Darren Kenny wrote: > 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. > > hmm, that's a very good point. It might make sense for us to unplumb/replumb if the ESSID changes. On a new ESSID selection, we could note that an unplumb is needed when the link up is propogated to the IP NCU. > 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. > > We actually ignore DL_NOTE_LINK_UP/DOWN for wifi at present and use a monitoring thread which is triggered on connect - I found that we often get spurious LINK_DOWN events when connecting that throw a spanner in the works. >> - 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? > > The link NCU would go offline*/down, then after a retry interval, would scan and attempt to connect. We need the interval as it's possible a link down would lead to repeated scans which would hog the CPU in the case where no known WLAN was available. That happens already, but what doesn't happen now is a propogation of this state change to IP. My proposal means the IP NCU would go offline/conditions not met.
Thanks! Alan
