madwifi-ng mode changes modification (iwpriv XX mode YY) and (iwconfig XX channel YY) / (iwconfig XX freq YY)

http://madwifi.org/ticket/411

http://madwifi.org/ticket/433

The code is very inconsistent between how different VAPs (AP, sta, wds, monitor) handle the mode (802.11a/b/g) changes.

AP uses ieee80211_create_ibss(), but it won't create anything unless both mode and channel are set.

STA uses ieee80211_check_scan(), using the mode as its limitation, it scans on the channels of the given mode. (limited by athchans, but not by the channel given by the user)

WDS and MONITOR is just put into RUN state without any modification, even if mode and channels are set.

---

Proposed changes: 1) The abg mode takes precedence over the channel choices. 2) STA should limit its scanning range to the current set channel, (bgscan should take care of hopping otherwise) 3) WDS and MONITOR needs to be allowed to got into SCANNING state, thus allowing them to change channel and modes 4) Scanning modules need to be created for WDS and MONITOR mode in order for 3) to happen.

IMHO, any state should allow for a manual scan.

using the latest version of ng/FC5 and 2.6.16 kernel. Mode is not changing in station mode. Initially the mode is selected to 11b and remains there.

But somtimes when I assign ip to the interface using ifconfig ath0 inet xxx than it changes the mode and associates itself with the access point. While I think mode change should be independent to ip address.

I am using the lastest NG sources with 2.6.15 kernel;

The Infrastructure (access point) mode setting fails...

'iwconfig ath0 mode Master' returns: Error for wireless request "Set Mode" (8B06) :

SET failed on device ath0 ; Invalid argument.

whereas 'iwconfig ath0 mode Managed' still works...

The above used to work with NG source code r1447

@rjain, actually that stuff never worked for -ng.

You have to use the "wlanconfig ath0 create wlandev wifi0 wlanmode ap"

Take a look at the wiki...

Thanks for clarifying, I was using 'wlanconfig' earlier as well but can't explain what stopped working... Please ignore my previous posting.

New comment (relating to ticket:275, ticket:228): (abg) mode changes, channel changes and scanning are all inter-related.

Classifying information by VAP operation:

STA/managed

An STA has no concept of a fixed channel when its not assoc/auth because of its SCAN_STATE. In the SCAN_STATE, the STA jumps from channel to channel (channels set by athchans)

What everyone was hoping for was this (i think): When we put "iwconfig ath0 channel 10", the sta will stop jumping channels, and stick with the one given (correct ?)

Another thing is the way scanning is not getting cancelled when another call is coming in. Cancelling the scan may not be appropriate (i.e. One program asks for a scan, another asks for a scan afterwards, should the second cancel the firsts scan ? I would think not)

AP/master

Changing channel/mode is fine (except when channel is set to something other than 0 and then mode can't be changed from a to b/g). Scanning is not supported by AP (even though a wlan_scan_ap is present)

monitor/wds

Channel/mode changes are not happening because these are not AP nor STA. They do not call create_ibss() or jump channels when SCANNING. These do not have a SCANNING state (gets put into RUN). To help put them into a correct channel/mode, new code must be placed to force them as such (ticket:612), but must also force all VAPs to change like any other code.

adhoc/ahdemo

Haven't looked into it, someone want to provide something for it ?

Follow up, I think what we're all hoping for in the STA case, have three types of scanning (forced/manual, active, background) in that priority.

Forced/manual scanning should be able to cancel all other scans (except its own type).

Active scanning is what the STA should be doing in the SCAN_STATE (can be cancelled by manual scans).

Background scanning is when the card "should" be assoc/auth and it jumps off channel every so often to build a scan cache of what's out there.

comments ?

I agree with your synopsis.

With regard to the monitor VAP, wouldn't it be best if it were locked to the same channel as other VAP's when VAP's exist (similar in behaviour to ipwlivetap from ipw2200/3945), and only be allowed to channel hop when it is the sole VAP?

How do we proceed with the patches on #275 and #228?

Kel.

Regarding ticket:275 and ticket:228, I didn't want to merge them since they are not 100% effective. I want to find a way to resolve the problem without actually merging a workaround. Besides, using the delay() functions doesn't sleep, which means we may stall the whole system for a little bit (messing up recv'ing frames from driver when under lock ?)

dyqith: I'm playing right now with a new scanning prototype: if you if'up an STA device, the scanner will only scan one time and stops on the first channel where a ap is found. Afer this, scanning stops, and the association will be performed. The rest of the channel will be scanned by background scan, that means the card goes every x (currently 3) seconds off-channel, scans one other channel, and returns.

For AP mode, we could use the result from these scans: scanning in AP mode is currently only performed to search for the channel with the lowest rssi and performing DFS if a radar is found.

If there is a new scan request during an active scan, the request will be queued and executed after the scan finishes.

What do you think about such a solution?

The last comment was from me.

@svens: I would rather we not stop the scanning after one try (i.e. AP is up after STA). Stopping on the first AP found may be bad (multiple AP w/ given essid, but first one has a bad signal strength, and should use another one instead)

The background scanning idea (jumping off every 3 sec) sounds okay, (are you using ps-poll to tell the AP to save frames though?), and how long are you planning to dwell at each channel ? Make sure bgscan can be turned off (instead of being cancelled like right now)

I like the idea about queuing scans (but like I mentioned above, and also from ticket:228, some people will find waiting for the first "up" scan to take too long and think its a bug, so active scans must be cancelled by active scans and manual scans [but never bgscan])

Does this sound reasonable ?

Hello. I'm using the latest madwifi (7-12-06) but I can't change the mode of a card of mine. I get the following error code:

Interface doesn't accept private ioctl...
mode (8BE2): Invalid argument

However, I can change the mode of my other cards...

@dragonfighter: see UserDocs/ChangingMode. If that does not help, please contact our regular support channels. Thanks.