Lines Matching refs:we
75 Here we discuss the essential objects and subtle aspects of the NWAM
114 initial event have been carried out to make higher level decisions we
118 for some short period of time (.1s). Typically the flurry of events we
121 what we do that cause external events to be posted on us. We are not
253 we want to distinguish between two cases:
255 1) when we are actively configuring the link with a view to moving online
263 So we see that offline and offline* can thus be used to distinguish between
277 WiFi links present a problem however. On the one hand, we want them
279 while on the other we want to watch out for new WLANs appearing in
281 group. The reason we watch out for these is they represent the potential
287 auxiliary state - why can't we simply add the auxiliary state machine to the
288 global object state machine? Part of the answer is that there are times we
291 WiFi - we want to do periodic scans to find a "better" WLAN - we can easily
293 states, but we want to stay online while we do it, since we are still
294 connected (if the WLAN disconnects of course we go to LINK_DOWN and offline).
296 Another reason we wish to separate the more general states (offline, online
319 since we have to simply assume a cable is plugged in. If an IP NCU
335 we need to decide how to aggregate the state of these logical
336 interfaces into the NCU state. The concept of "up" we use here
338 when we get (via getting RTM_NEWADDR events with non-zero
346 in, we need to reassess location activation conditions and
348 is that if we have a static/DHCP mix, and if we rely on
350 we will likely first apply the location when the static address
353 the solution is that on getting an RTM_NEWADDR, we
355 even if the interface NCU is already up, we reassess
375 So for NCUs, we define a handle_object_state() function