Bug 489701 - Unable to connect to LEAP secured Network with hidden SSID
Unable to connect to LEAP secured Network with hidden SSID
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11Target
  Show dependency treegraph
 
Reported: 2009-03-11 10:25 EDT by Nigel Jones
Modified: 2009-11-18 15:38 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 15:38:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
kernel debug log (16.66 KB, text/plain)
2009-03-11 10:25 EDT, Nigel Jones
no flags Details
example output from iwlist wlan1 scanning (5.00 KB, text/plain)
2009-03-11 10:28 EDT, Nigel Jones
no flags Details
wpa supplicant log (4.00 KB, text/plain)
2009-03-11 11:16 EDT, Nigel Jones
no flags Details
initial scan results (5.00 KB, text/plain)
2009-03-23 05:34 EDT, Nigel Jones
no flags Details
iwconfig output before direct probe (461 bytes, text/plain)
2009-03-23 05:35 EDT, Nigel Jones
no flags Details
kernel output (no debug) (918 bytes, text/plain)
2009-03-23 05:37 EDT, Nigel Jones
no flags Details

  None (edit)
Description Nigel Jones 2009-03-11 10:25:49 EDT
Created attachment 334802 [details]
kernel debug log

Description of problem:

Unable to connect to LEAP secured Network with hidden SSID

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

NetworkManager-0.7.0.99-1.fc11.i586
kernel-PAE-2.6.29-0.215.rc7.fc11.i686
wpa_supplicant-0.6.7-4.fc11.i586

How reproducible:
Every time

Steps to Reproduce:
1. Configure network using NetworkManager GUI
 - Create new connection
 - Enter ssid/infrastructure/connect automatically on 1st tab
 - select LEAP / username / password on security panel
 - apply, close
2. Left click on NM icon, notice hidden network is NOT listed
3. Left click on NM -> connect to hidden network
 - Select profile configured above as the "connection" name
 - observe the (correctly) greyed out values for network name, security, username, password that look correct
 - click CONNECT
 - Immediately get bounced to "Authentication required by wireless network" dialog (again with correct values) -- this last panel pops repeatedly, and each time connect is clicked reappears in less than 1s
  
Actual results:
 * Hidden network not displayed in list 
 * Network cannot be connected to


Expected results:
 * Hidden network displayed in list (if preconfigured in profile -- same as WIndows, Symbian behaviour)
 * Connects successfully to ssid hidden LEAP network

Note: not sure if this is 2 problems or one... can raise another if requested.

It does not appear that any attempt is being made to connect, but rather there's some configuration issue

Additional info:
 * SSIDs in log have been obfuscated
 * system also has eth0 -- working correctly
 * kernel debug log & iwscan results will be attached
 * NM was started 14:05:10, attempt to connect to higgen network was at 14:06:40
Comment 1 Nigel Jones 2009-03-11 10:28:09 EDT
Created attachment 334803 [details]
example output from iwlist wlan1 scanning

*the iwscan was taken after the debug session
* The wifi in use is ath5k, but previously had this behaviour with iwl3945. I don't have these logs, but am able to swap mini-PCI cards if required to gather additional data.
* I have no access/control to the wifi network configuration (upstream)
* WPA2 PSK (AES) works fine at home
Comment 2 Nigel Jones 2009-03-11 10:46:33 EDT
I have repeated the above test, this time configuring the client for WPA Enterprise with EAP-TLS -- specifying an identify, user certificate, CA certificate, private key & private key password.

This fails at an earlier stage. In this case after clicking "connect to hidden wireless network", a dialogue pops up where the connection name to be used can be selected. I select the new network, and the name, security settings entered above appear in the dialog.

HOWEVER the "connect" button is greyed out at this point, and so no attempt to connect can be made. The kernel debug log has no new entries, suggesting that there is some incompatability between the scan results and the saved configuration, but
 * it is not clear what the descrepancy is (error message/feedback)
 * I do not believe the settings are incorrect.

