Monitor mode on if_wi

[Sam Leffler]

> The latest if_wi from Mon Jul 21 is supposed to enable
> monitor mode on Prism based cards. I've had partial
> success in getting monitor mode to work:
>
> Linksys WCP11 card (Intersil Prism 2.5 chipset, flashed
> with Intersil firmware Primary 1.1.1, Station 1.7.4).
> The FreeBSD on this box is a very recent -CURRENT (all
> recent changes to the wi driver).
>
> dstumbler v0.3 seems to work just fine:
>
>    ifconfig wi0 monitor up
>    /opt/bin/dstumbler wi0 -o
>
> I see two access points, as expected.
>
> Also, prism2dump does just fine:
>
>    /opt/bin/prism2ctl wi0 -m
>    /opt/bin/prism2dump wi0
>
> I see beacons as well as user data.
>
> However, tcpdump on wi0 while in monitor mode gives
> bogus results. No 802.11 headers are shown at all
> and the packet dump seems all wrong.
>

dstumbler overrides any monitor mode setup you do and puts the device into 
the old-style prism debug mode where all packets are collected in the 
interrupt handler.  I actually have a version of dstumbler that knows about 
monitor mode and does the right thing but it's in a rather crude state 
right now (e.g. it dumps core when stations appear).  Monitor mode is good 
because it gets apps like dstumbler away from being prism-specific; e.g. my 
dstumbler works with Atheros cards and lets me scan a/b channels all at 
once.  The downside to monitor mode at the moment is that using it means 
you can only tap frames at the 802.11 layer and so you lose information 
like the RSSI that is especially useful for dstumbler.  I've been talking 
to David Young who's done some work for NetBSD to introduce a new packet 
capture format that's integrated with bpf.  Once this is in place monitor 
mode and this will let folks write device-independent tools.

> Also, recovering WEP keys using dwepdump /dwepcrack
> fails despite huge amounts of gathered data. While
> looking at the pcap files created by dwepdump with
> tcpdump -r , I see bogus packets, again without any
> IEEE 802.11 headers at all.
>

I suspect you're mixing different packet capture mechanisms and so getting 
802.3 frames and not 802.11 frames.  Either that or the tools are expecting 
to find the prism header before each frame.

> Kismet is another story. It discovers hundreds of
> access points (while there are only two within reach).
> The pcap files contain the 802.11 headers but the
> MAC addresses of the sending stations seem to vary
> at random.
>
> Any ideas?

If you want to hack I can hand you my dstumbler code...

	Sam