Created an attachment (id=727) [details]
Used wpa_supplicant config

Created an attachment (id=728) [details]
Debug output of wpa_supplicant

The messages show that no AP gets selected. The wanted AP is 00:0b:86:c2:11:e2.

Created an attachment (id=729) [details]
Debug messages from ipw3945

Created an attachment (id=732) [details]
Add ability to do single direct scan in response to IW_SCAN_THIS_SSID

Please try this patch against 0.0.71.  It adds support to scan for a single
SSID in response to the IW_SCAN_THIS_SSID flag.

Bumped to P1 and marking as Fixed (patch merged for 0.0.71)  Please let me know
if the patch doesn't fix the problem in your environment.

The patch works in principle, thanks. But there is a strange problem: Once 
associated to a hidden WPA AP, I can't connect to another AP anymore without 
reloading the driver. 

There was a bug in the patch that would cause non-direct scans to fail (so if
you don't have an ssid configured or aren't using scan_ssid=1).  A new patch has
been merged for 0.0.72 that corrects the behavior. 

I cannot connect via wpa_supplicant to hidden APs with 0.0.72 or 0.0.73. The 
wpa_supplicant debug output looks the same like 0.0.71 without your patch. 

I'm using wpa_supplicant v0.4.7 with ipw3945-0.0.73 and it is able to associate
with a WPA-PSK access point that has its SSID broadcast disabled:

% modprobe ipw3945
% iwlist scan
...
          Cell 02 - Address: 00:12:17:A6:C2:5D
                    ESSID:"<hidden>"
                    Protocol:IEEE 802.11b
                    Mode:Master
                    Channel:11
                    Encryption key:on
                    Bit Rates:11 Mb/s
                    Extra: Rates (Mb/s): 1 2 5.5 11
                    Quality=92/100  Signal level=-38 dBm  Noise level=-38 dBm
                    IE: WPA Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : PSK
                    Extra: Last beacon: 184ms ago
% cat /etc/wpa_supplicant.conf
ctrl_interface_group=0
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=1
fast_reauth=1