I then attempted to start wpa_supplicant manually, and even though the "right" SSID was specified in the wpa config file, wpa_supplicant reports

0: 00:1b:90:74:34:40 ssid='' wpa_ie_len=24 rsn_ie_len=20 caps=0x11
   skip - SSID mismatch
1: 00:1b:90:75:db:60 ssid='' wpa_ie_len=24 rsn_ie_len=20 caps=0x11
   skip - SSID mismatch
2: 00:1b:90:74:35:c0 ssid='' wpa_ie_len=24 rsn_ie_len=20 caps=0x11
   skip - SSID mismatch
Try to find non-WPA AP
0: 00:1b:90:74:34:40 ssid='' wpa_ie_len=24 rsn_ie_len=20 caps=0x11
   skip - SSID mismatch
1: 00:1b:90:75:db:60 ssid='' wpa_ie_len=24 rsn_ie_len=20 caps=0x11
   skip - SSID mismatch
2: 00:1b:90:74:35:c0 ssid='' wpa_ie_len=24 rsn_ie_len=20 caps=0x11
   skip - SSID mismatch

This seems to suggest some issue with decoding the IE's? could be a wpa breakage? or out of spec AP? (cisco)
Comment 3 Nigel Jones 2009-03-11 11:16:08 EDT
Created attachment 334819 [details]
wpa supplicant log

Log from wpa supplicant

sudo /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -iwlan1 -Dwext -ddddd 2>&1 | tee /tmp/wpa.out2
Comment 4 Nigel Jones 2009-03-12 12:46:59 EDT
Sounds like the same scenario described in the mail chain here -> http://lists.shmoo.com/pipermail/hostap/2007-December/016772.html

AP supports multiple SSIDs which appear to be hidden
 - 1 is open
 - 1 is WPA2
Comment 5 Jessica Sterling 2009-03-14 22:28:59 EDT
This bug has been triaged.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Nigel Jones 2009-03-18 11:44:41 EDT
Occurs with iwl3945 also - identical behaviour.
Comment 7 James 2009-03-19 06:47:15 EDT
Similar problem with iwl3945, but when I plug in a zd1211-usb stick and connect to a hidden ssid, iwl3945 can do it too afterwards.

What I found out so far on my setup:

On Fedora 11 Alpha DVD install connecting to a

-hidden ssid with
-WPA2-PSK with
-iwl3945

worked for me with either wpa_supplicant (adding scan_ssid=1) or NetworkManager/nm-applet.
After an update it does not work anymore (SSID mismatch).

I updated to:

Name       : NetworkManager
Arch       : i586
Epoch      : 1
Version    : 0.7.0.99
Release    : 3.fc11

Name       : wpa_supplicant
Arch       : i586
Epoch      : 1
Version    : 0.6.8
Release    : 1.fc11

Name       : iwl3945-firmware
Arch       : noarch
Version    : 15.28.2.8
Release    : 3

Name       : kernel
Arch       : i586
Version    : 2.6.29
Release    : 0.258.rc8.git2.fc11

wpa_supplicant.conf:
---8<----------------------------

ctrl_interface=/var/run/wpa_supplicant GROUP=wheel

network={
        scan_ssid=1
        ssid="XXXXXXX"
        bssid=00:18:4d:BA:DB:AD
        psk="XXXXXXXXXX"
        group=CCMP
        pairwise=CCMP
        proto=RSN
        key_mgmt=WPA-PSK
}

---8<----------------------------

btw. I remember that I could not connect to a NETGEAR router who was setup to support both WPA-PSK and WPA2-PSK (no WPA-network something) but it worked after setting the router to allow only WPA2 (or WPA1).

I hope this helps

James
Comment 8 Nigel Jones 2009-03-23 05:34:11 EDT
Moving to iwl3945 component as following a discussion on the hostapd mailing list with NM/wpa maintainers there's a feeling that the driver is behaving incorrectly.

Thread is at http://lists.shmoo.com/pipermail/hostap/2009-March/019513.html

