Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1736 (new defect)

Opened 11 years ago

Last modified 11 years ago

Association problem with 802.11a hidden/non broadcasted APs

Reported by: julien.boibessot@free.fr Assigned to:
Priority: minor Milestone:
Component: madwifi: other Version: v0.9.3.3
Keywords: Cc:
Patch is attached: 0 Pending:

Description

Hi,

I have found some problems with Madwifi when trying to associate with 802.11a access points, which are configured to not broadcast their SSID. As soon as I activate broadcasting, my stations are able to associate. If I switch my APs from 802.11a to 802.11g, association is working fine too, even if SSID is hidden.

Do anybody have an idea what's going on with 802.11a and "non-broadcasting"?

Here is my configuration:
APs: Cisco, D-Link, Colubris
Stations: ARM and x86 Linux systems (2.6.12 and 2.6.20 kernels) with Atheros 5212 a/b/g based mini-PCI modems
Madwifi: 0.9.3.3 & 0.9.2 versions
wpa-supplicant: 0.5.6 & 0.5.9
security: none, WEP, WPA2
All the combinations failed to associate in 802.11a mode with wpa_supplicant or manually. Same configurations with an Intel Pro Wireless a/b/g based modem (=not using MadWifi) are working.

Julien

Change History

(follow-up: ↓ 3 ) 01/17/08 05:44:40 changed by mrenzmann

Does association work without wpa_supplicant when you set your APs to "no encryption" and disble SSID broadcasts?

(follow-up: ↓ 4 ) 01/17/08 10:37:43 changed by ugly.p.mouse@gmail.com

You may also try to tune wpa_supplicant config: ap_scan=2, and use explicit security configuration. Check wpa_supplicant home page for more info.

It is most propably related to passive mode. In passive mode, Probe requests are not sent by Station. G allows probes, but for example A mode in most of the European countries does not (FCC Regulation allows probes, since there is no DFS requirement yet (US)).

Does anyone know if it's against the standard to use probes in regulation where DFS is required.

(in reply to: ↑ 1 ; follow-up: ↓ 5 ) 01/17/08 22:24:06 changed by julien.boibessot@free.fr

Replying to mrenzmann:

Does association work without wpa_supplicant when you set your APs to "no encryption" and disble SSID broadcasts?

No, when I try it "manually" with iwconfig & Co, no encryption, 802.11a mode and no SSID broadcast -> it's not working.

(in reply to: ↑ 2 ; follow-up: ↓ 6 ) 01/17/08 22:35:28 changed by julien.boibessot@free.fr

Replying to ugly.p.mouse@gmail.com:

You may also try to tune wpa_supplicant config: ap_scan=2, and use explicit security configuration. Check wpa_supplicant home page for more info.

Thanks for the tip but I already tried "ap_scan=2" without success. "ap_scan=2" is working with other hardware like Intel Pro Wireless 3945 ABG. but in that case I use "-Dwext"/Linux Wireless Extensions driver and not "-Dmadwifi"/MadWiFi.

I was told to use "ap_scan=1" with MadWifi but it doesn't work neither.

I have the problem even if the APs are configured with "no security".

(in reply to: ↑ 3 ; follow-ups: ↓ 8 ↓ 12 ) 01/18/08 06:25:07 changed by mrenzmann

Replying to julien.boibessot@free.fr:

No, when I try it "manually" with iwconfig & Co, no encryption, 802.11a mode and no SSID broadcast -> it's not working.

It might be a dumb question, but: are you sure that the WLAN cards you use in your clients have 11a support?

Can you try athdebug/80211debug, with athdebug flags +beacon and 80211debug flags +assoc +scan?

(in reply to: ↑ 4 ; follow-up: ↓ 9 ) 01/18/08 06:26:49 changed by mrenzmann

Replying to julien.boibessot@free.fr:

but in that case I use "-Dwext"/Linux Wireless Extensions driver and not "-Dmadwifi"/MadWiFi.

-Dwext is the preferred wpa_supplicant driver for MadWifi, at least with recent versions of MadWifi and wpa_supplicant. Try if that helps.

(follow-up: ↓ 10 ) 01/18/08 11:16:11 changed by úgly.p.mouse@gmail.com

I'm still quite sure that AP is using a countrycode that does use passive channels e.g probe reguests are not sent by wpa_supplicant.

At this point the wpa_supplicant does not send authentication request to AP...seen this behavior. You can check this by sniffing the traffic and checking if probe requests are sent by supplicant.

(in reply to: ↑ 5 ) 01/20/08 20:47:33 changed by julien.boibessot@free.fr

Replying to mrenzmann:

Can you try athdebug/80211debug, with athdebug flags +beacon and 80211debug flags +assoc +scan?

Ok I will try to gather these informations and let you know... Thanks

(in reply to: ↑ 6 ) 01/20/08 20:48:53 changed by julien.boibessot@free.fr

Replying to mrenzmann:

