Description of problem: Will not connect to LEAP Version-Release number of selected component (if applicable): 0.6.4 How reproducible: yes Steps to Reproduce: 1. Log into system. NetworkManager Prompts for credentials and Wireless network shows availble 2. Enter Credtials with LEAP Authentication- Network SSID changes to Null and signal strength still shows 3. Enter Connect to other network and with SSID, Credentials, and Leap and it will appear to connect and show IP 169.254.69.39 with 0% signal strength and Null connection with signal strength also still available. Actual results: will not connect to LEAP Expected results: Connect to LEAP network Additional info:
Created attachment 304966 [details] SOS report required by Ticket 826629
We do expect LEAP to work when using at least the ipw2x00 and ipw3945 drivers. Will work with Justin Jones to figure this out. A few questions though: 1) What wireless cards are you using? 2) What AP hardware are you using and what IOS version? 3) What RADIUS server are you using and what version? 4) Is this _original_ LEAP or WPA[2] using LEAP as the EAP method? 5) Have you tried connecting with plain wpa_supplicant, and if so, can you attach the wpa_supplicant config file that you were using? Thanks!
Looks like you've got a Cisco Aironet 340/350 card in the logs you attached... Also, you'll want to ensure that the 'dhcdbd' service is running by: /sbin/chkconfig --level 345 dhcdbd on /sbin/service dhcdbd start otherwise, NM won't be able to get a DHCP address and will fail the connection.
Yes it is the Aironet card in a Thinkpad T41P. I checked and the dhcdbd service is running. We use the Cisco 1200 series APs. I will have to get with our network guys for the ios and radius infomation. This is the original LEAP with 802.1x. I did a short test with wpa_supplicant and did not connect. I will do a little more testing and send the results.
Do you care about any other wireless hardware than Aironet cards? The only reason I ask about dhcdbd is that the logs indicated that it was not running in at least some of the connection attempts. Looking at the issue a bit more, I'm not necessarily sure that the airo driver will work with wpa_supplicant, because the airo does LEAP associations in firmware and you have to poke the LEAP username and password into specific registers in the card firmware. So I'm not surprised that it apparently fails with wpa_supplicant. Can you attach your wpa_supplicant config file? The reason I ask is that I'm still not quite sure whether you're using actual LEAP, or Dynamic WEP (802.1x) with EAP-LEAP. Config option soup, I know :)
The Network guys sent this for the Radius & IOS CiscoSecure ACS Release 4.1(4) Build 13 IOS at least 123-8.JA I created the test wpa_supplicant.conf with the dynamic WEP options. As part of the testing I hardcoded a good IP address so that may be the attemps where the dchpdb was ot running.
Created attachment 304977 [details] test wpasupplicant.conf
Other wireless cards include the Dell 4xx and 6xx laptops with Broadcom cards. That was going to be the next test after the T4x series IBMx. :)
The supplicant config file appears to use Dynamic WEP (802.1x) with EAP-LEAP, which is *good*. So you're not using actual LEAP, which means it has a hope of working with airo. Which _exact_ Broadcom cards do you have in those machines? Any way you could figure out which PCI IDs the cards use (a simple /sbin/lspci should tell you)? Also, do you have any Atheros-based cards that you care about, or not?
Yes there are atheros cards as well in the newer T4x series and other cisco wireless cards. Thanks
Billy: any chance you could get the output of /sbin/lspci on the machines you are looking to support so that I can verify what hardware/driver combinations you'd be using with RHEL? Thanks!
Created attachment 305166 [details] LSPCI Output Attached it three of the current wireless intallation lspci output lines. Thanks, Billy
Created attachment 305167 [details] LSPCI Output Attached it three of the current wireless intallation lspci output lines. Thanks, Billy
Billy: what's your priority ordering for these 3 wifi hardware types? Can you put them on a list of 1 - 3?
Billy: also, what's the output of 'rpm -qv NetworkManager' ? would be good to know exactly which version of NM you're using on those machines.
NetworkManager-0.6.4-7.el5 Priorities 1. Atheros 2. Broadcoms 3. 340/350 Not sure if this helps but, the Atheros has been tested with a PEAP and it connects. Fedora Core 9 has been tested and works.
Here are the results of my testing with RHEL 5.2. First though, you'll want NetworkManager-0.6.4-8.el5, which is availabe in the RHEL 5.2 release. Hardware: AP: Cisco AIR-AP1131AG RADIUS server: FreeRADIUS 1.1.7-3.1.fc8 DHCP server: Linksys WRT54GC Dell Latitude C610 with Broadcom 4306 Mini-PCI (internal) IBM Thinkpad X31 with Cisco Aironet 350 Mini-PCI (internal) and Cisco AIR-CB21AG (external CardBus) 1. Atheros: will not work out of the box, because there are no drivers for Atheros cards in the RHEL 5 kernel. This is because madwifi is not completely open-source, and requires linkage of a binary blob into the kernel, a potential violation of the GPL license. Red Hat appears to take a much stricter stance on the combination of GPL and GPL-incompatible code than other vendors do. Fedora 9 uses the ath5k driver, which is completely open-source. Filing an RFE request against RHEL 5 for a backport of the ath5k driver would probably be a good thing. In the mean time, you can use 3rd-party RPMs of madwifi to get Atheros cards working under RHEL 5, but of course these would not be supported by Red Hat directly. 2. Broadcom: My testing of a bcm4306kfb mini-pci card showed successful associations to a Dynamic WEP/IEEE802.1X authenticated network. But bcm43xx driver stability is highly dependent on which firmware version is installed and where you got it from. Where was the source for the firmware you installed onto your machines with the broadcom adapters? If you're able to send your firmware to me (privately of course) then I could test out some of our broadcom hardware with that specific firmware and see if there are issues with it. 3. Airo: failed without a backported bugfix to wpa_supplicant to allow the temporal keys to be loaded into the card without resetting the card's MAC. Packages with this fix are available here for testing (but are not supported by Red Hat at this time): http://people.redhat.com/dcbw/wpa_supplicant/ Please let me know if these work for you on your 'airo'-equipped machines. If so, we can proceed with getting the patch into official RHEL builds and through QA.
Clarification: when I said "Filing an RFE request against RHEL 5", I actually meant to say something like "Filing an Issue Tracker ticket with Red Hat support" with a request to backport ath5k to RHEL 5. I think there's already an open bug, but the more requests customers make the more it's on the radar and priority lists.
This should be fixed in RHEL 5.3. Please re-open if you still have problems, and we can diagnose.