On 12/08/2009 10:07, Alan Maguire wrote: > hi folks > > In the process of fixing 10377, I've been thinking > a bit about how we need to distinguish between > responses to various link down cases. The main > questions are > > - when do we unplumb IP? We don't want to > unplumb if the failure is transient, as is likely > the case with a wifi disconnect, but we do > want to unplumb when a link's priority group > is unselected, or when a link is wired and has > been unplugged, since that's a user-driven > act of deselection.
There is certainly a higher chance of a wifi disconnect being transient (e.g. you're carrying your laptop around, and would be moving AP (same essid but different bssid), so NWAM might disconnect the wlan and attempt a reconnect - and then chances are high that the same IP address will work and be valid. But then of course, what happens if you switch network, to an alternative remembered AP (suspend/resume is most likely here) - in that case the IP data is quite likely to be invalid, so we will need to do a dhcp request (assuming it's configured as such). Maybe both of the above cases will trigger a dhcp request? One thing is that some Wireless NICs (or probably more correctly drivers) do actually set the RUNNING flag appropriately depending on the connection state for the wifi network - I'm sure I've seen it happen - I don't know if this might effect the logic or not. > - what state/aux state should the IP NCU be in? > > Here's my proposal: > > - if a wired link goes down, unplumb IP and > mark the IP NCU as offline/conditions not met > and unplumb IP. A cable has been unplugged, > so it signifies intent. This is what happens > today. > - if a wireless link that was connected goes > down, mark the IP NCU as offline/conditions > not met and _do not_ unplumb IP. The only > complication here is that when handling > the IP NCU offline event, the state machine > would have to examine the state of the underlying > link to determine whether to unplumb or not. > We'd unplumb if the underlying link was offline > (as would be the case if another priority group > activates), but not if it was wifi and offline*, > since in the latter case we're still trying to reconnect. > > So this would change behaviour in that > link down events for wifi link NCUs would be > propogated to IP in terms of state changes, > but we'd stop short of unplumbing IP. Sound > reasonable? So, in this case there would be a state-change event, but the event would appear on the IP NCU, not the LINK NCU - is that correct? Thanks, Darren.
