Bug 323371

Summary: NM 0.7 doesn't work with EAP-TLS
Product: [Fedora] Fedora Reporter: Charles R. Anderson <cra>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: bstein, dcbw, jamatos, mb--redhat, micko, vanmeeuwen+fedora, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: 0.7.0-0.6.6.svn3109.fc8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-03 05:35:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 235704, 336531    
Description Flags
/var/log/messages entry
new errors under svn3020
--requires output as requested
correct version :-\
wpa_supplicant-0.5.7-13.fc8 log file with -ddd
NetworkManager-0.7.0-0.4.svn3020.fc8 log messages
wpa_supplicant.log, separate PEM certs, ath5k driver
wpa_supplicant.log, DER certs, ath5k driver
NM messages, separate PEM certs, ath5k driver
NM messages, DER certs, ath5k driver
working manual wpa_supplicant.log, PEM certs, ath5k driver
working manual wpa_supplicant.conf none

Description Charles R. Anderson 2007-10-08 17:24:14 UTC
Description of problem:

NM 0.7 cannot connect to WPA/WPA2-Enterprise secured wireless networks.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Click on NM applet, notice wireless networks
2. Click on a SSID that requires WPA Enterprise encryption
3. Nothing happens.
Actual results:

No dialog pops up asking to configure WPA Enterprise settings, such as
certificate files, username/password, etc.

Expected results:
WPA/WPA2 Enterprise needs to work.  There must not be a regression from previous
Fedora releases in supported Wireless networks.

Additional info:
I've tried using the included ath5k driver (works fine on open networks) and
also madwifi from livna.  madwifi worked fine in FC6 connecting to WPA/WPA2
Enterprise networks.

Comment 1 Matt Bernstein 2007-10-15 09:01:50 UTC
It's not just certificate-based authentication. This will affect all eduroam
<http://www.eduroam.org/> users, amongst others. I'm happy to test koji builds
if that helps get NM working properly in F8.

Comment 2 Dan Williams 2007-10-24 15:51:29 UTC
Please test with svn3016 from koji; that should support WPA Enterprise networks.
 I've tested it with WPA-EAP TTLS MSCHAPv2 so far, and will do TLS today just to
make sure that certificates work.

Comment 3 Matt Bernstein 2007-10-24 16:04:52 UTC
It still doesn't work for me. dmesg reports:

ipw2200: Failed to send SYSTEM_CONFIG: Already sending a command.

(as it did before; sorry if I failed to report that earlier)

I hope to be using EAP-{TTLS,PEAP}-MSCHAPv2.

Comment 4 Dan Williams 2007-10-24 16:08:15 UTC
Seems more like a driver problem; What's your configuration?  I can try to
duplicate here and reproduce.  If you could give me the output of 'iwlist <ethX>
scan' for your access point that would help a lot.  Can you also provide the
output of /var/log/messages for the connection attempt?  Thanks!

Comment 5 Matt Bernstein 2007-10-24 16:22:36 UTC
Nothing in /var/log/messages (I put my own markers in just to be sure). The
ipw2200 message appears to occur later. The scan is:

          Cell 07 - Address: 00:14:C2:A3:A0:38
                    Protocol:IEEE 802.11bg
                    Frequency:2.462 GHz (Channel 11)
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Quality=91/100  Signal level=-37 dBm  
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : 802.1x
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : TKIP CCMP
                        Authentication Suites (1) : 802.1x
                    Extra: Last beacon: 75ms ago

I have a three-year-old Thinkpad X40 2386-H4G with the ipw2200 wireless. The AP
is an HP ProCurve Radio Port 230 hooked up to their 'Wireless Edge Services
Module', if that helps.

It worked OK under F7.

Comment 6 Matt Bernstein 2007-10-24 16:44:56 UTC
Created attachment 236371 [details]
/var/log/messages entry

After rebooting (and hence upgrading the kernel from release 23 to 30),
behaviour was different. (Previously I merely restarted the NM service.) I got
a prompt (for the first time ever under NM 0.7) and it would let me hit
'Connect' till I had filled in the CA (something I must confess to not having
done under F7). I gave it a PEM file of our root CA, and attached is what NM
0.7 thinks of it.

Is that better?

Comment 7 Matt Bernstein 2007-10-24 16:45:57 UTC

Comment 8 Dan Williams 2007-10-24 19:35:17 UTC
I've identified a number of problems when using certificates that I'm fixing for
the next build.

Comment 9 Dan Williams 2007-10-25 03:19:54 UTC
Please retest with svn3020.  Note that certificates will likely need to be in
DER format, not PEM format.  Thanks!

