WPA anomalies in recent Joyride builds

[Dan Williams]

On Tue, 2007-12-18 at 11:14 -0500, Marcus Leech wrote:
> I use WPA-PSK (WPA personal) at home, and I've noticed anomalies.
> 
> One of the big ones is that it keeps re-prompting for the passphrase
> (this is with Joyride 1438), and tearing-down the
>   association.   I looked at /var/log/messages while this was going on,
> and it seems like it starts the association logic,
>   puts up the password prompt, and then times out the association
> attempt after 8 seconds--which typically isn't enough
>   time to type in the passphrase!   It turns out that NetworkManager has
> a wired-in 8 second timer for
>   re-association attempts, and 20 seconds for initial association attempts.

This only comes into play when there's an ongoing _connection_, it
doesn't come into play when you're typing in the password.  When NM
needs a password from you, it pauses the connection process until you
enter the password or cancel.

When it has the secrets it needs to connect, it _then_ will start timers
during the association.  There's an 8-second link timer, and an overall
20 second association timer.  The 8-second link timer only gets
triggered if the driver sends a disconnection event after association
has started, or when a successful association is established.  If the
link isn't re-established after 8 seconds, NM will terminate the
connection because the driver hasn't reassociated with the AP.  That
time might be a little bit low, but it's pretty reasonable.  The 4-Way
WPA handshake doesn't take that long, and if it does, you're most
definitely so far near the margins of your network that you won't be
able to pass frames anyway.

The 20 second overall association timer should probably get bumped up,
and I've got a NetworkManager in the OLPC-2 collection queued up to
build if required.  The problem here is that, due to driver issues, the
spawned wpa_supplicant may not have had enough time to scan and find the
AP you're looking for.  This is due mainly to driver issues, but is
exacerbated by the fact that a new wpa_supplicant is spawned for each
connection.  Later versions of NetworkManager use a long-running
wpa_supplicant process so this isn't as much of a problem.

> I'm not sure how this seems to work OK on a regular Fedora system--which
> is using almost the same version of

Because you're not using the libertas driver on the regular Fedora
system, and because a regular system doesn't have the memory and speed
constraints of the OLPC WRT to spawn time and memory pressure.  Things
just run slower on the OLPC so timeouts like this must be adjusted
upwards.

>   NetworkManager.  It's possible that the password-prompting happens
> before we go into the timer-controlled
>   region of the state machine--have we mucked with this at all?  Is the

Yes, the password prompting happens before either of the mentioned
timeouts is started.

> password dialog one of our own, or
>   just a standard one with Sugar decorations?

It's provided by Sugar, from sugar/hardware/*

Dan