-Dwext is the preferred wpa_supplicant driver for MadWifi, at least with recent versions of MadWifi and wpa_supplicant. Try if that helps.

Using -Dwext doesn't solve the issue... sorry

(in reply to: ↑ 7 ) 01/20/08 20:52:39 changed by julien.boibessot@free.fr

Replying to úgly.p.mouse@gmail.com:

You can check this by sniffing the traffic and checking if probe requests are sent by supplicant.

Could you tell me a good sniffer (preferably running on Linux) I could start with ??

Thanks !

01/21/08 18:59:08 changed by ugly.p.mouse@gmail.com

  • Get wireshark (formely called ethereal)
  • AP with WPA2/suppressed ssid, check the channel you are operating in
  • wpa_supplicant properly configured
  • Setup one card to operate in monitor mode (set monitor interface to ath1 for example): UserDocs/MonitorModeInterface
  • Use tcpdump to sniff traffic: tcpdump -n -i ath1 -s0 -x -w /path/snifflog.cap
  • output is saved to file snifflog.cap, which can easily be opened with wireshark

When sniffing, try to associate to hidden ssid AP. Check if wpa_supplicant is sending probe requests or trying to authenticate to AP.

(in reply to: ↑ 5 ) 01/27/08 22:26:46 changed by julien.boibessot@free.fr

Replying to mrenzmann:

Can you try athdebug/80211debug, with athdebug flags +beacon and 80211debug flags +assoc +scan?


Working case (ESSID broadcasted):


17180635.820000] ath0: ieee80211_check_scan: active scan, duration 2147483647, desired mode 11a, append
17180635.820000] ath0: sta_pick_bss Checking scan results
17180635.820000] ath0:  macaddr          bssid         chan  rssi  rate flag  wep essid
17180635.820000]  010 - 00:19:a9:5b:d5:d0 00:19:a9:5b:d5:d0   64   +47 54M   ess no  0x00!
17180635.820000]  000 + 00:19:a9:5b:d5:d0 00:19:a9:5b:d5:d0   64   +45 54M   ess no  "JUJU"
17180635.820000] ath0: [00:19:a9:5b:d5:d0] assoc success: long preamble, short slot time, QoS
17180635.820000] ath_beacon_config: nexttbtt 500 intval 100 (100)
17180635.820000] ath_beacon_config: tsf 1044650210 tsf:tu 1020168 intval 100 nexttbtt 1020200 dtim 200 nextdtim 1020300 bmiss 7 sleep 100 cfp:period 200 maxdur 0 next 1020300 timoffset 0
17180635.820000] ath0: [00:19:a9:5b:d5:d0] ieee80211_scan_assoc_success
17180694.036000] ath0: ieee80211_ioctl_siwscan: active scan request
17180694.036000] ath0: ieee80211_start_scan: active scan, duration 2147483647, desired mode 11a, append, nopick, once
17180694.036000] ath0: scan set 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 100a, 104a, 108a, 112a, 116a, 120a, 124a, 128a, 132a, 136a, 140a dwell min 5 max 50
17180694.040000] ath0: scan_next: chan  64a ->  52a [passive, dwell min 5 max 50]
17180694.240000] ath0: scan_next: chan  52a ->  56a [passive, dwell min 5 max 50]
17180694.440000] ath0: scan_next: chan  56a ->  60a [passive, dwell min 5 max 50]
17180694.640000] ath0: scan_next: chan  60a ->  64a [passive, dwell min 5 max 50]
17180694.704000] ath_bmiss_tasklet
17180694.708000] [00:19:a9:5b:d5:d0] new beacon on chan 64 (bss chan 64) "JUJU"
17180694.708000] [00:19:a9:5b:d5:d0] caps 0x101 bintval 100 erp 0x0
17180694.708000] ath0: ieee80211_add_scan: chan  64a min dwell met (206381 > 206369)
17180694.712000] ath0: scan_next: chan  64a ->  36a [passive, dwell min 5 max 50]
17180694.912000] ath0: scan_next: chan  36a ->  40a [passive, dwell min 5 max 50]
17180695.112000] ath0: scan_next: chan  40a ->  44a [passive, dwell min 5 max 50]
17180695.312000] ath0: scan_next: chan  44a ->  48a [passive, dwell min 5 max 50]
17180695.420000] ath_bmiss_tasklet
17180695.512000] ath0: scan_next: chan  48a -> 100a [passive, dwell min 5 max 50]
17180695.712000] ath0: scan_next: chan 100a -> 104a [passive, dwell min 5 max 50]
17180695.912000] ath0: scan_next: chan 104a -> 108a [passive, dwell min 5 max 50]
17180696.112000] ath0: scan_next: chan 108a -> 112a [passive, dwell min 5 max 50]
17180696.136000] ath_bmiss_tasklet
17180696.312000] ath0: scan_next: chan 112a -> 116a [passive, dwell min 5 max 50]
17180696.512000] ath0: scan_next: chan 116a -> 120a [passive, dwell min 5 max 50]
17180696.712000] ath0: scan_next: chan 120a -> 124a [passive, dwell min 5 max 50]
17180696.852000] ath_bmiss_tasklet
17180696.912000] ath0: scan_next: chan 124a -> 128a [passive, dwell min 5 max 50]
17180697.112000] ath0: scan_next: chan 128a -> 132a [passive, dwell min 5 max 50]
17180697.312000] ath0: scan_next: chan 132a -> 136a [passive, dwell min 5 max 50]
17180697.512000] ath0: scan_next: chan 136a -> 140a [passive, dwell min 5 max 50]
17180697.568000] ath_bmiss_tasklet
17180697.712000] ath0: sta_pick_bss Checking scan results
17180697.712000] ath0: scan_next: done, [jiffies 207132, dwell min 5 scanend 2147689861]
17180697.712000] ath0: notify scan done
17180697.780000] ath_beacon_config: nexttbtt 121000 intval 100 (100)
17180697.780000] ath_beacon_config: tsf 123904325 tsf:tu 121002 intval 100 nexttbtt 121100 dtim 200 nextdtim 121200 bmiss 7 sleep 100 cfp:period 200 maxdur 0 next 121200 timoffset 0


