Javier, I've also put this thread onto linux-wireless, maybe
people there are interested in this area, too.
> I use the echo-to-sys way because we are not setting any
> existing interface into monitor mode but creating a new one.
And that is the part that I'm not really liking.
> This is the way Intel ipw2xxx drivers behave and I think it is
> a cleaner solution to have separate interfaces, one for 802.3
> and another one for 802.11+rtap
The ipw2xxx driver is a driver that was developed mostly
out-of-kernel-tree. I'm not sure if it is a good template on how
to write a WLAN driver :-)
My problem is really that did create another interface, rtapX. It
is that you also create a new API on how to monitor. And I have
the feeling that we have an inflation of APIs for turning on
monitor mode:
* there is "iwconfig eth1 mode monitor"
* there is madwifi's way of wlanconfig
* there is ipw22xx's way of a .config and of modprobe "ipw2200
rtap_iface=1" and "ifconfig rtap0 up"
* and now you
with /sys/class/net/{ethX,mshX}/device/libertas_rtap
Somehow I fear that tools like kismet (or others!) won't honor
just-another-interface on how to turn monitor mode on.
Why not do it this way:
"iwmode eth1 mode monitor" turn's the device into monitor mode.
That's what by far the most drivers use. In this mode, the
device will send all frames to the host, e.g. all beacon frames.
After all, user space can filter:
tshark -i rtap0 -R '!(wlan.fc.subtype == 8)'
If you think that this creates too much traffic on the USB bus,
then additionally you can use something
like /sys/class/net/{ethX,mshX}/device/rtap_filter and expose
your bitmap.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
