Userspace packet injector applications might want to transmit packets
that are, by design, not supposed to be acked. In other cases, an
injector application may need to control the sequence number of the
packets it transmits. Introduce 2 new flags in the "TX flags" Radiotap
fields, controlling these 2 behaviors.
The new fields are as follows:
* IEEE80211_RADIOTAP_TX_FLAGS
IEEE80211_RADIOTAP_F_TX_NO_ACK: Transmit the packet once with no wai=
ting for
an ACK and no retrying if no ACK received
IEEE80211_RADIOTAP_F_TX_NO_SEQ: Use the sequence number already pres=
ent in
the 802.11 header, do not generate a new one
in the driver/stack. Useful when injecting
fragments with the same sequence number.
Signed-off-by: G=E1bor Stefanik <[email protected]>
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Fri, 2008-12-12 at 23:54 +0100, Stefanik Gábor wrote:
> Using an "assign seqno" flag would cause existing injectors that
> expect the kernel to do seq numbering for them to fail. This possibly
> includes hostap and penumbra.
Yeah, I know, but can hostapd/penumbra really expect getting seqnos on
other platforms? If not, then for the sake of interoperability it might
make sense to switch around and have hostapd/penumbra just set the bit.
johannes
On Fri, Dec 12, 2008 at 11:50 PM, Johannes Berg
<[email protected]> wrote:
> On Fri, 2008-12-12 at 23:40 +0100, Stefanik G=E1bor wrote:
>
>> [...]
>
> Incidentally, as for the radiotap changes, I'm wondering whether the
> flag really should be "no seqno" or should be "assign seqno" instead.=
It
> seems injection should be "as raw as possible" by default. But things
> like that really need to be worked out with people from other systems=
=2E
>
> johannes
>
Using an "assign seqno" flag would cause existing injectors that
expect the kernel to do seq numbering for them to fail. This possibly
includes hostap and penumbra.
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Fri, Dec 12, 2008 at 11:37 PM, Johannes Berg
<[email protected]> wrote:
> On Fri, 2008-12-12 at 23:32 +0100, Stefanik G=E1bor wrote:
>> Userspace packet injector applications might want to transmit packet=
s
>> that are, by design, not supposed to be acked. In other cases, an
>> injector application may need to control the sequence number of the
>> packets it transmits. Introduce 2 new flags in the "TX flags" Radiot=
ap
>> fields, controlling these 2 behaviors.
>>
>> The new fields are as follows:
>>
>> * IEEE80211_RADIOTAP_TX_FLAGS
>>
>> IEEE80211_RADIOTAP_F_TX_NO_ACK: Transmit the packet once with no =
waiting for
>> an ACK and no retrying if no ACK re=
ceived
>> IEEE80211_RADIOTAP_F_TX_NO_SEQ: Use the sequence number already p=
resent in
>> the 802.11 header, do not generate =
a new one
>> in the driver/stack. Useful when in=
jecting
>> fragments with the same sequence nu=
mber.
>
> Umm, these aren't really defined by radiotap yet. Does all of this ha=
ve
> to be NOW?
>
> johannes
>
No, that's why I submitted it as an RFC.
By the way, what is the preferred method of contacting the Radiotap
staff now that the mailing list seems to be permanently down?
--G=E1bor
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Fri, 2008-12-12 at 23:40 +0100, Stefanik Gábor wrote:
> No, that's why I submitted it as an RFC.
Phew. FWIW, except that the no-seq isn't defined by any other OS yet, it
seems at least compatible.
> By the way, what is the preferred method of contacting the Radiotap
> staff now that the mailing list seems to be permanently down?
I'm trying to convince David Young to get a new list. Netbsd seemed
willing to host it, but I haven't heard back yet (he wanted to have it
done a week ago)
johannes
On Fri, 2008-12-12 at 19:20 -0500, Richard Farina wrote:
> > Umm, these aren't really defined by radiotap yet. Does all of this have
> > to be NOW?
> Is there a compelling reason to prohibit progress?
Well, it should be done with radiotap.org...
Incidentally, the new list is there. [email protected].
johannes
On Fri, 2008-12-12 at 23:32 +0100, Stefanik Gábor wrote:
> Userspace packet injector applications might want to transmit packets
> that are, by design, not supposed to be acked. In other cases, an
> injector application may need to control the sequence number of the
> packets it transmits. Introduce 2 new flags in the "TX flags" Radiotap
> fields, controlling these 2 behaviors.
>
> The new fields are as follows:
>
> * IEEE80211_RADIOTAP_TX_FLAGS
>
> IEEE80211_RADIOTAP_F_TX_NO_ACK: Transmit the packet once with no waiting for
> an ACK and no retrying if no ACK received
> IEEE80211_RADIOTAP_F_TX_NO_SEQ: Use the sequence number already present in
> the 802.11 header, do not generate a new one
> in the driver/stack. Useful when injecting
> fragments with the same sequence number.
Umm, these aren't really defined by radiotap yet. Does all of this have
to be NOW?
johannes
On Fri, 2008-12-12 at 23:40 +0100, Stefanik Gábor wrote:
> [...]
Incidentally, as for the radiotap changes, I'm wondering whether the
flag really should be "no seqno" or should be "assign seqno" instead. It
seems injection should be "as raw as possible" by default. But things
like that really need to be worked out with people from other systems.
johannes
Johannes Berg wrote:
> On Fri, 2008-12-12 at 23:32 +0100, Stefanik G=C3=A1bor wrote:
> =20
>> Userspace packet injector applications might want to transmit packet=
s
>> that are, by design, not supposed to be acked. In other cases, an
>> injector application may need to control the sequence number of the
>> packets it transmits. Introduce 2 new flags in the "TX flags" Radiot=
ap
>> fields, controlling these 2 behaviors.
>>
>> The new fields are as follows:
>>
>> * IEEE80211_RADIOTAP_TX_FLAGS
>>
>> IEEE80211_RADIOTAP_F_TX_NO_ACK: Transmit the packet once with no =
waiting for
>> an ACK and no retrying if no ACK received
>> IEEE80211_RADIOTAP_F_TX_NO_SEQ: Use the sequence number already p=
resent in
>> the 802.11 header, do not generate a new one
>> in the driver/stack. Useful when injecting
>> fragments with the same sequence number.
>> =20
>
> Umm, these aren't really defined by radiotap yet. Does all of this ha=
ve
> to be NOW?
>
> =20
Is there a compelling reason to prohibit progress?
--Rick
> johannes
> =20