Bug 572796 - Unable to establish a wireless connection
Summary: Unable to establish a wireless connection
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 13
Hardware: i686
OS: Linux
low
urgent
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F13Target
TreeView+ depends on / blocked
 
Reported: 2010-03-12 02:05 UTC by Peter Gückel
Modified: 2010-05-07 17:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-07 16:36:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
See var/log/messages for further information (95.69 KB, text/plain)
2010-03-12 02:05 UTC, Peter Gückel
no flags Details
NetworkManager --no-daemon crash (2.14 KB, application/octet-stream)
2010-04-06 20:50 UTC, Alex G.
no flags Details
wpa_supplicant.log (167.72 KB, text/plain)
2010-04-07 01:52 UTC, Peter Gückel
no flags Details
wpa_supplicant.log using knetworkmanager (209.09 KB, text/plain)
2010-04-13 20:29 UTC, Peter Gückel
no flags Details

Description Peter Gückel 2010-03-12 02:05:07 UTC
Created attachment 399520 [details]
See var/log/messages for further information

Description of problem:
NetworkManager refuses to establish a wireless connection (only wired possible).

Version-Release number of selected component (if applicable):
0.8.0-0.4-git20100211.fc13.i686

How reproducible:
Boot computer without wired plugged in. No connection occure. Open edit connections in nm-applet and enter all the information for a new wireless connection. Try to connect to it: nothing happens. Reboot and hope that the newly created wireless will now kick in: still nothing.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:
Achieve a wireless connection.

Additional info:
Wireless worked fine in f12 and earlier on this laptop (no hardware has been changed). The laptop uses ipw2200-firmware-3.1-4.fc13.noarch, which is installed. The laptop is equipped with INTEL PRO/WIRELESS 2200BG.

Comment 1 Qian Cai 2010-03-22 04:37:36 UTC
Same problem here with,
NetworkManager-0.8.0-2.git20100317.fc14.i686
ipw2200-firmware-3.1-4.fc13.noarch

Comment 2 Peter Gückel 2010-04-01 19:23:56 UTC
I have continued updating and have the latest updates or updates-testing versions installed (not on the laptop now) and I scanned /var/log/messages. It seems that the connection is attempted many times, but each time it fails, giving the reason:

"association took too long".

I should add that while booting the computer, the wireless lamp is lit on the router and it remains lit as the login occurs, then, once logged in, it begins flickering (likely while the aforementioned association is being attempted) and then finally it extinguishes and there is no longer any way to revive the wireless light (which corresponds to the connection) on the router.

Is the inability to obtain a wireless connection a showstopper for the release of F13Beta?

Comment 3 James Laska 2010-04-06 13:05:02 UTC
Works fine for me using ipw2200 (NetworkManager-0.8.0-4.git20100325.fc13 and kernel-2.6.33.1-19.fc13).

Can you retest with the latest kernel and NetworkManager packages?

Comment 4 Adam Williamson 2010-04-06 16:30:20 UTC
"Is the inability to obtain a wireless connection a showstopper for the release
of F13Beta?"