Specifically I tried this
 * stopping wpa_supplicant & NM
 * /sbin/rmmod iwl3945 -- to reset stuff
 * /sbin/iwlist wlan0 -- to show the 3 or 4 BSS's which are serving the hidden SSID network
 * /sbin/iwconfig wlan0 -- show config
 * /sbin/iwconfig wlan0 essid XXX -- to send a probe request

After this the network was still not listed.

wpa_supplicant will then report a network mismatch, and NM won't work either.

Adding new log files

I'll ping iwl maintainer to see if they can take a look? Thinking this is no longer an NM/wpa issue...
Comment 9 Nigel Jones 2009-03-23 05:34:47 EDT
Created attachment 336256 [details]
initial scan results
Comment 10 Nigel Jones 2009-03-23 05:35:16 EDT
Created attachment 336257 [details]
iwconfig output before direct probe
Comment 11 Nigel Jones 2009-03-23 05:37:05 EDT
Created attachment 336258 [details]
kernel output (no debug)
Comment 12 Nigel Jones 2009-03-23 05:43:18 EDT
From dmesg during the scan I can see
 * the direct scan requested
 * a choice of 11 channels chosen (1..11)
 * this taking just over 120ms per channel

The only log info from ch. 11 (which is the strongest correct AP) is
iwl3945: I iwl3945_rx_scan_start_notif Scan start: 11 [802.11bg] (TSF: 0x00000000:041CDE03) - 1 (beacon timer 2701148669)
iwl3945: I iwl3945_rx_handle r = 64, i = 63, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 65, i = 64, SCAN_RESULTS_NOTIFICATION, 0x83
iwl3945: I iwl3945_rx_scan_results_notif Scan ch.res: 11 [802.11bg] (TSF: 0x00000000:041EBE0C) - 3 elapsed=122889 usec (124ms since last)
iwl3945: I iwl3945_rx_handle r = 66, i = 65, SCAN_COMPLETE_NOTIFICATION, 0x84

Ramping up debug more I managed to get a response frame:

