Re: [Madwifi-devel] linux vs. radiotap/monitor mode
Status: Beta
Brought to you by:
otaku
From: John B. <jb...@am...> - 2005-04-11 23:24:14
|
Based on everyone's comments, here is what I think should be done for now: 1. add an additional athXraw device, which will only appear if the appropriate sysctl is toggled. 2. add two sysctls: dev.athX.monitor_dev: setting this to 1 will register an the athXraw device, 0 will unregister it. dev.athX.monitor_dev_type: setting this will adjust dev->type: 0) - raw 802.11 packets (default) 1) - prism2 headers 2) - radiotap headers I would rather these be controlled by iwpriv commands similarly to vaps like Sam and Michael suggested, but in order to do that we would have to pass a bunch of driver-specific data (ie ath_desc's) up into ieee80211_input, which seems like it is asking for trouble. Also, other points where we would be interested in capturing packets (ie after transmissions are complete) don't really have good hooks into the net80211 layer. If anyone has any better spots to insert the radiotap device, that would be great. Intuitively, though, it makes sense that the capture should be done before the 802.11 stack processes a packet. It will probably be a while before we can get a radiotap ARPHDR, but I feel like it will eventually happen because 1) so many apps can parse it already and 2) it's very useful. For now I say we use some unused value until either we can get one assigned or it becomes standard by common use. We can also try to get one assigned in the kernel. (this wouldn't be the default setting anyway, for now). 3. add support for capturing frames that are sent by the card on athXraw. (I've been emailing with David Young about adding some fields to the radiotap header like the number of retries required and tx status). 4. add support for sending raw frames on the athXraw device and/or in monitor mode. These changes won't be incredibly invasive, but I think the features would be really useful. If there's a consensus I'll start working on it. --jbicket |