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

Opened 15 years ago

Last modified 15 years ago

Monitor mode not working if station VAP ever existed

Reported by: msmith@cbnco.com Assigned to:
Priority: major Milestone:
Component: madwifi: other Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:

Description

Kismet works on a master mode card (at least, assuming I destroy the master mode VAP first). But if the card has ever had a station VAP that successfully associated, bringing up a monitor interface either locks up the computer hard, or fails to return any packets to Kismet/tcpdump. Even if I destroy the station VAP first.

svn info:

Path: .
URL: http: //svn.madwifi.org/trunk
Repository Root: http: //svn.madwifi.org
Repository UUID: 0192ed92-7a03-0410-a25b-9323aeb14dbd
Revision: 2002
Node Kind: directory
Schedule: normal
Last Changed Author: proski
Last Changed Rev: 2000
Last Changed Date: 2007-01-25 20:59:37 -0500 (Thu, 25 Jan 2007)
Properties Last Updated: 2007-01-26 15:39:05 -0500 (Fri, 26 Jan 2007)

Kernel: 2.6.18.3

Here's a test script to reproduce it on the client. It assumes there's an ESSID "temp" available with no WEP, and something responding to ping at 10.0.0.1.

#!/bin/sh

set -x

modprobe ath_pci
iwconfig ath0 essid temp        # use default STA device on ath0
ifconfig ath0 10.0.0.2 netmask 255.255.255.0

sleep 1
ping -c 3 10.0.0.1 || exit 1    # just to show the network works

sleep 1

ifconfig ath0 down
wlanconfig ath0 destroy

sleep 1

athdebug 0x800c0170
80211debug 0x4c281000

# This is basically what Kismet does
wlanconfig kis0 create wlandev wifi0 wlanmode monitor
echo 803 > /proc/sys/net/kis0/dev_type
ifconfig kis0 up

sleep 1                         # it might hang the kernel here...
tcpdump -c 5 -ni kis0           # or it might never see packets here

Here's the output of running the script.

+ modprobe ath_pci
Using /lib/modules/2.6.18.3/net/ath_hal.ko
Using /lib/modules/2.6.18.3/net/wlan.ko
Using /lib/modules/2.6.18.3/net/ath_rate_sample.ko
Using /lib/modules/2.6.18.3/net/ath_pci.ko
+ iwconfig ath0 essid temp
+ ifconfig ath0 10.0.0.2 netmask 255.255.255.0
+ sleep 1
+ ping -c 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=3948 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=2950 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=11.0 ms

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 3943ms
rtt min/avg/max/mdev = 11.011/2303.504/3948.684/1671.442 ms, pipe 3
+ sleep 1
+ ifconfig ath0 down
+ wlanconfig ath0 destroy
+ sleep 1
+ athdebug 0x800c0170
dev.wifi0.debug: 0x00000000 => 0x800c0170<rate,reset,mode,watchdog,state,node,fatal>
+ 80211debug 0x4c281000
80211debug: sysctl-get(net.ath0.debug): No such file or directory
+ wlanconfig kis0 create wlandev wifi0 wlanmode monitor
kis0
+ echo 803
+ ifconfig kis0 up
+ sleep 1

Here are the madwifi messages from the kernel.

ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
wlan: 0.8.4.2 (0.9.3)
ath_rate_sample: 1.2 (0.9.3)
ath_pci: 0.9.4.5 (0.9.3)
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 5.9 phy 4.3 radio 4.6
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 5212: mem=0xa0010000, irq=11

...

ath_rate_sample: ath_rate_ctl_reset 00:00:00:00:00:00 no rates (fixed -1)
ath_node_alloc: an c7b85000
ath_init: mode 8
ath_stop_locked: invalid 0 flags 0x1002
startrecv: mtu 1500 cachelsz 32 rxbufsize 3104
ath_mode_init: RX filter 0xbf, MC filter 00000000:00000000
ilter 00000000:00000000
ath_newstate: wifi0: INIT -> RUN
ath_newstate: RX filter 0x3bf bssid 00:02:6f:21:fa:03 aid 0x0
ath_rate_sample: ath_rate_ctl_reset 00:02:6f:21:f9:e0 no rates (fixed -1)
ath_rate_sample: 00:02:6f:21:f9:e0 ath_rate_newassoc
ath_rate_sample: ath_rate_ctl_reset 00:02:6f:21:f9:e0 no rates (fixed -1)
ath_chan_set: 6 (2437 MHz) -> 6 (2437 MHz)
ath_newstate: wifi0: RUN -> RUN
ath_newstate: RX filter 0x3bf bssid 00:02:6f:21:fa:03 aid 0x0
ath_rate_sample: ath_rate_ctl_reset 00:02:6f:21:f9:e0 12 rates 1Mbps (14016us)- 54Mbps (644us)
ath_rate_sample: 00:02:6f:21:f9:e0 ath_rate_newassoc
ath_rate_sample: ath_rate_ctl_reset 00:02:6f:21:f9:e0 12 rates 1Mbps (14016us)- 54Mbps (644us)
ath_mode_init: RX filter 0x3bf, MC filter 00000000:00000000
ath_mode_init: RX filter 0x3bf, MC filter 00000000:00000000

After that it usually freezes.

I'm using miniPCI Aries NL-3054MP (80 mW). I've tried a couple of cards of the same model.

Mike

Change History

01/30/07 08:54:25 changed by scottr

Hi,

Any chance of getting kernel output at the time of the freeze, such as by a serial console? I routinely use monitor mode (with radiotap) and a sta vap and have had no problems. This is using 2.6.16.

I wonder if your enabling of ath/80211debug is causing so much debugging output to the console that the computer is appearing to freeze, when it is simply unable to keep up with the debug IO. Does it freeze up without enabling debugging output?

Cheers.

01/30/07 16:13:42 changed by msmith@cbnco.com

Hi Scott,

The output I pasted is from a serial console at the time of a freeze.

Originally I didn't have any debugging turned on; I just turned some flags on hoping it would help track down the problem. The behaviour is the same with athdebug and 80211debug set to 0.

Thanks, Mike

02/06/07 18:12:45 changed by msmith@cbnco.com

With trunk r2070, I no longer get a crash and monitor mode works. I think you can close this.

It even works if I was using WPA2 (wpa_supplicant, CCMP, PSK) as long as I follow this order:

  1. killall wpa_supplicant
  2. ifconfig ath0 down ; wlanconfig ath0 destroy
  3. ... create monitor VAP

If I mix up steps 1 and 2 and fail to kill wpa_supplicant before bringing its interface down, monitor mode doesn't work -- I don't see any traffic in tcpdump. But I wouldn't say that's a bug.