network={
        scan_ssid=1
        ssid="hidden-b"
        psk="the quick brown fox jumped over the lazy dog"
        priority=1
        proto=WPA
        key_mgmt=WPA-PSK
        pairwise=TKIP CCMP
}
% wpa_supplicant -ieth1 -Dwext -c/etc/wpa_supplicant.conf
Trying to associate with 00:12:17:a6:c2:5d (SSID='hidden-bi' freq=0 MHz)
Associated with 00:12:17:a6:c2:5d
WPA: Key negotiation completed with 00:12:17:a6:c2:5d [PTK=CCMP GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:12:17:a6:c2:5d completed (auth)
<ctr-z>
% bg
% dhcpcd eth1
% ping -I eth1 192.168.1.1
PING 192.168.1.1 (192.168.1.1) from 192.168.1.241 eth1: 56(84) bytes of data
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=5.79ms
...

Can you attach the debug kernel output with the driver set to a debug level of
0x800 from load until the association fails:

% modprobe ipw3945
% echo 0x800 > /sys/bus/pci/drivers/ipw3945/debug_level
% wpa_supplicant ...

Thanks,
James

Created an attachment (id=740) [details]
ipw3945 debug messages

'iwlist scan' does show the access point, but it's on channel 13, which is
listed as 'passive' in the log. Could that be a problem?

(In reply to comment #10)
> Created an attachment (id=740) [edit] [details]
> ipw3945 debug messages
> 
> 'iwlist scan' does show the access point, but it's on channel 13, which is
> listed as 'passive' in the log. Could that be a problem?

Yes -- that would keep it from working.

In order to find a hidden network, a probe request containing the network name
must be sent for from the laptop.  Doing that requires the channel not be marked
as passive only.  Does it work if you move the AP to an active channel?

I cannot easily move the AP to another channel. Association to an unencrypted 
AP on another channel using wpa_supplicant works, which should suffice for this 
particular test I think. Interestingly association works with the patch you 
attached to this bug, even though channel 12 and 13 are marked as passive as 
well. 

I have tested with 0.0.74 , our AP is asus channel 4(active)
I load the driver with debug level 0x800 (IPW_DL_SCAN)
the DUT can't associate with a hidden AP when using WPA PSK.
the wpa config file and kernel log can be found in attachment.

Created an attachment (id=760) [details]
kernel log

Created an attachment (id=761) [details]
WPA_PSK_TKIP.conf

(In reply to comment #13)
> I have tested with 0.0.74 , our AP is asus channel 4(active)
> I load the driver with debug level 0x800 (IPW_DL_SCAN)
> the DUT can't associate with a hidden AP when using WPA PSK.
> the wpa config file and kernel log can be found in attachment.

when I turned on the broadcast, the machin can associate with the AP. 

Reassigning to Hong

(In reply to comment #15)
> Created an attachment (id=761) [edit] [details]
> WPA_PSK_TKIP.conf

network={
        scan_ssid=1
        ^^^^^^^^^^^ would you please add this line to the wpa_supplicant.conf 
                    file, and see if the problem will be solved?
        ssid="ipwasus"
        proto=WPA
        key_mgmt=WPA-PSK
       	pairwise=TKIP
        group=TKIP WEP104 WEP40
        psk="sharedsecret"
#        priority=2
}

(In reply to comment #18)
> (In reply to comment #15)
> > Created an attachment (id=761) [edit] [details] [edit]
> > WPA_PSK_TKIP.conf
> network={
>         scan_ssid=1
>         ^^^^^^^^^^^ would you please add this line to the 
wpa_supplicant.conf 
>                     file, and see if the problem will be solved?
>         ssid="ipwasus"
>         proto=WPA
>         key_mgmt=WPA-PSK
>        	pairwise=TKIP
>         group=TKIP WEP104 WEP40
>         psk="sharedsecret"
> #        priority=2
> }

I have added this line in the config file and test many times, the DUT can 
successfully associate with the hidden AP and only several times failed. 

Based on the comment #12 and comment #19, mark as fixed and verify this bug.
If anyone still finds this bug, please reopen.

I still have problems when trying to associate to a hidden 11a access point. 
The problem looks equal, the AP does only show up as 'hidden' in the scan 
results. The AP is on an active channel. Connecting without wpa_supplicant or 
using ap_scan=2 works. I'm using ipw3945 version 1.0.3.

Is everything works fine if ap_scan is used? If ap_scan is not used, does the 
problem persists? Is there a reason ap_scan can't be used in his environment?

ap_scan=2 could be used, of course. But it has the disadvantage when using WPA, 
the user needs to specify WPA protocol and ciphers to be used, otherwise the 
driver may not be able to select the right AP. And it works with 11g, so I see 
no constraining reason why it shouldn't work with 11a as well.

I have some more information. The direct scanning of the 11a band seems to work 
when calling 'iwpriv set_mode 1'. I guess in abg mode the driver does a direct 
scan only in the 2.4 GHz band, and performs indirect scanning in the 5 GHz band 
afterwards, and therefore does not find the AP. Is this possible?

Created an attachment (id=855) [details]
patch to try

(In reply to comment #24)
> I have some more information. The direct scanning of the 11a band seems to work 
> when calling 'iwpriv set_mode 1'. I guess in abg mode the driver does a direct 
> scan only in the 2.4 GHz band, and performs indirect scanning in the 5 GHz band 
> afterwards, and therefore does not find the AP. Is this possible?

Thanks for the info. Please try the attached patch.

Merged for 1.1.2

I verified this bug on ieee80211 version 1.2.16 and ipw3945 version 1.2.0dm.

I added the line "scan_ssid=1" to the WPA_PSK_TKIP.conf. The DUT can 
successfully associate with the hidden AP(asus2-ven).
If anyone still encounters this problem, please reopen the bug.

Hi, I'm having the same problem with a routertech.org firmware if "Hidden SSID"
is checked.
I can succesfully if it's not hidden (without changing configuration) or if I
try with another Access Point (which hide SSID).

Within Windows it works well.

I'm running a Slackware current with followings
wpa_supplicant 0.5.7
ipw3945d 1.7.22
ieee 1.2.16

(In reply to comment #30)
> Hi, I'm having the same problem with a routertech.org firmware if "Hidden SSID"
> is checked.
> I can succesfully if it's not hidden (without changing configuration) or if I
> try with another Access Point (which hide SSID).

can you attach your wpa_supplicant.conf and log?

Hi,

I cannot associate with a Netgear WPN802 if "Broadcast SSID" is unchecked and
ap_scan is 1. (It works if it is "2", but it takes up to five minutes...)

I use a Thinkpad T60p with:
ipw3945 1.2.0
ucode 1.14.2
ipw3945d 1.7.22
kernel: 2.6.19-gentoo-r5

My wpa_supplicant.conf:
ap_scan=1

network={
        ssid="afXXXXX"
        proto=WPA
        key_mgmt=WPA-PSK
        pairwise=TKIP
        group=TKIP
        psk="XXXXXXXXXXX"
        priority=10
}

network={
        ssid="XXXXXXX"
        key_mgmt=NONE
}


I will create attachments with:
- Associating when "Broadcast SSID" is on
- Associating when "Broadcast SSID" is off (doesn't work)
- Associating when "Broadcast SSID" is off and scan_ssid=1 (doesn't work)

MAC adresses etc. have been removed to protect the innocent.

Let me know if you need more information.
Any help is really appreciated.

Thanks,
Mitch

Created an attachment (id=1006) [details]
Association if SSID is being broadcast (works)

Created an attachment (id=1007) [details]
Association if SSID is hidden (doesn't work)

Created an attachment (id=1008) [details]
Association if SSID is hidden and scan_ssid=1 (doesn't work)

Yes, I found this issue happened on our environment.
My testing env is :
   kernel:2.6.20-rc3
   driver: 1.2.0d
   wpa_supplicant: 0.5.7

WPA_PSK_TKIP.conf:
*********************
#ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=1

network={
        scan_ssid=1
        ssid="netgear-ven"
        proto=WPA
        key_mgmt=WPA-PSK
        pairwise=TKIP
        group=TKIP WEP104 WEP40
        psk="ipwtest1"
#        priority=2
}
**********************

No any response during trying to connection. 

BTW, if AP broadcasts its' essid, wpa can be connected smoothly. 

Created an attachment (id=1036) [details]
log from wpa_supplicant

I'm using
ipw3945 1.2.0
ipw3945d 1.7.22
wpa_supplicant 0.5.7
the ieee80211 from kernel 2.6.19.2

and a linksys WRT54GC AP with the SSID broadcast disabled.

If I enable SSID broadcast, it associates immediately. In windows, it works
fine (even with SSID broadcast disabled).

I'm attaching the result of /sbin/wpa_supplicant
-c/etc/wpa_supplicant/wpa_supplicant.conf  -ieth1 -dd 2>&1 >wpa_supplicant.log

my wpa_supplicant.conf is the following:

network={
	key_mgmt=NONE
	priority=0
}

network={
	ssid="collabora"
	scan_ssid=1
	priority=20
	key_mgmt=NONE
}

I am experiencing this issue as well on an FSC Amilo Si1520 trying to connect to
a FRITZ!Box Fon WLAN 7050 (UI), Firmware-Version 14.04.31 set to g+b and WPA2(CCMP)

OS is openSuSE 10.3 alpha3plus (Kernel 2.6.21-rc7-3-default), wpa_supplicant is
0.5.7-8, ipw3945 is 1.2.0_2.6.21_rc7_3.3

I can connect with network name broadcast without problem, no way to make it
with hidden SSID. I noted that there are other APs around with hidden SSID.

/etc/wpa_supplicant.conf is:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=10
ap_scan=2
update_config=1

network={
#	scan_ssid=1
	ssid="<hidden>"
	psk="mysecretpassphrase"
	proto=RSN
	key_mgmt=WPA-PSK
	pairwise=CCMP
}

I tried it with and without scan_ssid to no avail.

Created an attachment (id=1042) [details]
Output from wpa_supplicant with scan_ssid off

Created an attachment (id=1043) [details]
Output from wpa_supplicant with scan_ssid on

Created an attachment (id=1044) [details]
output from iwlist scan

The AP in question is:

	  Cell 13 - Address: 00:04:0E:A4:4F:A7
		    ESSID:"<hidden>"
		    Protocol:IEEE 802.11bg
		    Mode:Master
		    Channel:3
		    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; 22 Mb/s; 24 Mb/s
			      36 Mb/s; 48 Mb/s; 54 Mb/s
		    Quality=90/100  Signal level=-41 dBm  Noise level=-41 dBm
		    IE: IEEE 802.11i/WPA2 Version 1
			Group Cipher : TKIP
			Pairwise Ciphers (1) : TKIP
			Authentication Suites (1) : PSK
		    Extra: Last beacon: 1188ms ago

Not sure whether this has any significance related to the discussed issue:

workstation6l:/home/cjp # iwlist scan > Desktop/iwlistscan.log
lo        Interface doesn't support scanning.

eth0      Interface doesn't support scanning.

Warning: Driver for device eth1 has been compiled with version 22
of Wireless Extension, while this program supports up to version 21.
Some things may be broken...

Jun, any update/idea?

ipw3945 as a driver has been replaced by iwl3945 in official kernel for a long
time. We suggest to use iwl3945 driver instead of the obsolete ipw3945 driver.
If you have bug, please report it with product=iwlwifi and platform="Intel(R)
Wifi Link 3945". Thanks so much!