Re: Curious NM behaviour on new Fedora-11 system

[Dan Williams <dcbw redhat com>]

On Sun, 2009-07-19 at 18:45 +0100, Timothy Murphy wrote:
> Brian Morrison wrote:
> 
> >> Incidentally, are the meanings of the "state change" numbers
> >> explained anywhere?
> > 
> > In the source code I expect there will be some comments ;-)
> 
> Probably.
> Even so, NetworkManager reports take up well over 50%
> of my /var/log/messages (under Fedora).
> It's amazing that so much information
> can convey so little meaning, to me at least.

But, in the end, invaluable for debugging when things go wrong :)  First
thing to check is whether (for example) 'rmmod iwlagn' fixes the
problem; if it does, it's likely a kernel bug.  If not, and you still
can't reconnect after modprobing the module back, then try unplugging
the access point.  If that doesn't work, reboot, and try again.  If that
still doesn't work, sometimes APs just get screwed up and have to have a
timeout.  Other times its interference related.

Basically, NM is asking wpa_supplicant to connect, and the supplicant
tells the card to connect, and the card never connects within acceptable
timeouts.  Thus NM decides that your encryption key is wrong (which is
sometimes the cause of failed connections).

These days though, it's much more likely that the wifi driver is just
busted, or somebody turned on a microwave, than that your encryption key
is wrong.  So the idea (follow in the 'inhibit' branch in git) is to
just make NM try harder to connect with the same wifi key, and simply
not ask you for it again, because it's probably already right.  If NM
fails like 10 times (with some backoff between each time) then it might
want to notify you via a bubble or some other non-interrupting mechanism
that your connection is failing and you might want to check your key and
try again.

But in the end, even that doesn't help drivers that are all strung out
on crack as is unfortunately sometimes still the case.  That's what the
'rmmod' tests.  If it works after that, chances are it's a kernel issue.

Dan