Dan Williams <dcbw redhat com> writes:
> 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)
Done (see attached)
Note: you'll see two runs of the test tool in the log, because there
was an apparent hang at the end of the first run. I should have known
it was just a long long delay, because that's exactly where NM tends
to delay when connecting. It did the same thing in the 2nd run, but
after waiting long enough (minutes) the process continued, so you'll
see more output in the 2nd run. The tool never exited, so I can't
tell if you got all the information you wanted, but at the point I
captured the log for the 2nd run, I did have a usable wireless network
connection. It would probably be helpful if you added timestamps to
the debugging tool output (and probably NM's output as well, since
syslog does not reliably get timestamp updates for some reason).
> as well as the output
> from a run of NetworkManager itself attempting to connect to the same AP
> with the same config options.
I never received a clear answer from you or Darren about what "with
the same config options" means in this case, since I can't supply the
config options directly to NM, so I just used
NetworkManager --nodaemon
My first attempts to connect with NM were very successful (as the
first wireless connection with NM always seems to be on this
machine). I didn't keep those logs. Do let me know if you want to
see some successful connections. Then I carried the machine out of
network range and lost my connection. I killed NM and restarted it
with the results shown in the attached logs.
Even though I have seen NM stall many times at "stage 2 of 5" as shown
in the nm-supplicant-test logs, in this case I was getting lots of
stalls at
WPA: clearing AP WPA IE
Unfortunately, unlike the other case, it never seemed to establish a
connection after that.
BTW, and I've mentioned this before: I really would like to clear NM's
records of networks it's OK to connect to, but
gconftool-2 -R /system/networking
yields nothing. I don't know where this config stuff is actually
being stored on my machine, but it ain't there.
Attachment:
logs.tar.gz
Description: Binary data
-- Dave Abrahams Boost Consulting www.boost-consulting.com