[lwip-devel] [bug #20409] Add netif callback function for link change event

[Frédéric Bernon]

Follow-up Comment #28, bug #20409 (project lwip):

>The reason for a flag LINK_WAS_DOWN is that if the link changes fast, a
timer function might only see UP and UP again, not the DOWN in between. Thus
seeing no change, it wouldn't do anything. 

But if the change is short (<1000ms, I would even say <500ms), I think it's
not a problem to do nothing.

>As such, I don't know if it is enough to let the timers deal with such a
flag. You'd need one LINK_WAS_DOWN flag for every protocol or else one will
set it back and the others won't see it. 

I'm in flavour to let timers handle that, since like I said they are the only
ones to know what is the "right thing to do" on link down/up cases. Of course,
it could need to add a new state inside each one, but IT IS a new state, so,
it's logical...

>I think netif_set_up can stay like it is and the gratuitous ARP can be sent
there, as long as we make sure the interface is enabled again.

Agree

>For that, we could set the netif DOWN if the link is down and UP when the
link is back (from dhcp or autoip; or from hand when static IPs are used).
That way, the gratuitous ARP will be sent when the link is back. 

I don't like the idea that a link down cause to "down" the netif, and the
link up cause to "up". It's also possible to manually "down" a netif, and to
don't want it's "up" when the link is "up". To my point of view, this is two
really different state. But that a "link up" send a gratuitous ARP is the
netif is already "up" (in a netif_set_link_up) is not a big problem, since
it's only two lines of code.

>The only problem I see there is that the ARP timer is too slow... 

That's why, do the gratuitous ARP in both (netif_set_up & netif_set_link_up)
seems to be the best solution.

>a callback might be better after all... 

Agree with you: a callback, a "lock"... yes, it's better than a timer. The
problem is to provide the simplest way and less "intrusive" way to do that
(call netif_set_link_up/down).

>This brings us back to the old question of having a define that tells us
whether lwIP is running multithreaded or standalone

Yes ;)

>The only other solution would be to include locking in the whole core which
does nothing in standalone / raw mode.

Yes, and LOCK_TCPIP_CORE/UNLOCK_TCPIP_CORE can do this job...



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?20409>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/