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

Opened 12 years ago

Last modified 11 years ago

Channel change behavior is wrong for AP mode

Reported by: mtaylor Assigned to: mtaylor
Priority: major Milestone: version 0.9.5
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:

Description

When a user explicitly changes the channel on an access point VAP, the behavior is currently to record the desired channel, which would ONLY take effect on bringing down the interface and bringing it back up.

Oddly enough, the only path through this code for master mode VAPs looks at the roaming mode and determines whether it is set to auto. If so, it puts us into 'scan' mode which causes channel change to occur (in the case of station, it will no scan if a channel change is pending and will jus switch).

The correct behavior should be as follows:

If interface is down, set desired channel and do no further action. If interface is running and up, use the channel change IE on beacon to update the channel. If interface is running and not up we set the channel directly.

The current behavior of not changing channels has two unpleasant side effects:

1. Because the channel change has not taken effect, the txpower list is not updated and invalid power levels are seen and entered in startup scripts. Setting channel + power will often fail if the old channel had a lower power level restriction.

2. Because the channel change does not take effect until an explicit restart, assigning the channel after bringing up an interface in a ifup type script would fail.

3. You should not have to use iwpriv doth_chanswitch in order to change the channel of an AP explicitly.

4. You should be able to change channels on an AP without dropping associations.

Attachments

madwifi-0.9.3-chanswitch.diff (2.0 kB) - added by mtaylor on 06/14/07 21:36:06.
Updated logic for live channel changes for AP

Change History

06/14/07 21:36:06 changed by mtaylor

  • attachment madwifi-0.9.3-chanswitch.diff added.

Updated logic for live channel changes for AP

06/16/07 00:32:21 changed by mtaylor

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

Trunk r2462. madwifi-dfs r2463.

06/27/07 07:18:14 changed by mrenzmann

  • milestone changed from version 1.0.0 - first stable release to version 0.9.4.

(follow-up: ↓ 5 ) 09/06/07 22:01:30 changed by thunder.m

Hi, this patch caused hard kernel lockups with madwifi 0.9.3.2 and current trunk in AP mode, 100% reproducable. I tried same script without this patch (0.9.3.2 - v2612) and everything works without problems.

I am using this script to reproduce it:

ifdown ath0
ifconfig ath0 down
wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode ap
ifconfig ath0 up
ifup ath0
iwpriv ath0 mode 1
iwpriv ath0 xr 0
iwpriv ath0 protmode 0
iwpriv ath0 bgscan 0
iwpriv ath0 wmm 1
iwpriv ath0 wds 0
iwconfig ath0 essid czela.net
iwconfig ath0 key s:tajny
iwconfig ath0 rate 54M
iwconfig ath0 txpower 17dB
echo 0 > /proc/sys/dev/wifi0/diversity
echo 1 > /proc/sys/dev/wifi0/txantenna
echo 1 > /proc/sys/dev/wifi0/rxantenna
iwconfig ath0 channel 120

02/11/08 06:19:59 changed by mrenzmann

  • milestone changed from version 0.9.4 to version 0.9.5.

(in reply to: ↑ 3 ) 08/06/08 03:35:22 changed by proski

Replying to thunder.m:

The issue is tracked in #1903.