Comment 10 Matt Bernstein 2007-10-25 12:10:44 UTC
Created attachment 237311 [details]
new errors under svn3020

This is what I get under 3020 (without a reboot).

Will rebooting and creating a new user, and using the DER cert.

Comment 11 Matt Bernstein 2007-10-25 12:31:14 UTC
It's the same after rebooting, not allowing access to the keyring (rather than
new user) and using the DER CA file.

Sorry :-\

Comment 12 Dan Williams 2007-10-25 13:31:08 UTC
Did you force-install NetworkManager?  The latest NM requires a newer version of
wpa_supplicant, 0.5.7-13.  Can you post the output of 'rpm -q wpa_supplicant' ?

Comment 13 Matt Bernstein 2007-10-25 16:02:14 UTC
I didn't use --force, just 'rpm -Uvh', which didn't complain despite me having
wpa_supplicant-0.5.7-10.fc8. I won't be able to test this now till tomorrow, sorry.

Comment 14 Dan Williams 2007-10-25 17:40:03 UTC
Could you attach the output of 'rpm -q --requires NetworkManager' ?  Thanks!

Comment 15 Matt Bernstein 2007-10-25 19:42:53 UTC
Created attachment 237901 [details]
--requires output as requested

Curious.. (though I had already by then grabbed the updated wpa_supplicant from

Comment 16 Matt Bernstein 2007-10-25 19:44:47 UTC
Created attachment 237911 [details]
correct version :-\

Comment 17 Matt Bernstein 2007-10-26 09:31:10 UTC
OK. It's now tomorrow, I get into work, open my laptop and get the same problem.
After restarting wpa_supplicant, it magically starts working (so that's probably
why rebooting helped before). I still don't know why I was allowed to install
svn3020 with the old wpa_supplicant, but I'm less worried now.

Thank you. It now looks like my password is in my keyring rather than gconf :)

If you like, I will try to find another laptop to do a fresh rawhide install on.

Comment 18 Dan Williams 2007-10-26 16:41:14 UTC
If you could do a test with a fresh laptop, that would be awesome.  Thanks! 
Make sure you get wpa_supplicant-0.5.7-13.fc8.

