dhcpcd-discuss

Thanks for the explanation, Roy.
This will suffice for now.

Regards,
-shahid

On Tue, Jun 27, 2017 at 2:59 PM, Roy Marples <roy@xxxxxxxxxxxx> wrote:

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