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

Opened 13 years ago

Last modified 11 years ago

[patch] Fix channel switch while in monitor mode.

Reported by: tjalling.hattink@ti-wmc.nl Assigned to:
Priority: major Milestone: version 0.9.x - progressive release candidate phase
Component: madwifi: 802.11 stack Version: trunk
Keywords: channel switch monitor wds Cc:
Patch is attached: 1 Pending:

Description

When you switch channels the code checks if the given channel number actually changes by comparing it with the ic_bsschan field. But when the card is in monitor or wds mode this field is invalid and prevents to switch to certain channels. This patch adds an additional check on the current mode to prevent this behaviour.

Signed-off-by: Tjalling Hattink <tjalling.hattink@ti-wmc.nl> Twente Institute of Wireless and Mobile Communications

Attachments

fix-channelswitch.diff (0.8 kB) - added by tjalling.hattink@ti-wmc.nl on 05/11/06 10:15:29.
Patch for fixing channel switch check

Change History

05/11/06 10:15:29 changed by tjalling.hattink@ti-wmc.nl

  • attachment fix-channelswitch.diff added.

Patch for fixing channel switch check

05/11/06 16:29:55 changed by mrenzmann

  • milestone changed from version 0.9.0 - move to new codebase to version 0.9.x - progressive release candidate phase.

05/12/06 04:59:18 changed by dyqith

This patch looks good to me when there's only one vap, but when there's a monitor and an AP, and changing channels on them, it doesn't change the other. I haven't tested any other combination.

Also, the mode changing (abg) is a problem with this too.

05/15/06 01:41:07 changed by dyqith

related comment in ticket:572

05/20/06 20:13:04 changed by dyqith

  • owner set to dyqith.

05/20/06 20:13:10 changed by dyqith

  • status changed from new to assigned.

05/26/06 00:14:23 changed by dyqith

hi,

I'm wondering if you're still working on a patch for this ? if not, I'll see what I can do in the next few days.

05/26/06 08:39:10 changed by dyqith

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

Just checked again,

No problems in changing channels in monitor mode. Only changing the abg mode doesn't work.

This ticket is invalid. closing now, feel free to reopen if you think I'm wrong.

05/29/06 09:36:52 changed by tjalling.hattink@ti-wmc.nl

  • status changed from closed to reopened.
  • resolution deleted.

At least in my case the ic->ic_bsschan field sometimes contains a pointer to a valid channel description structure, even when the vap is running in monitor mode. This field is not zeroed out when it should be invalid, so it may contain old information. This causes the check to evaluate to true and ignore a channel change, even when it should always change because it is in monitor mode.

In my case it frequently happens when I use kismet. Normally the card has one VAP running in ad-hoc mode on channel 40 (Mode a). When kismet starts it creates a monitor VAP and scans the channels 40,52 and 64. But because it was previously in channel 40 the ic_bsschan field still contains channel 40 and makes it impossible for kismet to switch to channel 40.

06/01/06 20:05:06 changed by dyqith

so the problem is, when you're trying to do scanning, it is forced to not scan a particular channel because the driver thinks its already in that channel ?

06/01/06 20:05:55 changed by dyqith

  • status changed from reopened to new.

06/01/06 20:06:10 changed by dyqith

  • status changed from new to assigned.

06/02/06 09:09:19 changed by anonymous

Exactly. The "c == ic->ic_bsschan" makes the driver think that the monitor VAP is already on a particular channel because it is specified by the ic_bssscan, so it will never change to that channel and the monitor VAP stays on the previously scanned channel. If ic_bsschan would be always invalid in monitor mode this wouldn't happen, but this field sometimes contains an old channel value before the driver went into monitor mode.

06/02/06 09:09:55 changed by tjalling.hattink@ti-wmc.nl

The previous post was from me. Sorry about that.

07/24/07 20:56:56 changed by dyqith

  • status changed from assigned to new.
  • owner deleted.

(follow-up: ↓ 16 ) 11/13/07 19:18:34 changed by Max

As of version 0.9.3.2 taken from Debian testing, this issue happens quite often. I have D-Ling G550 WiFi card. I use the adapter mainly in monitor mode to inject generated traffic with my own utility (the generated traffic is used in the debugging purpose of developing another WiFi adapter). After dozen of channel switch (mainly manual via iwconfig) it doesn't switch to the channel 1 until destroying the VAP, though switching to other channels works perfectly.