Failing case (ESSID hidden):


17180573.768000] ath0: ieee80211_ioctl_siwscan: active scan request
17180573.768000] ath0: ieee80211_start_scan: active scan, duration 2147483647, desired mode 11a, append, nopick, once
17180573.768000] ath0: scan set 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 100a, 104a, 108a, 112a, 116a, 120a, 124a, 128a, 132a, 136a, 140a dwell min 5 max 50
17180573.772000] ath0: scan_next: chan  64a ->  52a [passive, dwell min 5 max 50]
17180573.972000] ath0: scan_next: chan  52a ->  56a [passive, dwell min 5 max 50]
17180574.172000] ath0: scan_next: chan  56a ->  60a [passive, dwell min 5 max 50]
17180574.372000] ath0: scan_next: chan  60a ->  64a [passive, dwell min 5 max 50]
17180574.396000] [00:19:a9:5b:d5:d0] new beacon on chan 64 (bss chan 64) "JUJU"
17180574.396000] [00:19:a9:5b:d5:d0] caps 0x101 bintval 100 erp 0x0
17180574.396000] ath0: ieee80211_add_scan: chan  64a min dwell met (176303 > 176302)
17180574.400000] ath0: scan_next: chan  64a ->  36a [passive, dwell min 5 max 50]
17180574.600000] ath0: scan_next: chan  36a ->  40a [passive, dwell min 5 max 50]
17180574.800000] ath0: scan_next: chan  40a ->  44a [passive, dwell min 5 max 50]
17180575.000000] ath0: scan_next: chan  44a ->  48a [passive, dwell min 5 max 50]
17180575.200000] ath0: scan_next: chan  48a -> 100a [passive, dwell min 5 max 50]
17180575.400000] ath0: scan_next: chan 100a -> 104a [passive, dwell min 5 max 50]
17180575.600000] ath0: scan_next: chan 104a -> 108a [passive, dwell min 5 max 50]
17180575.800000] ath0: scan_next: chan 108a -> 112a [passive, dwell min 5 max 50]
17180576.000000] ath0: scan_next: chan 112a -> 116a [passive, dwell min 5 max 50]
17180576.200000] ath0: scan_next: chan 116a -> 120a [passive, dwell min 5 max 50]
17180576.400000] ath0: scan_next: chan 120a -> 124a [passive, dwell min 5 max 50]
17180576.600000] ath0: scan_next: chan 124a -> 128a [passive, dwell min 5 max 50]
17180576.800000] ath0: scan_next: chan 128a -> 132a [passive, dwell min 5 max 50]
17180577.000000] ath0: scan_next: chan 132a -> 136a [passive, dwell min 5 max 50]
17180577.200000] ath0: scan_next: chan 136a -> 140a [passive, dwell min 5 max 50]
17180577.400000] ath0: sta_pick_bss Checking scan results
17180577.400000] ath0: scan_next: done, [jiffies 177054, dwell min 5 scanend 2147659793]
17180577.400000] ath0: notify scan done

02/04/08 05:49:29 changed by ugly.p.mouse@gmail.com

After checking the sniffer logs, it is as I suspected, the station does not associate to hidden SSID APs in case they are operating in passive channels. It does not use configured SSID to send authentication request to AP. One way to fix this is to Do a "listen before you talk" implementation. After hearing a first beacon from scanned channel, station will send a probe request to AP (in case it is hidden), if it answers with correct SSID, authentication is performed.

Workaround for this is to use either g-mode, or a-mode with active channels (U.S country code for example). At least almost all European regulation domains (ETSI), requires DFS.

-K

02/04/08 22:40:04 changed by julien.boibessot@free.fr

I confirm that I have no problem (at first sight) in 802.11g mode.
I couldn't try 802.11a with active channels as my APs don't allo that configuration.