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

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)

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

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

This bug has been triaged.

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

Occurs with iwl3945 also - identical behaviour.

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

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...

Created attachment 336256 [details]
initial scan results

Created attachment 336257 [details]
iwconfig output before direct probe

Created attachment 336258 [details]
kernel output (no debug)

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.

Retested with kojii 2.6.29-0.267.rc8.git4.fc11.i686.PAE -- still occurs

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?

I made this change, reloaded driver, but unfortunately this made no difference. I still see "SSID mismatch" from wpa supplicant.

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.

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)

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.

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?

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.

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)

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

Fedora-11 Preview DVD works for me

-hidden ssid with
-WPA2-PSK with
-iwl3945

James

sorry, Live CD, DVD not tested
James

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?

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.

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.

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

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.

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.

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

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.

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.

Ok, if it magically works in F12 I suspect driver fixes, since that part of the code hasn't really changed in NM recently.