Hey,
I'm currently working on using radiotap for some stuff in the Linux
wireless stack (mac80211), and ran across the case where we want
userspace to be able to send the frame to a high-priority queue. I'm
thinking this should probably be in radiotap.
There are also other things that need to be controlled via radiotap,
here's what I can propose so far:
* IEEE80211_RADIOTAP_SEND_AC u8 access category
*
* Indicates which access category to send the frame in, 0-3.
*
* IEEE80211_RADIOTAP_SEND_FLAGS u8 flags
*
IEEE80211_RADIOTAP_SEND_FLAG_ENCRYPT (1<<0)
/* encrypt with key for the station named in addr1 or default key */
IEEE80211_RADIOTAP_SEND_FLAG_AUTO_RTSCTS (1<<1)
/* automatically decide whether rts/cts are used, if unset then
* rts/cts are used depending on IEEE80211_RADIOTAP_F_TX_{CTS,RTS} */
IEEE80211_RADIOTAP_SEND_FLAG_RATE_CONTROL (1<<2)
/* should rate control be applied to this algorithm? if not, take
* the value of IEEE80211_RADIOTAP_RATE or lowest rate */
IEEE80211_RADIOTAP_SEND_FLAG_SEQNR (1<<3)
/* set if the sequence number in the packet shouldn't be changed,
* if not set then the packet is sequence numbered properly */
So far that's all I would need, but some regular fields would also be
used like I said above for example IEEE80211_RADIOTAP_F_TX_{CTS,RTS}. A
good text on using radiotap for this purpose should probably be written,
I think somebody other than Andy and me was working on something like
this so we really should work together and define this properly.
johannes
[radiotap mailing list dropped since it is members only]
Andy Green wrote:
> Sam Leffler wrote:
>
>> Note that using a monitor mode interface for transmit is a bad idea. It
>> is likely you will encounter devices that disallow any packet transmit
>> when operating in monitor mode. In practice this can be worked around
>> by using a non-monitor operating mode for the device (e.g. adhoc mode
>> w/o setting up beacons) but exporting this notion to user mode is bad
>> IMO. In net80211 there is an adhoc-demo mode which is essentially adhoc
>> mode which was originally added for functionality found in old lucent
>> cards but more recently has been used for building applications that
>> want a "raw 802.11 device".
>
> Hi -
>
> In mac80211 you can run multiple network interfaces off the one physical
> device, so you can have an associated WPA connection on one network
> interface and another logical "monitor mode" network interface up on the
> one physical device. "Monitor mode" in this case can be the results of
> a promiscuous hardware RX that is filtered for the Managed mode logical
> interface ... this is AIUI. So in that way "Monitor Mode" no longer
> means a single modal device setting, but really the delivery somehow of
> packets to a logical network interface that belongs to the physical device.
I've had working vap code for >3 years.
>
> Injecting down a "monitor mode interface" then only means to use a
> logical network interface that locally is configured to "Monitor Mode",
> it doesn't have the same definite implication for physical device
> configuration as before mac80211. (Well.. AIUI). So hopefully this
> objection may not apply.
As I described, some devices may allow rx-only operation on channels
otherwise disallowed by regulatory constraints. As such overloading
monitor operation with transmit is just a bad idea if you want to take
full advantage of what h/w provides. I'm just suggesting that you're
defining an abstraction that's going to get you into trouble.
Sam
On Thu, 2007-06-21 at 12:55 -0500, David Young wrote:
> > * IEEE80211_RADIOTAP_SEND_AC u8 access category
>
> The MAC access parameters are an important parameter to control, but
> I think that if the control is self-contained, then people will use it
> in a predictable and consistent way. As is, you have to interpret the
> access category by reference to the current MAC settings for the AC
> (AIFS, CWmin, CWmax, et cetera), which can change.
Good point. However, not all hardware allows setting these with each
frame, the Broadcom hardware I work with most allows only setting up the
parameters for four access categories and then using them by putting the
frame into different DMA rings.
> I propose that we add a field such as this,
>
> IEEE80211_RADIOTAP_TX_WMEPARAM u32 WME access parameters
>
> with three 8-bit fields for AIFS, log(CWmin), and log(CWmax), and the
> remaining 8 bits reserved and set to 0.
That makes sense.
> This gives us the flexibility to use more MACs to the extent of their
> capabilities. IIRC, one Realtek MAC lets us set the access parameters
> packet by packet, instead of category by category or queue by queue.
Oh ok, that'd be perfect for those then.
> Some 802.11 MACs have different transmit priority queues, but the queues'
> access parameters are not adjustable. For those MACs, we should provide
> for selecting the queue by number:
>
> IEEE80211_RADIOTAP_TX_QNUM u8 queue number
That would work, although I think I'd still prefer being able to select
an AC as well because in most cases the queues would be set up according
to the four ACs. However, we can standardise that within the QNUM field
as well.
> I think it's reasonable to say in the _TX_QNUM definition that the queue
> numbers do not necessarily have any relationship to queue priority level
> or access parameters.
Definitely.
> > * Indicates which access category to send the frame in, 0-3.
> > *
> > * IEEE80211_RADIOTAP_SEND_FLAGS u8 flags
> ...
> > IEEE80211_RADIOTAP_SEND_FLAG_SEQNR (1<<3)
> > /* set if the sequence number in the packet shouldn't be changed,
> > * if not set then the packet is sequence numbered properly */
>
> Let's re-use and augment IEEE80211_RADIOTAP_TX_FLAGS for transmission
> control. For example, let the bits _F_TX_CTS/_F_TX_RTS indicate "use CTS"
> and "use RTS" when we transmit. But see below. Also, add _F_TX_SEQNR.
Sounds good to me as well.
> > IEEE80211_RADIOTAP_SEND_FLAG_ENCRYPT (1<<0)
> > /* encrypt with key for the station named in addr1 or default key */
>
> Let's re-use IEEE80211_RADIOTAP_FLAGS[IEEE80211_RADIOTAP_F_WEP] for this.
Sure
> > IEEE80211_RADIOTAP_SEND_FLAG_AUTO_RTSCTS (1<<1)
> > /* automatically decide whether rts/cts are used, if unset then
> > * rts/cts are used depending on IEEE80211_RADIOTAP_F_TX_{CTS,RTS} */
>
> I believe implementors will have an easier time if you invert this:
> NOAUTO or (errr...) MANUAL.
Heh, probably.
> 16-bit fields IEEE80211_RADIOTAP_RTS_THRESHOLD and
> IEEE80211_RADIOTAP_CTS_THRESHOLD may be better: if absent, autoselect.
> If present and equal to 0, always use RTS(CTS). If present and greater
> than or equal to the maximum packet length, never use RTS(CTS). We can
> likewise control fragmentation.
Good point. However, in some cases where we may end up wanting to use
this feature, this means querying the kernel for the current
fragmentation threshold only to send it back into the kernel in the
radiotap header. That's perfectly acceptable of course.
> > IEEE80211_RADIOTAP_SEND_FLAG_RATE_CONTROL (1<<2)
> > /* should rate control be applied to this algorithm? if not, take
> > * the value of IEEE80211_RADIOTAP_RATE or lowest rate */
>
> Control this by the presence of the _RATE parameter. If _RATE is absent,
> let the driver or NIC autoselect.
Yeah, good enough.
Thanks for your comments! Do you want me to send a patch against the
authoritative version of the radiotap header?
johannes
Sam Leffler wrote:
> [radiotap mailing list dropped since it is members only]
>
> Andy Green wrote:
>> Sam Leffler wrote:
>>
>>> Note that using a monitor mode interface for transmit is a bad idea. It
>>> is likely you will encounter devices that disallow any packet transmit
>>> when operating in monitor mode. In practice this can be worked around
>>> by using a non-monitor operating mode for the device (e.g. adhoc mode
>>> w/o setting up beacons) but exporting this notion to user mode is bad
>>> IMO. In net80211 there is an adhoc-demo mode which is essentially adhoc
>>> mode which was originally added for functionality found in old lucent
>>> cards but more recently has been used for building applications that
>>> want a "raw 802.11 device".
>>
>> Hi -
>>
>> In mac80211 you can run multiple network interfaces off the one physical
>> device, so you can have an associated WPA connection on one network
>> interface and another logical "monitor mode" network interface up on the
>> one physical device. "Monitor mode" in this case can be the results of
>> a promiscuous hardware RX that is filtered for the Managed mode logical
>> interface ... this is AIUI. So in that way "Monitor Mode" no longer
>> means a single modal device setting, but really the delivery somehow of
>> packets to a logical network interface that belongs to the physical
>> device.
>
> I've had working vap code for >3 years.
Just pointing out that "monitor mode" in this context is now a logical
attribute for a network interface divorced from hardware settings. One
can add another TX-only "injection mode" logical network interface mode
but it buys you nothing over using the otherwise meaningless TX action
of the existing monitor mode. Because most usage cases want to monitor
RX as well having the RX side of Monitor Mode around makes sense for
these cases too.
>> Injecting down a "monitor mode interface" then only means to use a
>> logical network interface that locally is configured to "Monitor Mode",
>> it doesn't have the same definite implication for physical device
>> configuration as before mac80211. (Well.. AIUI). So hopefully this
>> objection may not apply.
>
> As I described, some devices may allow rx-only operation on channels
> otherwise disallowed by regulatory constraints. As such overloading
> monitor operation with transmit is just a bad idea if you want to take
> full advantage of what h/w provides. I'm just suggesting that you're
> defining an abstraction that's going to get you into trouble.
Well, the injection code can look if the channel is rx only and drop the
packet, if something else doesn't check already. Since TX on monitor
mode is not only currently completely unused, but will never be used as
part of a "Monitor" action, I don't see so much trouble it can get me
into to choose that place to overload the injection semantic.
But if you have a better plan I am interested to hear any proposal.
-Andy
Johannes Berg wrote:
> Hey,
>
> I'm currently working on using radiotap for some stuff in the Linux
> wireless stack (mac80211), and ran across the case where we want
> userspace to be able to send the frame to a high-priority queue. I'm
> thinking this should probably be in radiotap.
>
> There are also other things that need to be controlled via radiotap,
> here's what I can propose so far:
>
> * IEEE80211_RADIOTAP_SEND_AC u8 access category
> *
> * Indicates which access category to send the frame in, 0-3.
> *
> * IEEE80211_RADIOTAP_SEND_FLAGS u8 flags
> *
> IEEE80211_RADIOTAP_SEND_FLAG_ENCRYPT (1<<0)
> /* encrypt with key for the station named in addr1 or default key */
>
> IEEE80211_RADIOTAP_SEND_FLAG_AUTO_RTSCTS (1<<1)
> /* automatically decide whether rts/cts are used, if unset then
> * rts/cts are used depending on IEEE80211_RADIOTAP_F_TX_{CTS,RTS} */
>
> IEEE80211_RADIOTAP_SEND_FLAG_RATE_CONTROL (1<<2)
> /* should rate control be applied to this algorithm? if not, take
> * the value of IEEE80211_RADIOTAP_RATE or lowest rate */
>
> IEEE80211_RADIOTAP_SEND_FLAG_SEQNR (1<<3)
> /* set if the sequence number in the packet shouldn't be changed,
> * if not set then the packet is sequence numbered properly */
>
> So far that's all I would need, but some regular fields would also be
> used like I said above for example IEEE80211_RADIOTAP_F_TX_{CTS,RTS}. A
> good text on using radiotap for this purpose should probably be written,
> I think somebody other than Andy and me was working on something like
> this so we really should work together and define this properly.
This is the control state available on FreeBSD for doing raw 802.11
frame xmit (packets need not include all this; I've just provided the
most complete set of knobs):
uint8_t ibp_flags;
#define IEEE80211_BPF_SHORTPRE 0x01 /* tx with short preamble */
#define IEEE80211_BPF_NOACK 0x02 /* tx with no ack */
#define IEEE80211_BPF_CRYPTO 0x04 /* tx with h/w encryption */
#define IEEE80211_BPF_FCS 0x10 /* frame incldues FCS */
#define IEEE80211_BPF_DATAPAD 0x20 /* frame includes data padding */
#define IEEE80211_BPF_RTS 0x40 /* tx with RTS/CTS */
#define IEEE80211_BPF_CTS 0x80 /* tx with CTS only */
uint8_t ibp_pri; /* WME/WMM AC+tx antenna */
uint8_t ibp_try0; /* series 1 try count */
uint8_t ibp_rate0; /* series 1 IEEE tx rate */
uint8_t ibp_power; /* tx power (device units) */
uint8_t ibp_ctsrate; /* IEEE tx rate for CTS */
uint8_t ibp_try1; /* series 2 try count */
uint8_t ibp_rate1; /* series 2 IEEE tx rate */
uint8_t ibp_try2; /* series 3 try count */
uint8_t ibp_rate2; /* series 3 IEEE tx rate */
uint8_t ibp_try3; /* series 4 try count */
uint8_t ibp_rate3; /* series 4 IEEE tx rate */
Note that using a monitor mode interface for transmit is a bad idea. It
is likely you will encounter devices that disallow any packet transmit
when operating in monitor mode. In practice this can be worked around
by using a non-monitor operating mode for the device (e.g. adhoc mode
w/o setting up beacons) but exporting this notion to user mode is bad
IMO. In net80211 there is an adhoc-demo mode which is essentially adhoc
mode which was originally added for functionality found in old lucent
cards but more recently has been used for building applications that
want a "raw 802.11 device".
Sam
On Wed, Jun 20, 2007 at 11:44:13PM +0200, Johannes Berg wrote:
> Hey,
>
> I'm currently working on using radiotap for some stuff in the Linux
> wireless stack (mac80211), and ran across the case where we want
> userspace to be able to send the frame to a high-priority queue. I'm
> thinking this should probably be in radiotap.
>
> There are also other things that need to be controlled via radiotap,
> here's what I can propose so far:
>
> * IEEE80211_RADIOTAP_SEND_AC u8 access category
The MAC access parameters are an important parameter to control, but
I think that if the control is self-contained, then people will use it
in a predictable and consistent way. As is, you have to interpret the
access category by reference to the current MAC settings for the AC
(AIFS, CWmin, CWmax, et cetera), which can change.
I propose that we add a field such as this,
IEEE80211_RADIOTAP_TX_WMEPARAM u32 WME access parameters
with three 8-bit fields for AIFS, log(CWmin), and log(CWmax), and the
remaining 8 bits reserved and set to 0.
This gives us the flexibility to use more MACs to the extent of their
capabilities. IIRC, one Realtek MAC lets us set the access parameters
packet by packet, instead of category by category or queue by queue.
Some 802.11 MACs have different transmit priority queues, but the queues'
access parameters are not adjustable. For those MACs, we should provide
for selecting the queue by number:
IEEE80211_RADIOTAP_TX_QNUM u8 queue number
I think it's reasonable to say in the _TX_QNUM definition that the queue
numbers do not necessarily have any relationship to queue priority level
or access parameters.
> * Indicates which access category to send the frame in, 0-3.
> *
> * IEEE80211_RADIOTAP_SEND_FLAGS u8 flags
...
> IEEE80211_RADIOTAP_SEND_FLAG_SEQNR (1<<3)
> /* set if the sequence number in the packet shouldn't be changed,
> * if not set then the packet is sequence numbered properly */
Let's re-use and augment IEEE80211_RADIOTAP_TX_FLAGS for transmission
control. For example, let the bits _F_TX_CTS/_F_TX_RTS indicate "use CTS"
and "use RTS" when we transmit. But see below. Also, add _F_TX_SEQNR.
> IEEE80211_RADIOTAP_SEND_FLAG_ENCRYPT (1<<0)
> /* encrypt with key for the station named in addr1 or default key */
Let's re-use IEEE80211_RADIOTAP_FLAGS[IEEE80211_RADIOTAP_F_WEP] for this.
> IEEE80211_RADIOTAP_SEND_FLAG_AUTO_RTSCTS (1<<1)
> /* automatically decide whether rts/cts are used, if unset then
> * rts/cts are used depending on IEEE80211_RADIOTAP_F_TX_{CTS,RTS} */
I believe implementors will have an easier time if you invert this:
NOAUTO or (errr...) MANUAL.
16-bit fields IEEE80211_RADIOTAP_RTS_THRESHOLD and
IEEE80211_RADIOTAP_CTS_THRESHOLD may be better: if absent, autoselect.
If present and equal to 0, always use RTS(CTS). If present and greater
than or equal to the maximum packet length, never use RTS(CTS). We can
likewise control fragmentation.
> IEEE80211_RADIOTAP_SEND_FLAG_RATE_CONTROL (1<<2)
> /* should rate control be applied to this algorithm? if not, take
> * the value of IEEE80211_RADIOTAP_RATE or lowest rate */
Control this by the presence of the _RATE parameter. If _RATE is absent,
let the driver or NIC autoselect.
Dave
--
David Young OJC Technologies
[email protected] Urbana, IL * (217) 278-3933 ext 24
On Thu, 2007-06-21 at 13:49 -0700, Sam Leffler wrote:
> This is the control state available on FreeBSD for doing raw 802.11
> frame xmit (packets need not include all this; I've just provided the
> most complete set of knobs):
>
> uint8_t ibp_flags;
> #define IEEE80211_BPF_SHORTPRE 0x01 /* tx with short preamble */
> #define IEEE80211_BPF_NOACK 0x02 /* tx with no ack */
> #define IEEE80211_BPF_CRYPTO 0x04 /* tx with h/w encryption */
> #define IEEE80211_BPF_FCS 0x10 /* frame incldues FCS */
> #define IEEE80211_BPF_DATAPAD 0x20 /* frame includes data padding */
> #define IEEE80211_BPF_RTS 0x40 /* tx with RTS/CTS */
> #define IEEE80211_BPF_CTS 0x80 /* tx with CTS only */
> uint8_t ibp_pri; /* WME/WMM AC+tx antenna */
> uint8_t ibp_try0; /* series 1 try count */
> uint8_t ibp_rate0; /* series 1 IEEE tx rate */
> uint8_t ibp_power; /* tx power (device units) */
> uint8_t ibp_ctsrate; /* IEEE tx rate for CTS */
> uint8_t ibp_try1; /* series 2 try count */
> uint8_t ibp_rate1; /* series 2 IEEE tx rate */
> uint8_t ibp_try2; /* series 3 try count */
> uint8_t ibp_rate2; /* series 3 IEEE tx rate */
> uint8_t ibp_try3; /* series 4 try count */
> uint8_t ibp_rate3; /* series 4 IEEE tx rate */
Sounds simillar to what we're trying here though Dave had some good
comments that equally well apply here. I expect I'll be posting a
radiotap patch, maybe you can comment on that then? Even wrt. how well
you could implement this, possibly even on top of those fields you have.
> Note that using a monitor mode interface for transmit is a bad idea. It
> is likely you will encounter devices that disallow any packet transmit
> when operating in monitor mode. In practice this can be worked around
> by using a non-monitor operating mode for the device (e.g. adhoc mode
> w/o setting up beacons) but exporting this notion to user mode is bad
> IMO. In net80211 there is an adhoc-demo mode which is essentially adhoc
> mode which was originally added for functionality found in old lucent
> cards but more recently has been used for building applications that
> want a "raw 802.11 device".
There's a tradeoff here; the actual notion to userspace ought to be a
monitor interface because that is what tools need to have opened anyway.
It is also natural to use from userspace via libpcap. Also, most modern
hardware doesn't actually care what you send.
If we ever end up being able to support such cards that do care, then I
expect we'll either be able to work around the problem in the driver or
need some special instructions for users of such hardware.
johannes
Sam Leffler wrote:
> Note that using a monitor mode interface for transmit is a bad idea. It
> is likely you will encounter devices that disallow any packet transmit
> when operating in monitor mode. In practice this can be worked around
> by using a non-monitor operating mode for the device (e.g. adhoc mode
> w/o setting up beacons) but exporting this notion to user mode is bad
> IMO. In net80211 there is an adhoc-demo mode which is essentially adhoc
> mode which was originally added for functionality found in old lucent
> cards but more recently has been used for building applications that
> want a "raw 802.11 device".
Hi -
In mac80211 you can run multiple network interfaces off the one physical
device, so you can have an associated WPA connection on one network
interface and another logical "monitor mode" network interface up on the
one physical device. "Monitor mode" in this case can be the results of
a promiscuous hardware RX that is filtered for the Managed mode logical
interface ... this is AIUI. So in that way "Monitor Mode" no longer
means a single modal device setting, but really the delivery somehow of
packets to a logical network interface that belongs to the physical device.
Injecting down a "monitor mode interface" then only means to use a
logical network interface that locally is configured to "Monitor Mode",
it doesn't have the same definite implication for physical device
configuration as before mac80211. (Well.. AIUI). So hopefully this
objection may not apply.
-Andy