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 ), 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.
Description: Binary data
-- Dave Abrahams Boost Consulting www.boost-consulting.com