Kismet Wireless

Kismet Forums

 

Posted by:dom123
Subject:mac80211
Date:16:06:17 13/05/2011

> > Hi
> >
> > Sorry for starting another thread but i thought it may help with clarity.
> >
> > In attempting to fix my ongoing issue of broken SSID's, i'm wondering how significant this message is:
> >
> > ERROR: Source 'wlan0' doesn't have mac80211 support, disabling VAP creation of
> > default monitor mode VAP
> >
> > That message appears even with forcevap=true set at ncsource on the drone.
>
> That's weird, and not good...
>
> >
> > This is a freshly built openwrt firmware using the following settings, and applying the "__le32_to_cpu" fix to packetsource_pcap.cc.
>
> What fix is this?
>
> > We seem to be getting all the broken/corrupt packets - though this is an assumption.
> >
> > Thanks in advance, very much appreciated.
>
> Are you sure you're using the kernel ath9k drivers, and not some vendor variant for your embedded system? Make sure on that. I'd check dmesg and lsmod, and make sure you're loading the drivers you think you are.
>
> What does kismet do if you don't specify the type? You shouldn't need to, for kernel drivers at least. if it can't detect the type, that may indicate you're running out-of-kernel vendor drivers? Kismet has a fail-through model for the linux drivers where it tries to use the mac80211 controls then falls back to the old-school ioctl controls. It seems like it's doing that, which means something funny is going on.
>
> The kernel drivers ought to be mac80211 based. The only other things I can think of is if netlink isn't compiled into your kernel (would be hard, but i think maybe possible?)
>
> Personally I'm leaning towards "not really running ath9k", which would explain the mac80211 and the invalid frames coming in, but if you're absolutely positive you're running the kernel ath9k drivers, I'm at a bit of a loss.


Hi Dragorn - thanks again.

First, the packetsource_pcap.cc "fix" -> http://www.kismetwireless.net/Forum/General/Messages/1287434294.0886641

Netlink - I checked via make menuconfig and actually, lo and behold, it wasnt checked. I rebuilt the image but am getting exactly the same result! Odd.

Ath9k driver files were brought down with the openwrt image. These are built into the kernel, and lsmod shows they are loaded.

root@OpenWrt:~# lsmod | grep ath9k
ath9k 76000 0
ath9k_common 1200 1 ath9k
ath9k_hw 237984 2 ath9k,ath9k_common
ath 13792 3 carl9170,ath9k,ath9k_hw
mac80211 207216 2 carl9170,ath9k
cfg80211 120704 4 carl9170,ath9k,ath,mac80211
compat 9104 4 carl9170,ath9k,mac80211,cfg80211

Continuing the oddness, dmesg | grep ath shows:

root@OpenWrt:~# dmesg | grep ath
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a
Registered led device: ath9k-phy0

...not sure if that means anything.

Finally - what does kismet do if we dont specify a type:

INFO: Matched source type 'ath9k' for auto-type source 'wlan0'

Which seems to be correct.

However, even with forcevap, AND libn installed:

root@OpenWrt:~# opkg list_installed | grep libn
libnl - 1.1-4
libnl-tiny - 0.1-1

We still get...

ERROR: Source 'wlan0' doesn't have mac80211 support, disabling VAP creation of default monitor mode VAP

Bah!


Reply to this message