OLPC wireless startup at boot time

[Mikus Grinbergs]

> The question is why does it take so long for the connection to be established?
> 
> A 10-12 second reconnect time is to be expected:
>  1. A 1 second delay for the device to be probed and initialized on resume
>  2. NetworkManager has a 7 second delay hardcoded
>  3. A 1-2 second delay for scanning to complete
>  4. A 1-2 second delay for authentication, association, key exchange
> (if applicable) and DHCP.

It has looked to me as though icons already in Neighborhood View can
disappear as the XO reinitializes a complete scan of its radio spectrum.


I still think that in the plurality of wireless startup cases the pupil
will expect to make a connection on the SAME frequency that the XO was
using the last time his XO system's wireless was in use.

[I hope that an XO which is in "I've had my wireless connected for a
whole hour" mode can nevertheless detect whenever a __new__ AP shows up
(whose radio signal was not previously noticed).  If that is possible,
then the SAME capability should be applicable even at startup time.]


I'm thinking that at startup, Network Manager ought to be *inhibited*
while the XO listens on the same frequency as was last used.  If the XO
hears a strong enough signal, it ought to go into its "I've had my
wireless connected for a whole hour" mode -- and depend upon "radio
signal discovery" the same way that it does when not starting up..

Only if the XO at startup does NOT hear a strong signal on the last-used
frequency should the XO depend upon scanning and Network Manager to
determine "what are the radio signals that I am receiving now".
Whenever steps 2-3 above can be avoided, wireless startup will be
noticeably quicker.


[For those cases where the pupil has moved to a different schoolroom
while his XO was powered down - once the XO is powered up let the pupil
perform whatever manual "tuning" procedure he would have used if he had
moved to that different schoolroom while carrying his XO powered up.]

mikus