> While you're doing that, could you beat up on the driver teams to get > them to adopt the same APIs for turning on monitor mode and setting the > channel? There's a whole bunch of different commands (and presumably > calls) with different drivers:
Oh, I know. :) I'm working on it.
> It appears that the madwifi driver uses "iwconfig"; does that mean it
> uses standard, rather than private ("iwpriv"), ioctls? If so, it might
> be nice to get those more broadly adopted; if not, it might be nice to
The "standard correct way" to do it SHOULD BE siocsiwmode monitor (6).
Wext didn't have that when rfmon-able drivers first started coming out.
Generally I see all the modern drivers supporting that, though some
support legacy older models.
wext mode monitor DOESN'T give us linktype twiddles though. So those
are always going to be iwprivs. I'd like to see, and plan to push, that
any driver that can report signal levels default to radiotap linktype.
Don't get me started on the extra-broken random drivers that make
dynamic other devices (like wrt54, where depending on the firmware, you
either do ``wl mode monitor'' (shell command) and open the device, do wl
mode and open a new dynamic device (prism0), or do iwconfig monitor and
open a new dynamic device. *sigh*
I've been developing a database of cards based on the iwpriv
fingerprints. So far, the method seems to be sound. I hope to use that
to map sources automatically inside Kismet to the kismet 'specialty'
sources. As drivers evolve, I should only need one standard source
under linux, which I would hope is controled via siocsiwmode, reports
radiotap, and properly fills in the FCS bit in the rt header.
-m
--
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
Life is a whim of several billion cells to be you for a while.
pgp5yHtrHrGMe.pgp
Description: PGP signature
