Kismet Wireless

Kismet Forums

 

Posted by:dom123
Subject:mac80211
Date:14:51:43 16/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!

Any suggestions on where to go from here would be great - any ideas please?


Reply to this message