From: Thomas Markwalder <tmark@isc.org>
Date: Thu, 7 Dec 2017 11:46:13 +0000 (-0500)
Subject: [master] Replaced --enable-secs-btyeorder with run-time parameter
X-Git-Tag: v4_4_0b1_f1~46
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b4e157d82c161a3697011d64e840d4d5aeb3183d;p=thirdparty%2Fdhcp.git

[master] Replaced --enable-secs-btyeorder with run-time parameter

    Merges in rt45364
---

b4e157d82c161a3697011d64e840d4d5aeb3183d
diff --cc RELNOTES
index 9d4a3e620,c0df4795a..06d398ffd
--- a/RELNOTES
+++ b/RELNOTES
@@@ -204,29 -203,16 +204,39 @@@ dhcp-users@lists.isc.org
    even valid values to fail as invalid on some environments.
    [ISC-Bugs #46535]
  
 +- dhclient will now include the lease address when logging DHCPOFFERs,
 +  DHCPREQUESTs, DHCPACKs, DHCPRELEASEs, and DHCPDECLINEs.  Additionally,
 +  DHCPOFFERs will be logged before their corresponding DHCPREQUESTs are
 +  sent and logged.
 +  [ISC-Bugs #2729]
 +
 +- When given the -T command line argument, in addition to reading the
 +  current lease file, the server will write the leases to a temporary
 +  lease file.  This can help detect issues in server configuration that
 +  only surface when leases are written to the file.  The current lease
 +  file will not be modified and the temporary lease file is removed upon
 +  completion of the test.
 +  [ISC-Bugs #22267]
 +
 +- dhclient will now generate a DHCPv6 DECLINE message containing all IA_NA
 +  addresses which for which the client script indicates a DAD failure. After
 +  receiving the DECLINE reply, dhclient will restart the solicit process.
 +  Note, the client script must exit with a value of 3 to signify that the
 +  address failed DAD.  Thanks to Jiri Popelka of Red Hat for submitting the
 +  patch that was the foundation for this change.
 +  [ISC-Bugs #21297]
 +  [ISC-Bugs #36966]
 +
+ - Replaced compilation option, enable-secs-byteorder, with a run-time, server
+   configuration parameter, check-secs-byte-order.  When enabled, the
+   server will check for clients that do the byte ordering on the secs field
+   incorrectly.  This field should be in network byte order but some clients
+   get it wrong.  When this parameter is enabled the server will examine the
+   secs field and if it looks wrong (high byte non zero and low byte zero) swap
+   the bytes.  The default is disabled.  This parameter is only useful when
+   doing load balancing within failover.
+   [ISC-Bugs #45364]
+ 
  			Changes since 4.3.0 (bug fixes)
  
  - Tidy up several small tickets.