Comment 19 Dan Williams 2007-10-26 16:43:20 UTC
FYI, .4.svn3020 (.3 -> .4 because NM didn't change at all, just the applet)
should allow PEM certificates too.  Could you test that if you have some PEM
versions hanging around?  Otherwise you can make them with 'openssl -x509 -in
cert.der -inform der -out cert.pem -outform pem' or something like that.

Comment 20 Charles R. Anderson 2007-10-26 22:28:35 UTC
I tried .4.svn3020, wpa_supplicant-0.5.7-13.fc8.  Doesn't work.

Here are my settings:

Wireless Security: WPA & WPA2 Enterprise
Authentication: TLS
Identity: Wireless User 06-07
User Certificate: Wireless-User.pem (in home dir)
CA Certificate: netops-ca.pem (in home dir)
Private Key: Wireless-User.pem (in home dir)
Private Key Password: <alphanumeric password>

Comment 21 Charles R. Anderson 2007-10-26 22:31:43 UTC
Created attachment 239681 [details]
wpa_supplicant-0.5.7-13.fc8 log file with -ddd

I added INTERFACES="-ddd" to /etc/sysconfig/wpa_supplicant.  This is
/var/log/wpa_supplicant.log from WPA Enterprise attempt.

Comment 22 Charles R. Anderson 2007-10-26 22:33:48 UTC
Created attachment 239691 [details]
NetworkManager-0.7.0-0.4.svn3020.fc8 log messages

NetworkManager messages from /var/log/messages, WPA Enterprise connection
attempt with pem certificates.

Comment 23 Charles R. Anderson 2007-10-26 23:09:36 UTC
Also tried on a new user account, same results.  BTW, these tests have been
using kernel- and madwifi-

Comment 24 Matt Bernstein 2007-10-29 13:48:34 UTC
(In reply to comment #18)
> If you could do a test with a fresh laptop, that would be awesome.  Thanks! 
> Make sure you get wpa_supplicant-0.5.7-13.fc8.

Yup, tried the rawhide-20071019-i686 live CD. "yum upgrade NetworkManager"
offered .5.svn3030 which installed without updating wpa_supplicant, so I'm now
more confident my laptop is OK.

I then downgraded to .4.svn3020 while upgrading wpa_supplicant to 0.5.7-13.fc8
and couldn't get it to work; I think I need to restart something other than
NetworkManager and wpa_supplicant, but rebooting a live CD isn't very helpful ;)

However, after installing from the live environment to hard drive and upgrading
to .4.svn3020 and 0.5.7-13.fc8 (and rebooting) it works as expected.

If I get time I'll look for more data points, and the PEM bits.

Comment 25 Charles R. Anderson 2007-10-29 21:52:37 UTC
Update: manual config in /etc/wpa_supplicant/wpa_supplicant.conf and calling
wpa_supplicant manually works with madwifi driver:


        pairwise=CCMP TKIP
        group=CCMP TKIP
        identity="Wireless User 07-08"

wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -ddd -K -iath0

I also added "-ddd -K" to
/usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service for
debugging when NM runs wpa_supplicant itself.

Right now I'm comparing log files between the two runs to see why NM fails.

I did notice that NM sets the gconf keys strangely:

group [wep40,wep104,tkip,ccmp,wep40,wep104,tkip,ccmp]
pairwise [tkip,ccmp,tkip,ccmp]
proto [wpa,rsn,wpa,rsn]

Why are these duplicated?  I tried deleting all but "tkip,ccmp" for the first
two keys since that mirrors what I have configured in the manual wpa_supplicant
case, but no dice.  BTW, I'm moving the manual wpa_supplicant.conf out of the
way and restoring the original when testing with NM.

Comment 26 Charles R. Anderson 2007-10-29 22:17:38 UTC
NM seems to fail to associate to the AP.  Here is an excerpt from
wpa_supplicant.log while NM is attempting to connect:

wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
Setting authentication timeout: 15 sec 0 usec
EAPOL: External notification - portControl=Auto
RSN: Ignored PMKID candidate without preauth flag
RSN: Ignored PMKID candidate without preauth flag
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b06 len=8
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b04 len=12
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b1a len=18
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b19 len=8
Received 1401 bytes of scan results (5 BSSes)
Scan results: 5
Selecting BSS from priority group 0
0: 00:0b:0e:0f:99:00 ssid='WPI-Wireless' wpa_ie_len=30 rsn_ie_len=26 caps=0x11
   skip - SSID mismatch
1: 00:0b:0e:47:26:41 ssid='WLAN6-Test' wpa_ie_len=30 rsn_ie_len=26 caps=0x11
   selected based on RSN IE
Already associated with the selected AP.
RSN: Ignored PMKID candidate without preauth flag
RSN: Ignored PMKID candidate without preauth flag

Here is the same thing that succeeds when I run wpa_supplicant manually.  You
can see that it associates and then starts EAPOL:

wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
Setting authentication timeout: 15 sec 0 usec
EAPOL: External notification - portControl=Auto
RSN: Ignored PMKID candidate without preauth flag
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b06 len=8
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b04 len=12
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b1a len=18
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:0b:0e:47:26:40
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
Associated to a new BSS: BSSID=00:0b:0e:47:26:40
No keys have been configured - skip key clearing
Associated with 00:0b:0e:47:26:40
WPA: Association event - clear replay counter
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
EAPOL: External notification - portEnabled=1
EAPOL: SUPP_BE entering state IDLE
EAP: EAP entering state INITIALIZE
EAP: maintaining EAP method data for fast reauthentication
EAP: EAP entering state IDLE
Setting authentication timeout: 10 sec 0 usec
Cancelling scan request

I don't know why in the NM case it just returns a list of scan results at the
point which it should associate to the AP.  It seems to get a different wireless
event in each case:

NM:     Wireless event: cmd=0x8b19 len=8
Manual: Wireless event: cmd=0x8b15 len=20

Comment 27 Charles R. Anderson 2007-10-30 00:00:38 UTC
Ok, there are multiple problems happening at once here.  madwifi is flaky
associating to APs, and ath5k doesn't like to transfer data (i.e. DHCP packets)
once associated and authenticated.  Those problems aside, NM is simply not
passing the certs correctly to wpa_supplicant, or wpa_supplicant isn't reading
them correctly.  I know this because the authentication phase works fine when
running wpa_supplicant manually (with either madwifi or ath5k), but fails with
SSL errors when run through NM.

If I use ath5k and run wpa_supplicant manually, I can successully associate and
authenticate to WPA: Key negotiation completed.

If I use ath5k, run NM, and pass separate PEM certs (public, private, CA), it
throws SSL errors.

If I use ath5k, run NM, and pass DER certs (public/private, CA) it throws SSL

The SSL errors end with:

OpenSSL: Failed to load private key
TLS: Failed to load private key '(null)'
TLS: Failed to set TLS connection parameters

Comment 28 Charles R. Anderson 2007-10-30 00:41:57 UTC
Created attachment 242521 [details]
wpa_supplicant.log, separate PEM certs, ath5k driver

Comment 29 Charles R. Anderson 2007-10-30 00:43:14 UTC
Created attachment 242531 [details]
wpa_supplicant.log, DER certs, ath5k driver

Comment 30 Charles R. Anderson 2007-10-30 00:44:52 UTC
Created attachment 242541 [details]
NM messages, separate PEM certs, ath5k driver

Comment 31 Charles R. Anderson 2007-10-30 00:45:48 UTC
Created attachment 242551 [details]
NM messages, DER certs, ath5k driver

Comment 32 Charles R. Anderson 2007-10-30 00:47:57 UTC
Created attachment 242561 [details]
working manual wpa_supplicant.log, PEM certs, ath5k driver

Comment 33 Charles R. Anderson 2007-10-30 00:49:13 UTC
Created attachment 242571 [details]
working manual wpa_supplicant.conf

Comment 34 Charles R. Anderson 2007-10-30 23:51:11 UTC
I was unable to get blob:// syntax in wpa_supplicant.conf to work with PEM
user_cert/private_key, but it works with P12 private_key (contains both
user_cert and private_key in one file).  Unfortunately, P12 isn't supported by
nm-applet.  Will continue testing with DER certs, but this is looking like it
may partially be a wpa_supplicant issue.

Comment 35 Dan Williams 2007-10-31 11:34:47 UTC
So it turns out that when using blobs, you have to decrypt the private key
before passing it to OpenSSL.  So I need to do a bit more work in the applet to
handle that.  Until then, configs that use encrypted private keys won't work...
 it's probably a day or two of work but I don't think it will hit F8 gold, but
as an update immediately thereafter.

Comment 36 Dan Williams 2007-10-31 15:22:17 UTC
changing the title to more accurately reflect the problem.  Should get fixed in
a couple of days but it won't hit F8 gold, which is locked down already.

Comment 37 Charles R. Anderson 2007-10-31 20:56:40 UTC
Should nm-applet be decrypting the private key blob, or should wpa_supplicant be
decrypting it like it does when it reads private keys off disk?  I vote for the
latter, since it makes sense to behave the same way when dealing with files or

Comment 38 Dan Williams 2007-11-01 13:30:01 UTC
Yes, we want the applet decrypting the private key blob.  We don't want to pass
the file all the way down to wpa_supplicant, because we don't want
wpa_supplicant reading all over the HD.  Furthermore, there are configurations
where, like NFS, root is denied from reading from NFS stores for security
reasons, and in that case the applet would have to decrypt the private key
anyway.  It's a lot easier to secure wpa_supplicant with stuff like SELinux if
it doesn't go around reading random user-specified files from who knows where on
the system.

Comment 39 Charles R. Anderson 2007-11-01 13:40:21 UTC
I don't see why wpa_supplicant would be reading files off disk--it can decrypt
the blob in memory as passed in by the applet.  We already pass the
private_key_password, so it already has everything it needs to decrypt it in
memory before passing it off to OpenSSL.

Comment 40 Dan Williams 2007-11-01 19:29:05 UTC
wpa_supplicant _can't_ decrypt it in memory.  It will only use the private key
password when you give it a file, not a blob.  This is because OpenSSL expects
decrypted private keys when using blobs, and can only decrypt a private key if
given a path to a file.  wpa_supplicant just passes the file through to OpenSSL
and sets the key callback.  Therefore, it's useless to pass the private key to
wpa_supplicant if you're using blobs.  The decryption has to happen before you
hit wpa_supplicant.

Comment 41 toni2 2007-11-01 22:52:45 UTC
I have tried rawhide-20071019-i686 live cd, with intel 3945 wireless.
I can see nm 0.7 but it doesn't show my wireless connection (it doesn't have any
encription). Nm shows a message like "you are disconnected" when gnome starts.

Comment 42 Dan Williams 2007-11-02 11:01:07 UTC
toni2: you'll probably need to try with a later livecd; there was an iwl3945 and
iwl4965 initialization bug that caused the device to not show up on boot that
was fixed last week.

Comment 43 toni2 2007-11-06 19:00:41 UTC
Yes, fedora 8 rc3 live cd works well with intel 3945 wireless.
Dan Williams: Thank you!

Comment 44 Fedora Update System 2007-11-29 01:44:04 UTC
NetworkManager-0.7.0-0.6.6.svn3109.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'

Comment 45 Charles R. Anderson 2007-11-29 04:27:54 UTC
I applied 0.7.0-0.6.6.svn3109.fc8 and all is well in WPA EAP-TLS land.  As I
mentioned in Comment #27, madwifi is still flakey and refuses to associate to
any WPA AP that I tried.  However, ath5k works beautifully.  ath5k associates,
NM/wpa_supplicant completes EAP-TLS authentication, DHCP gets an IP address, and
it transfers data.  A recent kernel update must have fixed the data
transfer/encryption issue with ath5k.

Thanks for all the hard work on this!

Comment 46 Fedora Update System 2007-12-03 05:35:43 UTC
NetworkManager-0.7.0-0.6.6.svn3109.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 47 Micko 2007-12-03 19:15:40 UTC
At my work they use WPA-Enterprice with PEAP and TKIP. Networkmamager just
doesn't work at all or even give me the option to choose any correct protocol. I
tried Ubuntu and SUSE also and they work perfect. Is this known and associated
with this bug report? When I used FC7 it connected but worked very poor. Slow
and soon disconnected. I use NetworkManager-0.7.0-0.5.svn3030.fc8

Comment 48 Dan Williams 2007-12-03 21:15:08 UTC
@micko: please update to NetworkManager-0.7.0-0.6.6.svn3109.fc8, which as the
comment just above your latest comment says, has been pushed to updates to fix
this problem.  It enabled PEAP functionality.

Comment 49 Micko 2007-12-04 17:38:53 UTC
(In reply to comment #48)
Dan, I took it to work today, some new features was showing up, PEAP among
others, but I could not choose TKIP. When I tried without it, just with
MSCHAPv2, it crashed at once when I was trying to connect. I guess its a bit
more to come. I'm sorry, I have no report to send. If you want me to, please
send instructions. 

Comment 50 Micko 2008-01-08 17:03:21 UTC
One month has passed, some updates came in yesterday but still TKIP dosen't
work. I'm I the only Fedora user suffering from this? 

Comment 51 Dan Williams 2008-01-08 17:21:29 UTC
Micko: can you do the following and test again?

yum update --enable-repo=updates-testing NetworkManager libnl wpa_supplicant

and report if that works or not?

Comment 52 Micko 2008-01-09 15:47:35 UTC
I tried today at work, but i could not connect. There are still no possibility
to choose TKIP. But NM did not crash anymore when I still tried to connect. Tell
me if I can be of help and I'll do my best. 

Comment 53 José Matos 2008-01-11 08:39:04 UTC
After the last update (from updates-testing) I was able to connect to a 
eduroam network. It was just after the last update, I tried Monday morning 
before the update and it always failed.

After the update I toggled the wireless button, removed the network cable and 
voilá the network was up and running.

Thanks. :-)

Comment 54 Micko 2008-01-11 10:17:41 UTC
New report from me. NM is working now :-) I tried it today without any
modification and to my surprise it just connected fine. I could not choose the
TKIP protocol, which is used at my network, but it still worked. So far its
working fine, I've been connected now for about 10 minutes. 

