Re: One more clue

[Dan Williams <dcbw redhat com>]

On Thu, 2006-09-07 at 10:54 -0400, David Abrahams wrote:
> Dan Williams <dcbw redhat com> writes:
> 
> > On Wed, 2006-09-06 at 11:03 -0400, David Abrahams wrote:
> >> NM is commonly not connecting -- or taking forever to connect -- to my
> >> network, especially after the connection is dropped (e.g. if I go out
> >> of range).  However, if I'm lucky enough to have an unprotected
> >> network nearby, all I have to do is try to connect to that unprotected
> >> network and wait for the first "green dot" in nm-applet (I don't even
> >> need a full connection), then switch back to my preferred network, and
> >> everything connects reasonably quickly.
> >> 
> >> It seems as though the answer must be discernable from all the data
> >> I've provided.  Am I providing too much data about my problem?
> >
> > The only thing I can think of to diagnose this issue is to figure out
> > what NM and wpa_supplicant are doing differently.  And that will require
> > a small tool that mimics the behavior of NM controlling wpa_supplicant.
> > So, I need to distill the wpa_supplicant controlling bits of NM into a
> > small utility into which we can feed network configurations.  If I did
> > this, would you be willing to test it for me?
> 
> Of course!

It's checked into NM CVS on both HEAD and stable branches as
test/nm-supplicant-test.c.  Build NM (or grab it here [1]), construct a
wpa_supplicant config file, then run:

sudo test/nm-supplicant-test eth1 /path/to/wpa_supplicant.conf

It will use the network config for the first _uncommented_ network.  To
diagnose the issue, I'll need the output from the supplicant tester (be
_sure_ to remove any "wep_key0" or "psk" lines) as well as the output
from a run of NetworkManager itself attempting to connect to the same AP
with the same config options.  That should help narrow the issue down.

Dan

[1] http://people.redhat.com/dcbw/NetworkManager/nm-supplicant-test