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 #980 (new defect)

Opened 15 years ago

Last modified 10 years ago

Channel fixed, but STA VAPs still scan

Reported by: mrenzmann Assigned to:
Priority: minor Milestone: version 1.0.0 - first stable release
Component: madwifi: other Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:


It has been reported that "iwconfig athX channel Y" does not prevent STA VAPs from scanning all channels, for example when the connection to the AP is lost. This has negative side effects in cases where non-STA VAPs are used at the same time, since the scanning interrupts their connectivity.

This issue should be investigated and eventually be fixed. One idea that comes to mind is that this is caused by .11h requirements (DFS), but that's probably a red herring.


fix-980.diff (4.0 kB) - added by on 05/27/07 11:26:11.
Patch for fixing ticket #980 (partially, see ticket comment for details)

Change History

10/27/06 16:21:47 changed by

I can confirm this behaviour. It would be nice to have possibility (probably in iwpriv or even better set by default) to force madwifi to prevent scanning if there is AP VAP and STA VAP configured on one NIC. I'll play with doth options as suggested by Michael Renzmann on user list.

11/09/06 03:22:19 changed by anonymous

I have problems also ! I have AP and STA on one NIC, and bridge on them, and couple of clients connected to AP (ath0), when STA(ath1) lost connection with other AP, and regain connection again, all clients that were connected to AP before connection loss are unable to connect to AP again (no association response). But when I change MAC of one station, I'm able to connect again, and any client with MAC different than ne before connection loss is able to connect.

I'm using folowing to setup AP and STA

wlanconfig ath0 create wlandev wifi0 wlanmode ap wlanconfig ath1 create wlandev wifi0 wlanmode sta nosbeacon iwconfig ath1 ap 00:01:23:21:2B:29 iwconfig ath1 key _the_key_is_here iwpriv ath1 wds 1 iwconfig ath0 essid "new_AP" iwpriv ath0 wds 1 ifconfig ath1 up ifconfig ath0 up brctl addbr br0 brctl addif br0 ath0 brctl addif br0 ath1 echo 1 > /proc/sys/net/ipv4/ip_forward ifconfig br0 up

11/09/06 06:13:43 changed by mrenzmann

@anonymous: since you didn't specify a fixed channel (neither for the STA nor for the AP), the STA of course has to scan all available channels to find a suitable AP to connect to. Since the STA and the AP share the same WLAN card, the AP VAP automatically follows to the channels the STA is scanning and (in the end) working on. So you don't suffer from the bug described in this ticket, but from a conceptual misunderstanding.

11/12/06 02:03:51 changed by


No: It will scan even if you set an specific channel. That's my original issue, very simple config:

Remote AP (ch 7) <--- very long link ---> STA on MadWifi with ch SPECIFICALLY SET TO 7.

AP on MadWifi with different ssid. <---> my laptop.

Anyway, the commands are rather simple:

modprobe ath_pci autocreate=ap wlanconfig ath create wlandev wifi0 wlanmode sta nosbeacon

athctrl -d 35000

iwpriv ath0 hide_ssid 1

iwconfig ath2 essid "remote_ap_ssid" ifconfig ath2 <my_local_ip> netmask

iwpriv ath2 bgscan 0

