> + /* for every radiotap entry that is present (returns -ve on end or
> + * on error)
> + */
> +
> + while (ieee80211_radiotap_iterator_next(&iterator) >= 0) {
"returns -ve"? Also, this does >= 0 while the docs stated that -1 is
returned. Maybe the docs should be updated and the code should be
changed to actually return 0 or a negative error code for
iterator_next()? I don't see any value in the return code when it's
non-negative, but when it's negative there could be some value in
determining -EINVAL (invalid header) vs. -ENOENT (when it's the last
one) for example.
> + /*
> + * fix up the pointers accounting for the radiotap
> + * header still being in there. We are being given
> + * a precooked IEEE80211 header so no need for
> + * normal processing
> + */
Interesting thing I just thought about here. For hardware-based sequence
numbers we'll be updating the sequence number before sending it, and for
software-based sequence numbers we wouldn't be.
However, for a userspace MLME we really need to update the sequence
number, so we'll either want to have a radiotap flag determining whether
the sequence number should be updated or not when transmitting a frame
or we just update them all the time, even for software-sequence numbers.
bcm43xx for example allows to turn off hardware sequence numbers on a
per-frame basis, so it'd be able to do both, but I'm not sure we can
rely on such functionality hence we'll want to just update sequence
numbers all the time...
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