iwl data: 00000000: 80 00 00 00 ff ff ff ff ff ff 00 1b 90 74 34 40  .............t4@
iwl data: 00000010: 00 1b 90 74 34 40 e0 cf 8e 01 43 82 c6 00 00 00  ...t4@....C.....
iwl data: 00000020: 64 00 31 04 00 01 00 01 08 82 84 8b 0c 12 96 18  d.1.............
iwl data: 00000030: 24 03 01 0b 05 04 00 02 00 00 07 06 47 42 49 01  $...........GBI.
iwl data: 00000040: 0d 17 2a 01 00 30 14 01 00 00 0f ac 05 01 00 00  ..*..0..........
iwl data: 00000050: 0f ac 04 01 00 00 0f ac 01 28 00 32 04 30 48 60  .........(.2.0H`
iwl data: 00000060: 6c 85 1e 01 00 89 00 1f 00 ff 03 19 00 68 75 72  l............hur
iwl data: 00000070: 2d 61 70 2d 61 34 6c 36 30 00 00 00 00 02 00 00  -ap-a4l60.......
iwl data: 00000080: 27 dd 18 00 50 f2 01 01 00 00 50 f2 05 01 00 00  '...P.....P.....
iwl data: 00000090: 50 f2 02 01 00 00 50 f2 01 28 00 dd 06 00 40 96  P.....P..(....@.
iwl data: 000000a0: 01 01 00 dd 05 00 40 96 03 05 dd 05 00 40 96 0b  ......@......@..
iwl data: 000000b0: 09 dd 05 00 40 96 14 01 dd 18 00 50 f2 02 01 01  ....@......P....
iwl data: 000000c0: 81 00 03 a5 00 00 27 a5 00 00 42 54 bc 00 62 43  ......'...BT..bC
iwl data: 000000d0: 66 00

This is I think the right AP... but not a clue on interpretation. There's a few of these, as expected.

So we got a frame, but was the response what was needed? Ummm.
Comment 13 Nigel Jones 2009-03-23 05:47:43 EDT
Retested with kojii 2.6.29-0.267.rc8.git4.fc11.i686.PAE -- still occurs
Comment 14 John W. Linville 2009-03-23 15:19:34 EDT
Could you try dropping a file into /etc/modprobe.d/ that looks like this?

   options iwl3945 disable_hw_scan=1

Then reboot (or 'modprobe -r iwl3945; modprobe iwl3945')...does that make any difference for you?
Comment 15 Nigel Jones 2009-03-24 10:44:18 EDT
I made this change, reloaded driver, but unfortunately this made no difference. I still see "SSID mismatch" from wpa supplicant.
Comment 16 Nigel Jones 2009-03-25 06:43:47 EDT
Tried another test
 * cleared out all gconf/NM configuration
 * attempted to connect to hidden WLAN  with iwl3945 using NM
 * failed same as before
 * inserted a Zydas zd1211 wifi adapter 
 * attempted to connect with NM using same authentication data previously saved for iwl (this is using wpa enterprise/LEAP)
 * Zydas adapter connected fine.
 * removed zydas adapter
 * repeated connection attempt this time using iwl3945
 * connected fine (although sometimes it takes an agem and may need attempting more than once as NM times out)

As an aside I also tried wpa_supplicant with EAP-TLS (since I think NM itself is still causing issues with digital certs). **THIS ALSO CONNECTED FINE**

I then reloaded the driver and again could connect fine.

Umm... definately some kind of scanning issue. Maybe I was able to connect afterwards as the BSS had been saved by NM?

Need some guidance on simple specific tests to ping down the issue -- still too many variables.
Comment 17 Nigel Jones 2009-03-25 07:19:49 EDT
Same behaviour repeated after reboot.

No connectivity with iwl initially.
Zydas connected just fine and quickly
With zydas removed, iwl was then able to connect (but more slowly)
Comment 18 Dan Williams 2009-03-25 11:26:53 EDT
Any chance you know what model your Cisco APs are?

In any case, for reference, I set up a Cisco AIR-AP1131-AG yesterday with the intention of trying to debug these sort of hidden SSID problems.  The AP was set up with "Guest SSID" mode on, and the main SSID as the 802.1x-authenticated SSID.

Initial scans showed the "guest mode" SSID being broadcast from the AP.  Doing a probe-scan for the main SSID replaced the "guest mode" SSID entry in the scan result list (same BSSID!) with the SSID and security settings for the main SSID.  Yay for cisco.

Haven't tried pure hidden Cisco SSID yet, but will.
Comment 19 Nigel Jones 2009-03-25 13:38:45 EDT
I don't. will try to find out. Won't be able to test again for a week as will be out of the office.

Note that NM *did* work today in conjunction with the Zydas adapter. It was the iwl3945 that floundered?
Comment 20 Stefan Becker 2009-03-28 07:12:06 EDT
I can confirm the problem with iwl3945 (Lenovo T60) and iwlagn (Clevo M860TU, smolt <http://www.smolts.org/client/show/pub_0f1188c8-b2ed-454d-8eb2-e821375598b6>).

If NM can't create connection after bootup then a modprobe -r & modprobe will fix the issue for me.

Additionally I followed Dan's advice to add disable_hw_scan=1. Now finally all my problems with long scan times are gone. Thanks, you're a lifesaver!!!


I still have to verify with the WPA2 EAP non-hidden APs at work on Monday. The iwl3945 had problems with that too on F11 rawhide.
Comment 21 Nigel Jones 2009-03-31 08:14:47 EDT
Now using kernel-PAE-2.6.29-16.fc11.i686
Using LEAP, iwl3945 would not connect even after reloading or with disable_hw_scan
Plugged in Zydas USB and connected fine within 3s. No tweaking, same NM/wpa supplicant configuration, same AP -- just worked.
(Amazing since that USB key I don't use anymore as it never worked great on windows...)

Conclusion - iwl3945 broken for my AP config. (worked under previous fedora, think it was 10, could have been 9)
Comment 22 Nigel Jones 2009-04-16 05:36:51 EDT
Occasional success with latest kernels (probably 1 in 10 or so) when disable_hw_scan is in use, so minor improvement on before when I could *never* connect, but still effectively not working.

Kernel now at 2.6.29.1-85
Comment 23 James 2009-04-30 12:48:24 EDT
Fedora-11 Preview DVD works for me

-hidden ssid with
-WPA2-PSK with
-iwl3945

James
Comment 24 James 2009-04-30 12:50:06 EDT
sorry, Live CD, DVD not tested
James
Comment 25 Nigel Jones 2009-04-30 15:34:48 EDT
Still wasn't working here today.

I *very occasionally* can persuade it to connect after running this a few times
!/bin/sh
sudo /sbin/service NetworkManager stop
sleep 5
sudo /sbin/rmmod iwl3945
sleep 3
sudo /sbin/modprobe iwl3945
sleep 3
sudo /sbin/service NetworkManager start

That's probably 1 in 25 times. Also on occasion this has caused a panic (not reported yet)

It may be something specific to the IEs  for this particular network rather than just the hidden nature. I've added scan results above if that helps?
Comment 26 Nigel Jones 2009-05-06 18:24:10 EDT
Suspect this may be addressed by
https://bugzilla.redhat.com/show_bug.cgi?id=498719
or
https://bugzilla.redhat.com/show_bug.cgi?id=498263 (protected)

[same infrastructure]

will test once F11 patches available.
Comment 27 Nigel Jones 2009-05-14 15:02:42 EDT
Tried with
wpa_supplicant-0.6.8-4.fc11.i586
kernel-PAE-2.6.29.3-142.fc11.i686
NetworkManager-0.7.1-4.git20090414.fc11.i586

both with disable_scan_1 & without

But unable to connect consistently (iwl3945)

Also noted that whilst testing after several attempts to rmmod/insmod iwl3945 I hit a kernel panic. However same problem after boot.

Don't have a dump so haven't opened bug on that.
Comment 28 Nigel Jones 2009-05-20 02:14:40 EDT
A recent wpa/kernel change (~2 weeks ago) appears to have made manual connection via wpa_supplicant work with EAP-TLS. However NM still fails.

I've switched to using wicd, which after 24 hours is looking promising (except that it is not shipped with F11). Once configured with security & told to connect once to the hidden SSID it then appears to reliably connect. (I did also need to tweak the template it uses)

Suggests an outstanding problem with NM
Comment 29 thomas.swan 2009-05-28 17:17:55 EDT
This may be related.  I have a 4965 card, and I can only see hidden SSID PEAP protected networks if I enable asmdu_size_8K=1 on my iwlagn module.  I still cannot connect to the PEAP protected network due to other problems.  This is running 2.6.29.4-170 on Fedora 11 (Preview Release).  I have been unable to see or join any hidden wireless networks (protected or open) since trying the new F11 PR.
Comment 30 thomas.swan 2009-06-02 12:17:25 EDT
Correction, 2.6.29.4-162 and 2.6.29.4-167 are the most recent kernel versions where I am seeing this.  Hidden networks worked correctly on FC10 on the same hardware.
Comment 31 Bug Zapper 2009-06-09 08:08:14 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 32 Dan Williams 2009-11-11 11:46:00 EST
How are we doing on this bug with latest F11 kernel versions?  Latest is 2.6.30.9-96.fc11.  The reason I ask is because scanning and hidden SSID detection is *highly* driver dependent, and I'm very curious if 2.6.30 has made this issue any better.
Comment 33 Nigel Jones 2009-11-18 05:08:29 EST
This problem no longer occurs with F12 gold and may be closed. 
Basically LEAP appears to work reliably (although to be honest I dare not touch the configuration) -- I ended up re-enabling hw scanning as otherwise I'd loose wireless for a few seconds during a rescan.

 Thanks.
Comment 34 Dan Williams 2009-11-18 15:38:56 EST
Ok, if it magically works in F12 I suspect driver fixes, since that part of the code hasn't really changed in NM recently.

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