(in reply to: ↑ 15 ; follow-up: ↓ 17 ) 11/14/07 09:44:46 changed by tjalling.hattink@ti-wmc.nl

Replying to Max:

Max, please try to apply the patch in this ticket to the source of 0.9.3.2 and see if it still happens. I don't know if this ticket is still valid with the latest releases so your problem could also be caused by other issues in the code.

(in reply to: ↑ 16 ) 11/14/07 14:25:43 changed by Max

Replying to tjalling.hattink@ti-wmc.nl:

Max, please try to apply the patch in this ticket to the source of 0.9.3.2 and see if it still happens. I don't know if this ticket is still valid with the latest releases so your problem could also be caused by other issues in the code.

Thanks for the quick response. Applied. Seems to work. But since there is no test case to reproduce the issue for 100%, I'll try to work with it for a couple of days and then let you know whether the issue still happens.

(follow-up: ↓ 19 ) 11/14/07 19:12:46 changed by mentor

Try r2849

(in reply to: ↑ 18 ) 04/04/08 00:19:21 changed by mitchell@ucar.edu

Replying to mentor:

Try r2849

I have this issue using 0.9.4 as installed by the Ubuntu Hardy beta. My reading of the 0.9.4 versions is that this patch should be included? In my case, it's quite repeatable. I have modprobe set to not create any VAP's by default: 'options ath_pci autocreate=none'. I then run a patched version of kismet drone which tells me when it's trying to change channels. I can watch the channel changes via athdebug +reset and then 'dmesg | grep chan'.

Doing this, I can verify that when I first run kismet_drone it scans all channels. Note dwell time of 1sec per channel. Once the problem starts, you can see a time delta of 2 seconds between reported channel changes. The kismet_drone still reports that it is calling the ioctl() once per second.

When I kill kismet_drone and restart it, whatever channel the card is on when I kill kismet_drone won't be available the next time I run it. The time 170041 is when I stop kismet and 170049 is when I restart it. I don't know if the first channel change at 170049 is triggered by kismet or the driver. I can reproduce this on both Ubuntu 7.10 and 8.04beta using three different NICs (D-Link WNA-1330, TP-LINK TL-WN610G and Netgear WG511T)

[170034.176000] ath_chan_set: 1 (2412 MHz) -> 6 (2437 MHz)
[170035.216000] ath_chan_set: 6 (2437 MHz) -> 11 (2462 MHz)
[170036.228000] ath_chan_set: 11 (2462 MHz) -> 1 (2412 MHz)
[170037.248000] ath_chan_set: 1 (2412 MHz) -> 6 (2437 MHz)
[170038.256000] ath_chan_set: 6 (2437 MHz) -> 11 (2462 MHz)
[170039.328000] ath_chan_set: 11 (2462 MHz) -> 1 (2412 MHz)
[170040.372000] ath_chan_set: 1 (2412 MHz) -> 6 (2437 MHz)
[170041.380000] ath_chan_set: 6 (2437 MHz) -> 11 (2462 MHz)
[170049.252000] ath_chan_set: 11 (2462 MHz) -> 11 (2462 MHz)
[170049.256000] ath_chan_set: 11 (2462 MHz) -> 6 (2437 MHz)
[170050.288000] ath_chan_set: 6 (2437 MHz) -> 1 (2412 MHz)
[170051.328000] ath_chan_set: 1 (2412 MHz) -> 6 (2437 MHz)
[170053.344000] ath_chan_set: 6 (2437 MHz) -> 1 (2412 MHz)
[170054.344000] ath_chan_set: 1 (2412 MHz) -> 6 (2437 MHz)
[170056.372000] ath_chan_set: 6 (2437 MHz) -> 1 (2412 MHz)
[170057.420000] ath_chan_set: 1 (2412 MHz) -> 6 (2437 MHz)
[170059.504000] ath_chan_set: 6 (2437 MHz) -> 1 (2412 MHz)
[170060.544000] ath_chan_set: 1 (2412 MHz) -> 6 (2437 MHz)

(follow-up: ↓ 21 ) 04/23/08 23:19:37 changed by mitchell

I just tried trunk to see about fixing an unrelated monitor bug and this seems to have been addressed. It's svn r3563 I think.

(in reply to: ↑ 20 ) 04/24/08 06:21:42 changed by mrenzmann

Replying to mitchell:

I just tried trunk to see about fixing an unrelated monitor bug and this seems to have been addressed. It's svn r3563 I think.

Can anyone else here confirm that the issue reported in this ticket is fixed in recent revisions of trunk?