[lwip-devel] [task #13508] Implement IPv4 Address Conflict Detection

[Jasper Verschueren]

Follow-up Comment #14, task #13508 (project lwip):

_- it seems like autoip is never stopped in coop mode, why did you remove the
coop state?_

Autoip was stopped by dhcp in following cases:
* Link goes up -> autoip now has it's own functions for link up and down. dhcp
should not bother with the autoip link up down behavior.
* dhcp_bind -> autoip should stay active when a valid routable address is
acquired. This was already the case (more or less) because
autoip_accept_packet stayed active. So actually the module was disabled while
it was still receiving packets on that address. This is not the good approach.
Now when a routable address is set on the netif the acd module of autoip will
be put in passive mode. This means that conflict detection and autoip stays
active but when a conflict occurs it's shut off. 
* dhcp_release_and_stop -> If you want to stop dhcp, their is no need to turn
off autoip. 

Generally I removed the coop state because dhcp should not influence the
autoip behavior. To keep a state variable of autoip in the dhcp struct seems
looking for trouble to me. The autoip state can change without dhcp knowing
it, should we then make functions to update the state variable from autoip in
the dhcp struct... The only thing that dhcp should do is start autoip if dhcp
is failing. Also keeping the the address open for packets but shutting down
the autoip module is not nice.

_- it seems like autoip is disabled on link loss and never re-enabled. Why is
that?_ 

Autoip is always disabled on link down. This because their is no need to keep
it enabled. When the link goes up, you need to restart it anyway. Autoip is
(re)started on link up if the LWIP_DHCP_AUTOIP_COOP is off. In that situation
autoip is on it's own. If LWIP_DHCP_AUTOIP_COOP is on, dhcp will need to
restart it again if it fails to find a dhcp server. The link local address
however is kept the same until their is a conflict found.

I would like (later on) to add a kind of address api that handles these kinds
of priority levels in how the address should be acquired. It would also have
fixed IP in their. I don't like when things are too much entangled. I don't
think that dhcp should start autoip in the first place. My perference would be
that the dhcp module signals to the address api that it is failing to find a
server. Then the address api can decide what to do with that information. I do
not have time to work on the address api for now but that is on my list. 

_- how is the new ACD module integrated with user-supplied static IPs? Your
patch disables the single gratuitous ARP for static IPs, so that's another
regression._

There is not really an integration with the static IPs because there are no
static IP functions. If a user want's to use static IPs it can of course use
the ACD module. 
I see that the single gratuitous ARP is indeed disabled in the case you have
ACD enabled and are using fixed ip without ACD. If you would be using it with
ACD their is no problem of course. If you are using autoip or dhcp with ACD
then why would you not use it on fixed ip? I did not think of that case
because lwIP does not have any support for fixed IP. You would need to write
your own management functions.
Could we leave it as in my patch? or do you have a suggestion? Also if autoip
is enabled but ACD is not enabled on dhcp, it will not send this gratuitous
arp for a dhcp address. 
I do not directly see a solution for the fixed ip situation except adding the
just mentioned address api. A fixed IP looks like a routable so we cannot do
an easy check on the netif address. Using defines in the lwipopts.h also does
not work, because it can be changed at run time. 
For the dhcp situation this can simply be solved with an extra check on the
LWIP_DOES_ACD_CHECK and the type of the new address. 
If we have a solution for the fixed ip situation, I will create a patch
combining both dhcp and fixed ip solutions. 

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/task/?13508>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/