Bug 231526 - [PATCH] fix for dhclient alias issue
Summary: [PATCH] fix for dhclient alias issue
Status: Closed DUPLICATE of bug 119801
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2018-09-20 19:06 UTC by Domagoj Hranjec
Modified: 2018-11-03 17:06 UTC (History)
1 user (show)

See Also:


Attachments
fix for bug #119801 (337 bytes, patch)
2018-09-20 19:06 UTC, Domagoj Hranjec
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Domagoj Hranjec 2018-09-20 19:06:21 UTC
Created attachment 197287 [details]
fix for bug #119801

On interface with alias and DHCP address (see bug #119801), after RENEW-ing of address the dhclient-script puts new DHCP address after the alias address which causes problems (with e.g. ipnat behaviour). [bugs #119801 and #222899]

The attached patch solves the issue by removing the old alias, before applying the new, hence restoring the new DCHP IP address on first place after DHCP renewal.
Comment 1 Conrad Meyer freebsd_committer 2018-11-03 17:06:13 UTC
Hm.  This patch provides a window where the ordering is wrong, right?  We delete the old address and routes, then add the new address and routes (at this point old alias is first), then with your patch remove the alias and re-add it (now second).  Also, it unnecessarily removes and adds the unchanged alias address, which I expect may break things like TCP connections.

Isn't the problem that we're (ipnat, ddclient, etc?) relying on address ordering on an interface at all?  Alias is a special keyword to the ifconfig command just to allow configuring >1 address, but aliases have no special meaning in the kernel -- all addresses are equal and just hang off a linked list from the interface ifp object.

Hypothetically we could add some sort of tagging via the ifa_flags field on interface addresses in the kernel, but there's no room in the SIOCAIFADDR ioctl for ifconfig to pass that additional information.

Duplicating this to the original bug and will follow up ipnat / ddclient issue there.

*** This bug has been marked as a duplicate of bug 119801 ***