[Starlingx-discuss] DHCP Related Patches
HI Brent, There are currently 6 DHCP related patches specifically to the client code. We have already determined that 2 of those patches the NSUPDATE protection could be removed, 2 seem to be StarlingX spceific but replaced with a enter-hook scripts provided in another patch. 1 is a backport dhclient-disable-NSUPDATE.patch support-disable-nsupdate.patch - Remove these 2 dhclient-handle-wrs-install-uuid.patch dhclient-dhcp6-wrs-install-uuid.patch - Can these be removed as the functionality is now added via the dhclient-enter-hooks script? dhclient-ipv6-bind-to-interface.patch - This is a backport, which will be available when CentOS updates to the newer version. dhclient-ipv6-conditionally-set-hostname.patch - Can this be moved to the dhclient-enter-hooks? dhclient-restrict-interfaces-to-command-line.patch - This seems to be adding functionality, in order to restrict the dhclient to only be active on one interface. There is no commit message for this one, or is there a way to refactor this? Is this a bug in dhclient? Was it ever filled or commented on in the DHCP mailing list? Thanks Sau!
Here's the original commit message for dhclient-restrict-interfaces-to-command-line.patch. There was an issue with leases expiring, causing interfaces to lose their IP addresses, which in turn caused various issues due to the loss of comms: Author: Allain Legacy <allain.legacy@windriver.com> Date: Tue Jan 5 14:36:47 2016 -0500 dhclient: restrict interfaces to those on command line only By default, the dhclient process does not respect the list of interfaces supplied at the command line. It configures any interfaces found to be specified in the config file. Since we customize options for each interface in our config file and run a separate dhclient process for each interface we end up with multiple dhclient processes that each service all interfaces. This is undesirable because it is possible that a request is sent by process A but received by process B. This leads to lease expiry events even though a valid request packet was returned by the server. This change introduces a "--restrict-interfaces" option to the dhclient process to force it to ignore all interfaces in config files other than those specified at the command line. To activate this change our busybox version of ifup/ifdown has been modified to pass the "--restrict-interfaces" to dhclient as well as to request that each process use its own lease file to avoid file corruption. -----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Thursday, October 04, 2018 6:02 PM To: Rowsell, Brent; starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] DHCP Related Patches HI Brent, There are currently 6 DHCP related patches specifically to the client code. We have already determined that 2 of those patches the NSUPDATE protection could be removed, 2 seem to be StarlingX spceific but replaced with a enter-hook scripts provided in another patch. 1 is a backport dhclient-disable-NSUPDATE.patch support-disable-nsupdate.patch - Remove these 2 dhclient-handle-wrs-install-uuid.patch dhclient-dhcp6-wrs-install-uuid.patch - Can these be removed as the functionality is now added via the dhclient-enter-hooks script? dhclient-ipv6-bind-to-interface.patch - This is a backport, which will be available when CentOS updates to the newer version. dhclient-ipv6-conditionally-set-hostname.patch - Can this be moved to the dhclient-enter-hooks? dhclient-restrict-interfaces-to-command-line.patch - This seems to be adding functionality, in order to restrict the dhclient to only be active on one interface. There is no commit message for this one, or is there a way to refactor this? Is this a bug in dhclient? Was it ever filled or commented on in the DHCP mailing list? Thanks Sau! _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On 10/04/2018 04:51 PM, Penney, Don wrote:
Here's the original commit message for dhclient-restrict-interfaces-to-command-line.patch. There was an issue with leases expiring, causing interfaces to lose their IP addresses, which in turn caused various issues due to the loss of comms:
Thanks Don, Was this reported anywhere? I am trying to ensure I follow any trails that have already been started. Thanks Sau!
Author: Allain Legacy <allain.legacy@windriver.com> Date: Tue Jan 5 14:36:47 2016 -0500
dhclient: restrict interfaces to those on command line only
By default, the dhclient process does not respect the list of interfaces supplied at the command line. It configures any interfaces found to be specified in the config file. Since we customize options for each interface in our config file and run a separate dhclient process for each interface we end up with multiple dhclient processes that each service all interfaces. This is undesirable because it is possible that a request is sent by process A but received by process B. This leads to lease expiry events even though a valid request packet was returned by the server.
This change introduces a "--restrict-interfaces" option to the dhclient process to force it to ignore all interfaces in config files other than those specified at the command line.
To activate this change our busybox version of ifup/ifdown has been modified to pass the "--restrict-interfaces" to dhclient as well as to request that each process use its own lease file to avoid file corruption.
-----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Thursday, October 04, 2018 6:02 PM To: Rowsell, Brent; starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] DHCP Related Patches
HI Brent,
There are currently 6 DHCP related patches specifically to the client code.
We have already determined that 2 of those patches the NSUPDATE protection could be removed, 2 seem to be StarlingX spceific but replaced with a enter-hook scripts provided in another patch. 1 is a backport
dhclient-disable-NSUPDATE.patch support-disable-nsupdate.patch - Remove these 2 dhclient-handle-wrs-install-uuid.patch dhclient-dhcp6-wrs-install-uuid.patch - Can these be removed as the functionality is now added via the dhclient-enter-hooks script?
dhclient-ipv6-bind-to-interface.patch - This is a backport, which will be available when CentOS updates to the newer version.
dhclient-ipv6-conditionally-set-hostname.patch - Can this be moved to the dhclient-enter-hooks?
dhclient-restrict-interfaces-to-command-line.patch - This seems to be adding functionality, in order to restrict the dhclient to only be active on one interface. There is no commit message for this one, or is there a way to refactor this? Is this a bug in dhclient? Was it ever filled or commented on in the DHCP mailing list?
Thanks Sau!
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On 10/04/2018 04:51 PM, Penney, Don wrote:
Here's the original commit message for dhclient-restrict-interfaces-to-command-line.patch. There was an issue with leases expiring, causing interfaces to lose their IP addresses, which in turn caused various issues due to the loss of comms:
Author: Allain Legacy <allain.legacy@windriver.com> Date: Tue Jan 5 14:36:47 2016 -0500
dhclient: restrict interfaces to those on command line only
By default, the dhclient process does not respect the list of interfaces supplied at the command line. It configures any interfaces found to be specified in the config file. Since we customize options for each interface in our config file and run a separate dhclient process for each interface we end up with multiple dhclient processes that each service all interfaces. This is undesirable because it is possible that a request is sent by process A but received by process B. This leads to lease expiry events even though a valid request packet was returned by the server.
So, a further question is why is the default behavior of having 1 process managing all the interfaces a bad thing? What problem were you trying to solve? Again, the WHY behind the original change not just that dhclient has a undesirable behavior. Why is there a dhclient/interface?
This change introduces a "--restrict-interfaces" option to the dhclient process to force it to ignore all interfaces in config files other than those specified at the command line.
To activate this change our busybox version of ifup/ifdown has been modified to pass the "--restrict-interfaces" to dhclient as well as to request that each process use its own lease file to avoid file corruption.
I think this dates to the OE version, as Centos does not have busybox, but the changes are in initscripts. Thanks Sau!
-----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Thursday, October 04, 2018 6:02 PM To: Rowsell, Brent; starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] DHCP Related Patches
HI Brent,
There are currently 6 DHCP related patches specifically to the client code.
We have already determined that 2 of those patches the NSUPDATE protection could be removed, 2 seem to be StarlingX spceific but replaced with a enter-hook scripts provided in another patch. 1 is a backport
dhclient-disable-NSUPDATE.patch support-disable-nsupdate.patch - Remove these 2 dhclient-handle-wrs-install-uuid.patch dhclient-dhcp6-wrs-install-uuid.patch - Can these be removed as the functionality is now added via the dhclient-enter-hooks script?
dhclient-ipv6-bind-to-interface.patch - This is a backport, which will be available when CentOS updates to the newer version.
dhclient-ipv6-conditionally-set-hostname.patch - Can this be moved to the dhclient-enter-hooks?
dhclient-restrict-interfaces-to-command-line.patch - This seems to be adding functionality, in order to restrict the dhclient to only be active on one interface. There is no commit message for this one, or is there a way to refactor this? Is this a bug in dhclient? Was it ever filled or commented on in the DHCP mailing list?
Thanks Sau!
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On 10/04/2018 03:01 PM, Saul Wold wrote:
HI Brent,
There are currently 6 DHCP related patches specifically to the client code.
We have already determined that 2 of those patches the NSUPDATE protection could be removed, 2 seem to be StarlingX spceific but replaced with a enter-hook scripts provided in another patch. 1 is a backport
dhclient-disable-NSUPDATE.patch support-disable-nsupdate.patch - Remove these 2 dhclient-handle-wrs-install-uuid.patch dhclient-dhcp6-wrs-install-uuid.patch - Can these be removed as the functionality is now added via the dhclient-enter-hooks script?
dhclient-ipv6-bind-to-interface.patch - This is a backport, which will be available when CentOS updates to the newer version.
MY bad, I was looking at the wrong code base, this is still a valid patch and seems to move where the bind to interface happens from after the bind to before the bind, again if this is a bug, was it reported anywhere to Redhat or Upstream on the DHCP list/bug system? Sau!
dhclient-ipv6-conditionally-set-hostname.patch - Can this be moved to the dhclient-enter-hooks?
dhclient-restrict-interfaces-to-command-line.patch - This seems to be adding functionality, in order to restrict the dhclient to only be active on one interface. There is no commit message for this one, or is there a way to refactor this? Is this a bug in dhclient? Was it ever filled or commented on in the DHCP mailing list?
Thanks Sau!
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (2)
-
Penney, Don
-
Saul Wold