radiotap rate no longer supported in mac80211?

radiotap rate no longer supported in mac80211?

[Steve deRosier]

I'm trying to support per-packet setting of rate on a packet injection
via the radiotap header.  In an earlier version of mac80211 (around
2.6.26), there was code in __ieee80211_parse_tx_radiotap (in
net/mac80211/tx.c) to support the use of the the rate element from the
radiotap header.  In current versions of wireless-testing, most of the
code here has been removed and only the flags are parsed.

I want to return the IEEE80211_RADIOTAP_RATE portion of this function
in order to support this.  So the questions:
1. Why were all fields other than IEEE80211_RADIOTAP_FLAGS removed?
2. Would it be OK for me to prepare and submit a patch to restore the
rate functionality?

Thanks,
- Steve

Re: radiotap rate no longer supported in mac80211?

[Pavel Roskin]

On Mon, 2010-06-14 at 15:18 -0700, Steve deRosier wrote:
> I'm trying to support per-packet setting of rate on a packet injection
> via the radiotap header.  In an earlier version of mac80211 (around
> 2.6.26), there was code in __ieee80211_parse_tx_radiotap (in
> net/mac80211/tx.c) to support the use of the the rate element from the
> radiotap header.  In current versions of wireless-testing, most of the
> code here has been removed and only the flags are parsed.
> 
> I want to return the IEEE80211_RADIOTAP_RATE portion of this function
> in order to support this.  So the questions:
> 1. Why were all fields other than IEEE80211_RADIOTAP_FLAGS removed?
> 2. Would it be OK for me to prepare and submit a patch to restore the
> rate functionality?

I posted a patch that would add rate and retry flags:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/47441

I didn't see any interest in the patch.  Perhaps injecting packets at a
specific rate in not particularly needed.

Also, the patch is somewhat inelegant because of the requirement to
specify the rate when the retry count is specified.

mac80211 has an array of rates with corresponding retry counts.  The
radiotap standard has one rate and one retry count.  This doesn't map
well to the mac80211 approach.  Supporting the retry count without the
rate would require some tricky logic, and I don't know if anyone needs
that.

I don't feel good about pushing a patch that makes the code more complex
without knowing the use case.

-- 
Regards,
Pavel Roskin

Re: radiotap rate no longer supported in mac80211?

[Roberto Riggio]

Pavel Roskin <proski@...> writes:

> I posted a patch that would add rate and retry flags:
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/47441
> 
> I didn't see any interest in the patch.  Perhaps injecting packets at a
> specific rate in not particularly needed.

Well maybe it is a little late to reply to this. Anyway I'm actually using
your patch as part of a custom routing protocol for a mesh based on the roofnet 
code.

Capturing packets with bad FCS in monitor mode

[Daniel Haid]

Hello,

is it possible to receive packets with bad FCS in monitor mode (ath9k driver)?
There is a comment in ath9k/common.c which says that a bad checksum is
ignored in monitor mode, but I have so far never been able to receive a
packet with bad FCS (I do not know how to generate such packets,
so I might just be too lucky that all packets are received unimpaired).

Does ath9k hardware drop packets with bad FCS directly? If so, can
it be disabled?

Best regards.

Re: Capturing packets with bad FCS in monitor mode

[Qasim Javed]

Hi Daniel,

I am using the same card and the ath9k driver. I was also not able to
receive frames with CRC errors by setting the fcsfail flag while
creating the monitor mode interface. I looked up the code and found
that ath9k ignores frames with CRC errors in monitor mode.

The ath9k_rx_accept function in common.c has the following condition

if (ah->opmode == NL80211_IFTYPE_MONITOR) {
        if (rx_stats->rs_status &
                ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
                ATH9K_RXERR_CRC))
        return false;

Clearly, this function will return false in case of a CRC error while
receiving on a monitor interface.

For your info, this function is called by ath9k_rx_skb_preprocess
which in turn is invoked in ath9k_rx_tasklet.

In order to receive frames with CRC errors in monitor mode, I just
removed ATH9K_RXERR_CRC from the above snippet, recompiled and
reloaded ath9k and was able to receive frames with CRC errors.

I hope that helps.

-Qasim

On Thu, Aug 5, 2010 at 9:14 AM, Daniel Haid <d.haid@gogi.tv> wrote:
>
> Hello,
>
> is it possible to receive packets with bad FCS in monitor mode (ath9k driver)?
> There is a comment in ath9k/common.c which says that a bad checksum is
> ignored in monitor mode, but I have so far never been able to receive a
> packet with bad FCS (I do not know how to generate such packets,
> so I might just be too lucky that all packets are received unimpaired).
>
> Does ath9k hardware drop packets with bad FCS directly? If so, can
> it be disabled?
>
> Best regards.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: radiotap rate no longer supported in mac80211?

[Daniel Haid]

On 2010-06-15 Pavel Roskin wrote:
> I don't feel good about pushing a patch that makes the code more complex
> without knowing the use case.

I need this as well. How can it be implemented correctly, so that it can
be accepted?