it depends on the exact impact of this. It works fine on this system, for e.g. (rt2800 wireless, using the RPMFusion driver). If all wireless connections failed, that'd be a blocker, but I don't believe that's the case. We need to pin down exactly what the failure conditions are.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 5 Dan Williams 2010-04-06 17:47:58 UTC
(In reply to comment #2)
> I have continued updating and have the latest updates or updates-testing
> versions installed (not on the laptop now) and I scanned /var/log/messages. It
> seems that the connection is attempted many times, but each time it fails,
> giving the reason:
> 
> "association took too long".
> 
> I should add that while booting the computer, the wireless lamp is lit on the
> router and it remains lit as the login occurs, then, once logged in, it begins
> flickering (likely while the aforementioned association is being attempted) and
> then finally it extinguishes and there is no longer any way to revive the
> wireless light (which corresponds to the connection) on the router.

Can you follow the directions here in the "Debugging WiFi Connections" section?

http://live.gnome.org/NetworkManager/Debugging

I'm specifically interested in the wpa_supplicant -dddt logs.

ipw2200 and NM git20100325.f13 also work here for WPA PSK.

Comment 6 Alex G. 2010-04-06 20:50:20 UTC
Created attachment 404787 [details]
NetworkManager --no-daemon crash

I think bug 574247 is a duplicate of this one.

(Raling rt2860 wireless card on EEEPC901)

After installing
kernel-2.6.33.1-19.fc13.i686
ModemManager-0.3-6.git20100331.fc13.i686
NetworkManager-glib-0.8.0-4.git20100325.fc13.i686
NetworkManager-0.8.0-4.git20100325.fc13.i686

knetworkmanager reports that "Network Manager disabled". I've tried to follow the steps provided, but I'm getting a crash in NetworkManager --no-daemon.

I think the problems may be related.

Comment 7 Peter Gückel 2010-04-07 01:48:49 UTC
I have NetworkManager-0.8.0-4.git20100325.fc13.i686 and kernel-PAE-2.6.33.1-24.fc13.i686.

OK, Dan, I edited the file as shown in the debugging link above. I had to remove sections, like -B that was before -u -f and I had to replace -P /var/run/wpa_supplicant.pid with -dddt in order to make the line in my file read exactly as described.

Ok, I got the output. I keep seeing the message, No keys have been configured - skip key clearing, but I do have my passphrase stored in knetworkmanager and it is shown. It is there.

I never had a problem with this before. It worked in f12 (but I used nm-applet for gnome, back then, not knetworkmanager, but Kevin Kofler says he's using knetworkmanager without problems).

I will attach my output net posting.

Comment 8 Peter Gückel 2010-04-07 01:52:59 UTC
Created attachment 404817 [details]
wpa_supplicant.log

Comment 9 Adam Williamson 2010-04-07 23:57:34 UTC
We had a lot of people testing F13 over the past few days, and specifically testing the kernel for Beta RC5, who mentioned their wireless is working okay. My wireless works, so does James'. We're not sure what the failure condition here is, but we're pretty happy this issue isn't widespread enough to constitute a blocker. So, dropping from the blocker list.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Alex G. 2010-04-08 08:16:58 UTC
Yay! for quality control.(forgive my sarcasm)

This decision is a bit disappointing. The issue is definitely a show-stopper for EEEPC users.

Comment 11 James Laska 2010-04-08 12:13:15 UTC
(In reply to comment #10)
> Yay! for quality control.(forgive my sarcasm)
> 
> This decision is a bit disappointing. The issue is definitely a show-stopper
> for EEEPC users.    

Alex, I understand your frustration.  At the last minute before Beta release, a decision has to be made.  Unfortunately, we didn't have enough information in hand to say ... "let's hold the Beta and slip the release of F13 another week for this bug".  That's not to say this issue isn't important and doesn't affect you.  

Hopefully the provided debugging information helps Dan Williams determine the nature of the problem, and leads to an updated package in F13 that can be installed and tested during an initial DVD or wired install (wireless install not supported).  

I've added this to F13Blocker to keep this on the radar given this potentially impacts all EEEPC.

Comment 12 Adam Williamson 2010-04-08 18:32:36 UTC
Ooh, wait. I think I may know what's going on here.

Did this ever actually work out of the box, or have you been using the rt2860sta driver from RPM Fusion?

There's a driver in the F13 kernel, now, for rt28xx devices; rt2800pci. This didn't exist in F12. AFAICT, it doesn't actually work yet; it behaves for me (I happen to have a similar card in my desktop) exactly as you describe. But I've never been able to use the card with any driver but rt2860sta, from RPMFusion. The only difference now is there's a driver in the official kernel which _tries_ to work, but doesn't.

If you make sure you have an appropriate RPMFusion repo set up and install the rt2860sta driver from there, it should blacklist the rt2800pci driver automatically, and then work...

I may be misreading the situation, but that's how it is on my system.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 13 Dan Williams 2010-04-08 23:05:41 UTC
*** Bug 574247 has been marked as a duplicate of this bug. ***

Comment 14 Alex G. 2010-04-09 07:11:24 UTC
It never detected the card out-of the box until F13.

A while back I installed akmod-rt2860 from RPM fusion (F13). I verified that it built the kernel module, but never really verified if it was loaded or not. I still couldn't connect.

I won't have access to a wired network for the next couple of days, but I'll start chopping as soon as I do.

Comment 15 Adam Williamson 2010-04-09 16:29:50 UTC
Alex: for a while, the RPM Fusion package didn't include a /etc/modprobe.d file to blacklist the in-kernel module, so the rt2860sta module would get loaded after the in-kernel rt2800pci module on boot, the rt2800pci module would get control of the hardware, and it still wouldn't work. So you may well have an older version of the RPM Fusion package without the blacklist file, and that's why it's not working.

The latest RPM Fusion package does include a blacklist file; or you can just make one yourself. Create the file /etc/modprobe.d/blacklist-rt2800.conf and add just the line 'blacklist rt2800pci' to it. That would be all it'd need.

Comment 16 Peter Gückel 2010-04-10 23:45:58 UTC
I upgraded to NetworkManager-0.8.0-6.git20100408.fc13.i686.

I can now get a connection when I use cnetworkmanager, but when I use knetworkmanager, it still doesn't work.

Comment 17 Alex G. 2010-04-11 20:21:02 UTC
(In reply to comment #15)

Yes you are right; akmod-rt2860 works. I'm able to connect using the NetworkManager included with the alpha.

Should I file a bug report for the kernel with this?

Comment 18 Adam Williamson 2010-04-12 17:55:44 UTC
Not really worth it, the in-kernel driver is considered highly experimental. If it doesn't work for me by the time F13 is close, I may talk to the kernel devs about disabling it by default. I keep an eye on the wireless-next tree and test it every so often to see if they've made the thing work yet, but no dice so far. If you want to file a bug on the kernel file it upstream, but I expect the upstream devs are already aware the driver doesn't really work yet.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 19 Adam Williamson 2010-04-12 17:56:12 UTC
note that only Alex G. is hitting the rt2860 issue, Peter's bug appears to be different (and probably knetworkmanager-related). So leaving the report open.

Comment 20 Dan Williams 2010-04-12 23:41:10 UTC
Peter: could you provide the wpa_supplicant logs again but grab some both when using knetworkmanager and cnetworkmanager so we can compare?  Be sure to:

cp /var/log/wpa_supplicant.log /tmp/wpa_supplicant-knm.log
rm -f /var/log/wpa_supplicant.log
<do test with cnetworkmanager>

etc so we can cleanly separate the logs.

For the logs your provided in comment #8 the failure point is:

1270604308.558872: Authentication with 00:1b:5b:97:32:11 timed out.

which means the AP simply isn't responding to your wifi card's requests to authenticate.  That could indicate driver problems, or it could indicate that the PSK is wrong and the AP simply isn't replying to the bad PSK, which could be caused by an error in knetworkmanager.

Getting the supplicant logs from both knm and cnetworkmanager should help us figure out what's going on.

Btw, what package version is knetworkmanager?

Comment 21 Peter Gückel 2010-04-13 20:11:25 UTC
Dan, I connected using cnetworkmanager, but no wpa_supplicant.log is created! There is no file. Do I have to specify some sort of option to cnetworkmanager to force it to create a wpa_supplicant.log?

Comment 22 Peter Gückel 2010-04-13 20:29:11 UTC
Created attachment 406342 [details]
wpa_supplicant.log using knetworkmanager

I:

killed knetworkmanager
made a copy and deleted the original wpa_supplicant.log
stopped the service NetworkManager
started the service NetworkManager
established a connection with cnetworkmanager

but there is no new wpa_supplicant.log, even though I have a running connection.

Comment 23 Peter Gückel 2010-04-13 20:56:53 UTC
I just thought of something: I am running cnetworkmanager without wpa_supplicant, so of course there would not be a log.

I have been running it like this:

cnetworkmanager -C networkname --wpa-pass=unencryptedkey

How would I make it use wpa_supplicant? Where would I find the encrypted key that wpa_supplicant uses?

Comment 24 Peter Gückel 2010-04-13 22:35:51 UTC
No, that was wrong, wasn't it? Even though I enter the key unencrypted, I am still using wpa, aren't I?

I have the feeling that knetworkmanager is not able to communicate with wpa_supplicant or is not able to unencrypt the key. It's something about wpa_supplicant with knetworkmanager.

Comment 25 Tim Fenn 2010-04-14 10:07:02 UTC
I have a eeepc 1000he with similar issues under F13 beta (wireless works with the akmod-rt2860 from rpmfusion, but not with rt2800pci out-of-the-box) - I'd be glad to provide additional information/perform testing if need be.

Comment 26 Alex G. 2010-04-14 10:23:09 UTC
Tim's question made me wonder, why isn't rt2860sta included in Fedora by default?

I wasn't able to find the answer, and rt1860 source code seems to follow Fedora's licensing guidelines.

Comment 27 Peter Gückel 2010-04-14 16:08:16 UTC
I forgot to tell you the knetworkmanager version:

knetworkmanager-0.9.0.17-20100310.fc13.i686

Comment 28 Adam Williamson 2010-04-14 18:58:39 UTC
can we please stop talking about the ralink issue here? it's not the bug under discussion.

rt2860sta isn't in Fedora because Fedora, by policy, does not accept out-of-tree kernel modules. The reason for this policy is that they're usually out-of-tree for a reason, and this is certainly true in the case of rt2860sta (it's a messily coded driver which would not meet the standards to be included in the upstream kernel).

Fedora's preferred approach is to either get an out-of-tree driver added to the upstream kernel, if it's sufficiently good, or improve it or write/encourage the writing of a new one, if it's not.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 29 Tim Fenn 2010-04-14 19:33:29 UTC
(In reply to comment #28)

Sorry, ralink people should be here:

https://bugzilla.redhat.com/show_bug.cgi?id=570869

instead of this bug.

Comment 30 Jirka Klimes 2010-04-15 11:49:56 UTC
Looks like that it's an issue with ipw2200, ipw2200-firmware. And maybe some interaction with wpa_supplicant and/or APs.

I've found several post complaining on ipw2200 after an upgrade.

1. http://sidux.com/PNphpBB2-printview-t-20036-start-15.html
   Last comment suggest that reinstalling firmware package solve the problem.
   (Debian based system)
   So, try to reinstall ipw2200-firmware package, or possible downgrade it.
2. http://forums.debian.net/viewtopic.php?f=5&t=50892
3. https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/331103
   comment 39 confirms that some APs works, others not


(In reply to comment #22):
1271189695.004627: WPA: 4-Way Handshake failed - pre-shared key may be incorrect

The line means that handshake was not successful. What AP do you use? Are you able to obtain some logs from it?

Comment 31 Peter Gückel 2010-04-16 17:54:41 UTC
(In reply to comment #30)
> The line means that handshake was not successful. What AP do you use? Are you
> able to obtain some logs from it?    

What's an AP? You mean what brand of router do I have? It is a Gateway 2700. I don't think I can get any logs. I wouldn'thave a clue how to. It is attached to the telephone jack and my computer(s) are attached to it by wire (desktop) and by wireless (laptop).

OK. I downloaded the ipw2200-firmware and will reinstall it. It is impossible to downgrade, as there is only this version for f13 available.

Comment 32 Adam Williamson 2010-04-16 18:03:23 UTC
"I don't think I can get any logs. I wouldn'thave a clue how to. It is attached to
the telephone jack and my computer(s) are attached to it by wire (desktop) and
by wireless (laptop)."

It should have a management interface; all routers do, so you can configure things like the password, the wireless mode, the firewall features and so on. Usually, you'd do something like browsing to http://192.168.1.1 from one of the other computers to access it.

On some models of router, you can get logs from this management interface.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 33 Peter Gückel 2010-04-16 18:33:32 UTC
(In reply to comment #32)
> 
> On some models of router, you can get logs from this management interface.
> 

OK, so what would I look for?

I uninstalled and reinstalled ipw2200-firmware and there was no change.

Comment 34 Peter Gückel 2010-04-16 18:39:51 UTC
The only places where the router has any logs is for remote access, but I have that disabled, so it is empty; the firewall; and parental logs, but I am not using parental blocking. There are no logs for the wireless.

Comment 35 Adam Williamson 2010-04-16 20:07:23 UTC
cai, are you still having trouble with this?

Discussed at today's blocker review meeting. For now, we think this is too restricted in impact to be considered a blocker: it seems to be specific to KDE and to Peter's config, Rex Dieter says that as far as he's aware, knetworkmanager mostly works okay for typical wireless configs.

If we get information suggesting the impact of this is wider than initially thought, we can add it back to the blocker list. James Laska will test an ipw2200 system he has handy to see if he can reproduce, in KDE.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 36 Peter Gückel 2010-04-16 20:37:47 UTC
There has been a new development. As mentioned in comment #31, I reinstalled the firmware.

I just rebooted and this time (for the first time ever), I was asked whether I wanted to start knetworkmanager automatically upon booting. Due to the problems, I answered in the negative, and voilà,, I got a connection! It seems that nm-applet has silently and unseen stepped up to the plate (the icon does not appear in the system tray, but there is now network ability).

Comment 37 Peter Gückel 2010-04-16 23:15:44 UTC
This is exasperating. I rebooted again, and now nm-applet does appear in the system tray and knetworkmanager does not start, but...

there is NO network connection.

It only works with cnetworkmanager (again).

Comment 38 Peter Gückel 2010-04-25 03:46:17 UTC
I got the new knetworkmanager and NetworkManager packages, but there is no improvement. Still no connection, except with cnetworkmanager.

Comment 39 Dan Williams 2010-04-25 07:50:43 UTC
Yeah, this seems like a knetworkmanager-only thing at this point.  If jlaska can reproduce with knetworkmanager, I guess I'll have to dive in and see where NM <-> knetworkmanager are miscommunicating.  There's at least one bug open about NM/knetworkmanager miscommunication somewhere already.

Comment 40 Gowrish 2010-04-26 05:23:17 UTC
"association took too long" problem

experienced this problem when there were two wireless router with same SSID. Network manager displayed only one SSID while 'iwlist scan' identified two different ap with same ssid. So changed the ssid of my router and now it works well.

Comment 41 James Laska 2010-04-28 13:57:39 UTC
So, I'm new to KDE ... and not entirely familiar with the UI, but I'm able to connect to wireless while logged in.  It wasn't obvious and didn't automatically show nearby networks.  I had to click the nm-applet icon, and select "[X] Enable wireless".  Eventually, it saw nearby networks.  I was able to select, enter connection details and connect to a nearby wireless network.

I installed my system from a GNOME desktop live image last week.  I next installed KDE by doing, 'yum groupinstall "KDE Software Compilation"'.

= System details =

ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq
ipw2200: Copyright(c) 2003-2006 Intel Corporation
ipw2200 0000:0b:02.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection
ipw2200 0000:0b:02.0: firmware: requesting ipw2200-bss.fw

Smolt profile available at http://www.smolts.org/client/show/pub_7f9b3dd5-4116-46e9-a0ae-af2b2f995aa3

Comment 42 Dan Williams 2010-04-28 20:02:04 UTC
(In reply to comment #40)
> "association took too long" problem
> 
> experienced this problem when there were two wireless router with same SSID.
> Network manager displayed only one SSID while 'iwlist scan' identified two
> different ap with same ssid. So changed the ssid of my router and now it works
> well.    

Correct, having two SSIDs connected to different physical networks is a misconfiguration of the wireless network.  Each AP broadcasting an SSID is expected (by the standards) to be interconnected with every other AP broadcasting that SSID.  This is how multi-AP roaming works with WiFi.  If you  have two APs with the same SSID, but they are connected to different physical networks then you cannot seamlessly roam between them.  Many corporate and other networks use multiple APs with the same SSID so that when you walk between offices and buildings you keep connectivity and do not have to continually reconnect.

Some kernel drivers have the ability to "lock" the connection to a specific AP based on that AP's MAC address/BSSID; you can do this in the connection editor's Wireless tab for that connection, and lock the connection to only your AP even if there's a different AP with the same SSID nearby.  Note that this does not work for all kernel drivers (most of the newer hardware is OK), but the capability is there.

Comment 43 Dan Williams 2010-04-28 20:03:22 UTC
(In reply to comment #41)
> So, I'm new to KDE ... and not entirely familiar with the UI, but I'm able to
> connect to wireless while logged in.  It wasn't obvious and didn't
> automatically show nearby networks.  I had to click the nm-applet icon, and
> select "[X] Enable wireless".  Eventually, it saw nearby networks.  I was able
> to select, enter connection details and connect to a nearby wireless network.
> 
> I installed my system from a GNOME desktop live image last week.  I next
> installed KDE by doing, 'yum groupinstall "KDE Software Compilation"'.
> 
> = System details =
> 
> ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq
> ipw2200: Copyright(c) 2003-2006 Intel Corporation
> ipw2200 0000:0b:02.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
> ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection
> ipw2200 0000:0b:02.0: firmware: requesting ipw2200-bss.fw
> 
> Smolt profile available at
> http://www.smolts.org/client/show/pub_7f9b3dd5-4116-46e9-a0ae-af2b2f995aa3    

James, I think people here are using the built-in KDE network manager applet, not nm-applet, which is apparently causing the issue.  Try temporarily moving the /etc/xdg/autostart/nm-applet.desktop file out of the way to allow the KDE applet to start.  At least I hope that's what lets the KDE applet start :)

Comment 44 James Laska 2010-04-28 20:10:14 UTC
(In reply to comment #43)
> (In reply to comment #41)
> > So, I'm new to KDE ... and not entirely familiar with the UI, but I'm able to
> > connect to wireless while logged in.  It wasn't obvious and didn't
> > automatically show nearby networks.  I had to click the nm-applet icon, and
> > select "[X] Enable wireless".  Eventually, it saw nearby networks.  I was able
> > to select, enter connection details and connect to a nearby wireless network.
> > 
> > I installed my system from a GNOME desktop live image last week.  I next
> > installed KDE by doing, 'yum groupinstall "KDE Software Compilation"'.
> > 
> > = System details =
> > 
> > ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq
> > ipw2200: Copyright(c) 2003-2006 Intel Corporation
> > ipw2200 0000:0b:02.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
> > ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection
> > ipw2200 0000:0b:02.0: firmware: requesting ipw2200-bss.fw
> > 
> > Smolt profile available at
> > http://www.smolts.org/client/show/pub_7f9b3dd5-4116-46e9-a0ae-af2b2f995aa3    
> 
> James, I think people here are using the built-in KDE network manager applet,
> not nm-applet, which is apparently causing the issue.  Try temporarily moving
> the /etc/xdg/autostart/nm-applet.desktop file out of the way to allow the KDE
> applet to start.  At least I hope that's what lets the KDE applet start :)    

I believe I was using the built-in KDE network manager applet.  It looked nothing like nm-applet I know of.  Logging back into KDE, I can confirm that the application 'nm-applet' is *NOT* running.  I do see 'knetworkmanager' running.  Sorry, I'm just used to typing nm-applet.

Comment 45 Peter Gückel 2010-05-07 01:32:58 UTC
After updating to NetworkManager-0.8.0-12.git20100504, I was no longer able to get even cnetworkmanager to connect, which had been my failsafe, so I started to experiment.

I wish someone had told me not to use hexadecimal digits in the wpa password for wireless internet! Using only decimal digits (I could swear that I tried that weeks ago, to no avail), but tonight it seems to have done the trick.

I think this bug is solved. It works with knetworkmanager and nm-applet. I didn't bother trying cnetworkmanager.

Comment 46 Dan Williams 2010-05-07 02:09:51 UTC
(In reply to comment #45)
> After updating to NetworkManager-0.8.0-12.git20100504, I was no longer able to
> get even cnetworkmanager to connect, which had been my failsafe, so I started
> to experiment.
> 
> I wish someone had told me not to use hexadecimal digits in the wpa password
> for wireless internet! Using only decimal digits (I could swear that I tried
> that weeks ago, to no avail), but tonight it seems to have done the trick.

Hmm, you should be able to use hex digits in the password (a valid passphrase would be "124125125abf231535ed" since it's between 8 and 63 digits inclusive and is composed only of ASCII characters).  If knetworkmanager is doing something odd WRT parsing that as a *hex* key, then that's a knetworkmanager bug.  A WPA key is only a hex key if it's *exactly* 64 characters long and is composed only of hex digits.

> I think this bug is solved. It works with knetworkmanager and nm-applet. I
> didn't bother trying cnetworkmanager.    

Good to know... shall we dupe this to https://bugzilla.redhat.com/show_bug.cgi?id=570947 or just close it?

Comment 47 Peter Gückel 2010-05-07 02:27:04 UTC
(In reply to comment #46)
> Hmm, you should be able to use hex digits in the password (a valid passphrase
> would be "124125125abf231535ed" since it's between 8 and 63 digits inclusive
> and is composed only of ASCII characters).
I was using 10 digits and I had a couple of hex digits in the mix. Composed only of ASCII, you say? So G-Z would be acceptable, too?

> If knetworkmanager is doing
> something odd WRT parsing that as a *hex* key, then that's a knetworkmanager
> bug.  A WPA key is only a hex key if it's *exactly* 64 characters long and is
> composed only of hex digits.
I don't know if knetworkmanager is not reading hex correctly, or if my router is not able to properly encrypt passwords including hex digits into a valid WPA key. I have been fiddling with this a long time and really don't feel like looking into that for a few days, at least. Wireless is working, although I haven't proven conclusively that knetworkmanager cannot use A-F or whether is is my router that won't.

> > I think this bug is solved. It works with knetworkmanager and nm-applet. I
> > didn't bother trying cnetworkmanager.    
> 
> Good to know... shall we dupe this to
> https://bugzilla.redhat.com/show_bug.cgi?id=570947 or just close it?    

I would say close both. Some day I will give my router another try with A-F or even any ASCII, like G-Z and see what happens.


Note You need to log in before you can comment on or make changes to this bug.