dhcpcd-discuss

Hi Roy,

On Fri, Sep 2, 2016 at 9:59 PM, Roy Marples <roy@xxxxxxxxxxxx> wrote:
> Hi Guy
>
> On 2016-09-02 18:25, Guy Yur wrote:
>>
>> With latest trunk and D5469 the addresses are restored.
>> I tested on head r304837 so 194485 doesn't apply cleanly.
>> Also reverted my changes for 195197.
>
>
> Great news!
>
> OK, so just running the D5469 patch.
> Can you try reverting that and reverting and any dhcpcd patches you have so
> it's a clean trunk please.
> If this works, then I'll do a new release shortly.
>
> Roy

Tested with VirutalBox, 2 cpu cores and em0 interface.
dhcpcd trunk 018576c771 unpatched.
FreeBSD 10.3 and head r305297.

1. kernel with D5469 as only networking change.
2. kernel with no networking changes.

1. IPv6 EUI64 link local and EUI64 ULA configured before dhcpcd starts.
dhcpcd adding "slaac private" ULA and global from RA.
2. No preconfigured addresses.
dhcpcd adding "slaac private" link local, ULA and global from RA.

IPv4 and IPv6 addresses added by dhcpcd are removed on link disconnect
or "if down" in all scenarios above.
IPv4 and IPv6 addresses are restored on link disconnect/reconnect
for all scenarios above.
IPv4 address is restored on "if down/if up" for all scenarios.
IPv6 addresses are restored on "if down/if up" if the kernel has D5469.
IPv6 addresses are restored on "if down/if up" when the kernel
doesn't have D5469 only if no preconfigured link local and ULA.


Some other unrelated issues I saw:
1. When two SIOCAIFADDR_IN6 ioctls are done, one for
ND6_INFINITE_LIFETIME and then the real lifetime, there are
nd6_dad_timer messages printed from the kernel.
"ndp -p" shows the prefix has infinity time and ifconfig shows
the address has time from RA so they are added fine.

"nd6_dad_timer: called with non-tentative address
NNNN:NNNN:NNNN:NNNN:AAAA:AAAA:AAAA:AAAA(em0)"


2. On link disconnect/reconnect the kernel complains on prefix delete
failure when deleting the address because dhcpcd already removed the
interface route.

"in_scrubprefix: err=51, prefix delete failed"
ENETUNREACH from rtinit1 when not found in the table?


3. Should the IPv4 routes be deleted in reverse order like IPv6?
Using TAILQ_FOREACH_REVERSE(rt, ctx->ipv4_routes, rt_head, next)
instead of "TAILQ_FOREACH(rt, ctx->ipv4_routes, next)" in
ipv4_buildroutes in loop for d_route.

Currently the interface route is deleted before the default route.
The kernel doesn't care so it works either way.


IPv4 log for if down:
em0: deleted route to 192.168.1.0/24
em0: ignored false RTM_DELADDR for 192.168.1.101
em0: carrier lost
em0: executing `/usr/local/libexec/dhcpcd-run-hooks' NOCARRIER
em0: deleting default route via 192.168.1.1
em0: deleting IP address 192.168.1.101/24

IPv4 log for link disconnect:
em0: carrier lost
em0: executing `/usr/local/libexec/dhcpcd-run-hooks' NOCARRIER
em0: deleting route to 192.168.1.0/24
em0: deleting default route via 192.168.1.1
em0: deleting IP address 192.168.1.101/24


Thanks,
Guy