Bug 231526

Summary: [PATCH] fix for dhclient alias issue
Product: Base System Reporter: Domagoj Hranjec <cab902>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed DUPLICATE    
Severity: Affects Only Me CC: cem
Priority: --- Keywords: patch
Version: CURRENT   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=119801
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222899
Attachments:
Description Flags
fix for bug #119801 none

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 freebsd_triage 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 ***