After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 324660 - NetworkManage cannot connect to unencrypted wireless networks
NetworkManage cannot connect to unencrypted wireless networks
Status: RESOLVED INCOMPLETE
Product: NetworkManager
Classification: Platform
Component: general
0.5.x
Other All
: Normal major
: ---
Assigned To: Dan Williams
Dan Williams
: 326773 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-12-21 00:27 UTC by Diego González
Modified: 2007-07-05 23:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
output from NetworkManager --no-daemon, see comment (2.16 KB, application/x-compressed-tar)
2007-07-05 23:45 UTC, Ian Malone
Details

Description Diego González 2005-12-21 00:27:13 UTC
Please describe the problem:
this happends since the last series of big commits, nm-applet lists them, but
doesn't connect to any. When the network cable is pluged in it works ok. But not
with any wireless networks.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Dan Williams 2006-02-27 07:14:06 UTC
Is this still an issue now that the WPA support has landed?
Comment 2 Dan Williams 2006-02-27 07:17:36 UTC
*** Bug 326773 has been marked as a duplicate of this bug. ***
Comment 3 André Klapper 2006-10-01 03:57:08 UTC
Closing this bug report as no further information has been provided. Diego, please feel free to reopen this bug if you can provide the information Dan asked for.
Thanks!
Comment 4 Ian Malone 2007-07-05 18:24:58 UTC
Some Fedora 7 users have seen this behaviour: RedHat Bugzilla  242469 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242469 

In summary, connects to WPA encrypted networks, doesn't connect to unencrypted networks (but using RedHat's system-config-network to set up the open network will work). My version is 0.6.5.
Comment 5 Ian Malone 2007-07-05 23:45:32 UTC
Created attachment 91281 [details]
output from NetworkManager --no-daemon, see comment

The attached set of logs needs some explaining. I ran NetworkManager --nodaemon and it connected with the unencrypted network rc1.  That surprised me, since using NetworkManager this had not worked previously.  Output: NetworkManager--no-daemon.out

I cancelled (^C) NM, turned the access point's WPA on and repeated the process.  I was asked for the key, supplied it and the connection was sucessful: NetworkManager--no-daemon#-wWPA.out

I cancelled NM, then disabled WPA on the AP again (now open network) and repeated, CONNECTION NOW FAILED: NetworkManager--no-daemon#-aWPA.out

Since I had seen something previously about trying to connect to APs that had previously been encrypted I cancelled NM, changed the AP's ESSID from rc1 to rc (WPA still off).  Connection succeeded: NetworkManager--no-daemon#-rc.out

Finally, cancelled NM, changed ESSID back to rc1, WPA still off.  Connection now failed: NetworkManager--no-daemon.out

I'll add that I have the Network Monitor applet running for eth1 and can see the signal strength indicator.  In all unencrypted cases the Network Monitor applet was showing associated with good signal strength while Network Manager was still displaying busy.  Additionally in the unencrypted cases where connection was successful at stage 2 the process would then simply complete as fast as the terminal would scroll, the unsuccessful ones simply hung around until the timeout.

In conclusion:
First try on rc1 unencrypted successful.
First try on rc1 WPA successful.
After WPA, rc1 unencrypted fails
Change rc1 to rc (same AP), unencrypted successful
Change rc to rc1, unencrypted fails

If it's something to do with previous connections to the AP then this still doesn't completely tie with my previous failure to associate with wireless hotspots (but that was with the iwl3945 rather than ipw3945 driver used here and may be unrelated).