iwconfig ath0 essid "test" ifconfig ath0 <another_network_ip> netmask iwconfig ath2 channel 7 iwconfig ath0 cahnnel 7 (added later, just to try to make it "stay" on channel 7..... it isn't working, thus I could remove this line).

And when the remote ap is disconnected (power failure, or whatever), ath2 start to scan!, and, off course, the Atheros-based AP stop working.

The issue is getting me so upset, that I'll test if the remote AP can work in ad-hoc mode (it is an WRT54GS with OpenWRT on it)... and I'll try OLSR in ad-hoc mode.... but last time I tested the WRT in ad-hoc mode, it didn't worked very well....

I will give it another try, but I think that madwifi shouldn't be scanning when a channel have been manually set.


Ildefonso Camargo

11/12/06 15:58:17 changed by anonymous


Well if I set channels I have same thing, I'm using next to link with remote AP

wlanconfig ath0 create wlandev wifi0 wlanmode ap wlanconfig ath1 create wlandev wifi0 wlanmode sta nosbeacon iwconfig ath1 ap xx:xx:xx:xx:xx:xx iwconfig ath1 key the_key iwconfig ath0 channel 2 iwconfig ath1 channel 2 iwpriv ath1 wds 1 iwconfig ath0 essid "new_name" iwpriv ath0 wds 1 ifconfig ath1 up ifconfig ath0 up

When ath1-sta lost connection with remote_AP, ath0-AP goes down, but when ath1 regain connection, it's not possible to connect to ath0-AP with MAC which was connected to ath0-AP while connection loss (ath1-sta<-> remote_AP). If I change MAC adress of clients which connects to ath0-AP I'm able to connect to ath0-AP again.

Also I tried "athchan -i ath0 2", and "athchan -i ath1 2", but I have same results.

12/13/06 02:45:51 changed by


Any update on this issue?. I'm having REALLY serius issues because of this: when I lost connection on the STA interface, the AP interface is lost..... I would suggest simply make the channel "fixed", and have the STA just sit and wait in the same channel... this in order to keep the AP up while the STA isn't connected.

Another thing: is this really a "minor" issue?.....


Ildefonso Camargo

01/02/07 14:34:25 changed by roee

I fixed this issue but in 0.9.2 : In ieee80211_scan_sta.c there's a function add_channels(). In it there's a loop that fills in an array of channels to scan (ss->ss_chans[]). Towards the end of the loop, just before setting a channel into this array I've added the following condition:

if (ss->ss_last >= IEEE80211_SCAN_MAX)

// ---- My change start here ----
if (vap->iv_des_chan != IEEE80211_CHAN_ANYC)
    if (c != vap->iv_des_chan)
// ---- My change ends here ----

ss->ss_chans[ss->ss_last++] = c;

Note that vap->iv_des_chan is set by iwconfig ath0 channel ... command. This works for me in STA mode but I haven't tested it exhaustively.

05/02/07 13:03:22 changed by anonymous

@roee: what other modifications you made? Should I pass *vap for add_channels()-function or is there better solution?

05/12/07 08:03:41 changed by ansanto

ieee80211_scan_sta.c is ok at present day ? or in which madwifi release ? and sure a stupid question: what is the best between "iwconfig athx freq xxxx" and "iwconfig athx channel n"b ?


05/26/07 15:51:12 changed by

Well, I can confirm that something is wrong in 0.9.3:

ath_hal: (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) wlan: (0.9.3) ath_pci: (0.9.3) ath_rate_sample: 1.2 (0.9.3)

My Frequency bounces around even though I've set: iwpriv ath0 bgscan 0 iwconfig ath0 channel 152

The channel command sets off the scan again, this is really not very nice when dealing with long links that are supposed to be reliable.

05/26/07 18:18:30 changed by

I've just "upgraded" to the trunk version straight out of svn:

ath_hal: (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF54
13, RF2133)
wlan: (svn r2377)
ath_pci: (svn r2377)
ath_rate_sample: 1.2 (svn r2377)                                                

... and it still suffers from this insanely annoying bug.

I've tried the suggested patch, while it stops the scanning it also locks the channel to some random 2.4GHz channel and iwconfig ath0 channel 152 does nothing.

What do other people do when setting up long links?

05/27/07 11:26:11 changed by

  • attachment fix-980.diff added.

Patch for fixing ticket #980 (partially, see ticket comment for details)

05/27/07 11:33:19 changed by

I've written a tiny fix for this problem and attached it to the ticket, all the fix does is to limit the scanning to the single channel that the user wants when he's sure what he wants.

To stop scanning: pyramid:~# iwconfig ath0 channel 152 pyramid:~# ifconfig ath0 down pyramid:~# ifconfig ath0 up

To start scanning: pyramid:~# iwconfig ath0 channel 0 pyramid:~# ifconfig ath0 down pyramid:~# ifconfig ath0 up

The act of setting the channel doesn't stop/start the scanning, but it should, that's why I call this a partial fix, but if you can live with that then this should help you.

Don't be put off by the size of the patch, the meat of the change is simply:

if (vap->iv_des_chan != IEEE80211_CHAN_ANYC) {

ss->ss_chans[ss->ss_last++] = vap->iv_des_chan;

} else {

Perhaps this could be done more elegantly, by not starting the scan in the first place perhaps, but here you are.