Comment 55 Micko 2008-01-11 10:59:37 UTC
Report again! No, it did only work for about 10 minutes and then it
dissconnected and it was not possible to reconnect again. Same behavior as in
FC7 NM. Maybe problems occur when network changes key? Again, this does not
happen in UbuntU or SUSE NM. Maybe it could be an idea to have a look how they
solved it? Some data from the network:

                    Frequency:2.437 GHz (Channel 6)
                    Quality=62/100  Signal level=-70 dBm  Noise level=-87 dBm
                    Encryption key:on
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : 802.1x
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : 802.1x
                    Bit Rates:5.5 Mb/s; 6 Mb/s; 9 Mb/s; 11 Mb/s; 12 Mb/s
                              18 Mb/s; 24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s

Comment 56 Micko 2008-01-30 23:26:55 UTC
Hello again! Please let me know if there is any work in progress to fix the NM?
I've been waiting now for many months to be able to use Fedora at work. I'm
starting to get a bit frustrated. Can you advice me? Is it better to change
disto? I just can't figure it out when I see Ubuntu and Suse NM working perfect.
Is there a completly new one in Fedora under development causing this? No
support for TKIP seems to be the main problem for me.

Comment 57 Charles R. Anderson 2008-01-31 01:08:35 UTC
The issue that I originally opened this bug report for has been fixed for many
months.  This bug has been closed in December.  If you are still having issues,
then please open a new bug.  Thanks.