Red Hat Bugzilla – Bug 410931
Network Manager fails to connect to hidden SID wireless network with WPA Enterprise using PEAP
Last modified: 2008-01-10 18:36:45 EST
Description of problem:
Supplying credentials to nm-applet causes some delay, then nm-applet returns
asking for access credentials and/or certs.
Version-Release number of selected component (if applicable):
[root@lapster /]# rpm -qa |egrep "NetworkM|wpa_sup"
[root@lapster /]# uname -a
Linux lapster.4wx.net 184.108.40.206-63.fc8 #1 SMP Wed Nov 21 18:51:08 EST 2007 i686
i686 i386 GNU/Linux
Try connecting to a ESSID that is hidden running wpa and PEAP authentication.
Steps to Reproduce:
1. start nm-applet (from system tray)
2. connect to other wireless network
3. NetworkName: Populated
4. Wireless Security: WPA & WPA2 Enterprise
5: Authentication: Protected EAP (PEAP)
6: Anonymous Identiity: <blank>
7: CA Cert: (None)
8: PEAP Version: Version 1
9: Inner Authentication: MSCHAPv2
10: User Name: mine
11: Password: mine
12: Click Connect
13: Click Ignore (for the lack of CA Cert dialog)
14: suffer :(
Error asking for credentials when correct credentials have been supplied.
A connection to the wireless network is created.
This same hardware works and is able to access the wireless network using
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network
Connection (rev 02)
Subsystem: Intel Corporation Unknown device 1020
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 219
Region 0: Memory at efdff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Address: 00000000fee0300c Data: 414a
Capabilities: [e0] Express Legacy Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <512ns, L1 unlimited
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0
Link: Latency L0s <128ns, L1 <64us
Link: ASPM L1 Enabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
iwlwifi drivers are known to have problems with hidden SSIDs at this time,
because they do not support the ap_scan=2 option with wpa_supplicant... we
could make sure this is the case though. Are you familiar with wpa_supplicant's
config file format?
Somewhat. What do you have in mind?
constructing a wpa_supplicant.conf file that will connect to your network, then
playing around with ap_scan=1 and ap_scan=2 to determine whether this is
actually the cause of your problem with iwl3945. It's pretty much known not to
work with hidden SSIDs and ap_scan=2 already, but doesn't hurt to nail it down
before handing off to the kernel team to fix the driver. Let me know if you'd
like to do this.
Created attachment 277351 [details]
syslog messages on working wireless config
I'm attaching this to aide in configuring a matching wpa_supplicant.conf file
Okay, I'm working on creating a wpa_sup.conf file that I'll attach here. At
that point I'll need some guidance.
sure, let me know, happy to help.
Okay, here is my tentative /etc/wpa_supplicant/wpa_supplicant.conf file:
Looks good. Kill NetworkManager, then wpa_supplicant. Then run wpa_supplicant
/usr/sbin/wpa_supplicant -ddd -i wlan0 -D wext -c /path/to/your/wpa_supplicant.conf
You're looking for the string COMPLETED in there. in any case, email me the
log. YOu probably don't want to attach it as some private network details may
The following wpa_supplicant.conf file gets me onto the network. Running
dhclient gets me an IP address and everything seems to be working.
Do you still want the wpa_supplicant output emailed to you?
I'm going to speculate this is a simply a matter of getting NetworkManager to do
the right thing when using PEAP without certs. Please ping me on IRC if you
would like me to try a new NetworkManager build.
*** This bug has been marked as a duplicate of 373841 ***