dhcpcd-discuss

Hi

On 27/06/2017 19:36, Shahid Mahmood wrote:
> we are observing a situation when dhcpcd gets a link lost notification, 
> it sends NOCARRIER to the hook script followed by removing the IP 
> address and then sending 'EXPIRE' to the hook script.
>
> See:
>
> Jun 27 15:26:12 kernel: [  144.015919] wlan: EVENT: Link lost (reason 0x0)
> Jun 27 15:26:12 kernel: [  144.016145] wlan: Disconnected from 
> 02:XX:XX:XX:6d:2f: Reason code 3
> Jun 27 15:26:12 dhcpcd[696]: mlan0: carrier lost
> Jun 27 15:26:12 dhcpcd[696]: mlan0: executing `XXX/dhcpcd-run-hooks' 
> NOCARRIER
> Jun 27 15:26:12 dhcpcd[677]: mlan0: carrier lost
> Jun 27 15:26:12 dhcpcd[677]: mlan0: executing `XXX/dhcpcd-run-hooks' 
> NOCARRIER
> Jun 27 15:26:12 dhcpcd[677]: mlan0: deleting route to 192.168.43.0/24 
> <http://192.168.43.0/24>
> Jun 27 15:26:13 dhcpcd[677]: mlan0: deleting IP address 192.168.43.98/24 
> <http://192.168.43.98/24>
> Jun 27 15:26:13 dhcpcd[677]: mlan0: executing `XXX/dhcpcd-run-hooks' EXPIRE
>
> This is causing us some grief, because of which we intend to use 
> 'nolink' option parameter to avoid this situation.
>
> This leads to some questions:
>
> - What is the rationale for forcing a lease (which may not have expired) 
> to expire for this event?
> - What are the consequences of using 'nolink' to the end user 
> application? to dhcpcd internal functions? Are we compromising anything?

When the link comes back up again it will start using the IP address on 
the interface right away, which may cause DaD issues if another machine 
decides to use the address while we were off the link. Also, the network 
could have been changed.

The consequence of using nolink means there is the chance the host 
running dhcpcd could cause ARP announcements of the addresses which 
could cause other machines on the network either to have a poisoned ARP 
cache or erroneously fail their own DaD - maybe even drop off the 
network entirely. As such, dhcpcd strives to be a model role model for 
the network it's connecting to and ensures that no addresses are active 
when the link comes up. As dhcpcd reacts after the kernel starts using 
the addresses, they are removed at carrier down.

Obviously this isn't everyone idea of how it should work, so you're 
welcome to override it. Infact, some NetBSD users disliked it so much we 
added IPv4 DaD to the kernel and enforced the addresses not to be used 
until DaD had completed. Also, on carrier down the addresses are marked 
as detached (can't be used) and on carrier up go tentative (again, can't 
be used) until DaD completes when they can be used.

As such, NetBSD and dhcpcd is the *only* combination where you get the 
perfect network role model and the IP address persists unless dictated 
by the DHCP server (or lack of one).
Nothing stops you from adding the same to Linux and we can then do the 
same as NetBSD. Not something I'll be doing though - the Linux IP stack 
scares me.

Roy