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 #623 (closed defect: fixed)

Opened 13 years ago

Last modified 13 years ago

Scanning incorrect channels in Adhoc mode with r1552

Reported by: Assigned to: mrenzmann
Priority: major Milestone: version 0.9.x - progressive release candidate phase
Component: madwifi: other Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:


In r1552 (although the problem goes back as far as r1474) I'm having difficulties with scanning. Specifically the card will only scan channels 10 and 11 of b/g mode. The card is aware of the other channels (iwlist athX chan shows all appropriate b/g channels) but will not scan them in an active scan. If the card is forced into a specific channel (e.g 6) and then the VAP destroyed and recreated that channel is now scanned as well (following from the example of 6 the channels scanned would now be 6, 10 and 11). Station mode scans all appropriate channels.


imr-adhoc-channels.diff (0.5 kB) - added by on 05/23/06 02:54:26.
Patch to use the same channels table in ad-hoc mode as in station mode.

Change History

05/16/06 07:02:42 changed by dyqith

Use 80211debug +scan +state

And make sure this is indeed true.

05/16/06 11:44:07 changed by

I've used 80211debug +scan already, and the active scan cycles between the two channels. In station mode it does traverse the entire collection of appropriate channels. I'll try tomorrow with +state as well and see if anything leaps out.

05/17/06 00:06:44 changed by

Follows is a snippet of the debug output with +scan and +state, although there doesn't appear to be any state changes occurring, probably because I've just brought an Ad-Hoc interface up, set it to 11b and let it do its own thing. This is all done automatically by a start script not written by me.

eth1: scan_next: done, restart [jiffies 26408, dwell min 50 scanend 2147416391]
eth1: scan_next: chan  11b ->  10b [active, dwell min 50 max 50]
eth1: scan_next: chan  10b ->  11b [active, dwell min 50 max 50]
[00:13:10:4f:f3:cb] new probe_resp on chan 11 (bss chan 11) "CRCnet-rsc"
[00:13:10:4f:f3:cb] caps 0x401 bintval 100 erp 0x4
[00:13:10:4f:f3:cb] new beacon on chan 11 (bss chan 11) "CRCnet-rsc"
[00:13:10:4f:f3:cb] caps 0x401 bintval 100 erp 0x4
[00:13:10:4f:f3:cb] new beacon on chan 11 (bss chan 11) "CRCnet-rsc"
[00:13:10:4f:f3:cb] caps 0x401 bintval 100 erp 0x4
[00:13:10:4f:f3:cb] new beacon on chan 11 (bss chan 11) "CRCnet-rsc"
[00:13:10:4f:f3:cb] caps 0x401 bintval 100 erp 0x4
[00:13:10:4f:f3:cb] new beacon on chan 11 (bss chan 11) "CRCnet-rsc"
[00:13:10:4f:f3:cb] caps 0x401 bintval 100 erp 0x4
eth1: ieee80211_add_scan: chan  11b min dwell met (26519 > 26516)
eth1:  macaddr          bssid         chan  rssi  rate flag  wep  essid
 002 - 00:13:10:4f:f3:cb 00:13:10:4f:f3:cb   11   +40  11M   ess!  no  "CRCnet-rsc"
eth1: adhoc_pick_bss: no scan candidate
eth1: scan_next: done, restart [jiffies 26523, dwell min 50 scanend 2147416391]
eth1: scan_next: chan  11b ->  10b [active, dwell min 50 max 50]

This repeats constantly. As can be seen it scans 10, then 11, then finishes and starts the next scan heading back to 10.

05/19/06 06:26:17 changed by

I've had a look at the driver source, and unless I'm mistaken the chances of it scanning any channel other than 10 and 11 has been practically nill since the introduction of source:/trunk/net80211/ieee80211_scan_sta.c back in r1775. Does anyone know why the compatibility mode for Ad-Hoc only uses channels 10 and 11 for b? The creation of the list of channels to scan for Ad-Hoc mode is done in adhoc_start and above that we have the following code (and comment) starting on line 1132 of r1520 (the last modification):

 * Adhoc mode-specific support.
static const u_int16_t adhocWorld[] =           /* 36, 40, 44, 48 */
{ 5180, 5200, 5220, 5240 };
static const u_int16_t adhocFcc3[] =            /* 36, 40, 44, 48 145, 149, 153, 157, 161, 165 */
{ 5180, 5200, 5220, 5240, 5725, 5745, 5765, 5785, 5805, 5825 };
static const u_int16_t adhocMkk[] =             /* 34, 38, 42, 46 */
{ 5170, 5190, 5210, 5230 };
static const u_int16_t adhoc11b[] =             /* 10, 11 */
{ 2457, 2462 };

Any comments?

05/19/06 07:39:50 changed by kelmo

s/r1775/r1475/ perhaps? What changeset are you referring to Ian, must had made a typo above.

05/19/06 07:43:04 changed by Matt Brown

Hi Kelmo,

The code has been in the file since it was initially imported in r1175.

I know Ian has been doing some testing this afternoon with an expanded array and there are no obvious problems.

I myself can't think of any logical reason why scan's in AdHoc? mode should be restricted. Any ideas?

05/19/06 09:25:17 changed by mrenzmann

I have absolutely no idea why such a restriction has been introduced. Did anyone check already how Sam did it in FreeBSD?

05/19/06 14:15:29 changed by

I have tried simply replacing uses of adhocScanTable with staScanTable, and this has worked with the very minimal testing I have done so far. I am still concerned however as the restriction appears to be very deliberate, and it would be nice to know why that restriction was in place before removing it.

05/19/06 14:53:36 changed by Matt Brown

The earliest instance of this file that I can find in the FreeBSD repository is the following changeset

This is simply a backport by Sam from somewhere (I don't know where...) but the offending code is already in place. So no clues there as to the reasoning behind it.

05/23/06 02:53:37 changed by

I haven't managed to turn up any hard information as to why ad-hoc was limited to channels 10 and 11, although there is a suggestion that this is possibly the remenants of an old standard for ad-hoc usage. Attached is a patch that replaces the table of channels used by ad-hoc mode with that used when in station mode. <imr-adhoc-channels.diff>

Signed-off-by: Ian M Rawley <>

05/23/06 02:54:26 changed by

  • attachment imr-adhoc-channels.diff added.

Patch to use the same channels table in ad-hoc mode as in station mode.

05/23/06 02:55:43 changed by

  • patch_attached set to 1.

Setting patch attached flag, because the patch is attached now.

05/23/06 06:36:52 changed by mrenzmann

  • status changed from new to assigned.
  • owner set to mrenzmann.
  • milestone set to version 0.9.x - progressive release candidate phase.

07/02/06 08:59:51 changed by kelmo

  • status changed from assigned to closed.
  • resolution set to fixed.

Applied to r1661, thanks Ian and Matt.