[ath9k-devel] Monitor mode in ath9k

[ath9k-devel] Monitor mode in ath9k

[mahaveer gupta]

Hello,

   I have set my atheros wireless card driven by ath9k driver in
monitor mode. I wish to see all packets which have a failed CRC.

Now, for a given channel condition between transmitter-receiver pair
(80211 g link), I am not receiving all of the packets with failed
CRCs. I am able to receive 50% of them, but the rest leave no trace
whatsoever.

In the test environment, collisions could be safely ignored and the
channel condition was good enough for decoding plcp header and
preamble. The question is, why am I not receiving all packets that
have failed CRCs?

  Is this because of some filtering happening in the hardware. If so,
can I do some configuration to prevent such filtering and pass all
erroneous packets to upper layers? Is there anything to do with
"ath9k_hw_setrxfilter()" in "hw.c"?

Thanks,
M

[ath9k-devel] Monitor mode in ath9k

[Pavel Roskin]

On 06/25/2011 10:08 PM, mahaveer gupta wrote:
> Hello,
>
>     I have set my atheros wireless card driven by ath9k driver in
> monitor mode. I wish to see all packets which have a failed CRC.
>
> Now, for a given channel condition between transmitter-receiver pair
> (80211 g link), I am not receiving all of the packets with failed
> CRCs. I am able to receive 50% of them, but the rest leave no trace
> whatsoever.
>
> In the test environment, collisions could be safely ignored and the
> channel condition was good enough for decoding plcp header and
> preamble. The question is, why am I not receiving all packets that
> have failed CRCs?
>
>    Is this because of some filtering happening in the hardware. If so,
> can I do some configuration to prevent such filtering and pass all
> erroneous packets to upper layers? Is there anything to do with
> "ath9k_hw_setrxfilter()" in "hw.c"?

Promiscuous mode should disable rx filtering.  Programs like wireshark 
enable promiscuous mode, but maybe you are using some userspace software 
that doesn't?

-- 
Regards,
Pavel Roskin

[ath9k-devel] Monitor mode in ath9k

[mahaveer gupta]

Hi Pavel,

    After setting the device in monitor mode, I was dumping out the
packets at the kernel level by modifying some parts of the driver code
(dumping from ath_rx_tasklet( ) before call to ieee80211_rx( )). I am
not using any user-space software

Thanks,
Mahanth

On Mon, Jun 27, 2011 at 11:55 AM, Pavel Roskin <proski@gnu.org> wrote:
> On 06/25/2011 10:08 PM, mahaveer gupta wrote:
>>
>> Hello,
>>
>> ? ?I have set my atheros wireless card driven by ath9k driver in
>> monitor mode. I wish to see all packets which have a failed CRC.
>>
>> Now, for a given channel condition between transmitter-receiver pair
>> (80211 g link), I am not receiving all of the packets with failed
>> CRCs. I am able to receive 50% of them, but the rest leave no trace
>> whatsoever.
>>
>> In the test environment, collisions could be safely ignored and the
>> channel condition was good enough for decoding plcp header and
>> preamble. The question is, why am I not receiving all packets that
>> have failed CRCs?
>>
>> ? Is this because of some filtering happening in the hardware. If so,
>> can I do some configuration to prevent such filtering and pass all
>> erroneous packets to upper layers? Is there anything to do with
>> "ath9k_hw_setrxfilter()" in "hw.c"?
>
> Promiscuous mode should disable rx filtering. ?Programs like wireshark
> enable promiscuous mode, but maybe you are using some userspace software
> that doesn't?
>
> --
> Regards,
> Pavel Roskin
>

[ath9k-devel] Monitor mode in ath9k

[Pavel Roskin]

On 06/27/2011 12:55 PM, mahaveer gupta wrote:
> Hi Pavel,
>
>      After setting the device in monitor mode, I was dumping out the
> packets at the kernel level by modifying some parts of the driver code
> (dumping from ath_rx_tasklet( ) before call to ieee80211_rx( )). I am
> not using any user-space software

Then use ifconfig or ip to set promiscuous mode, e.g.

ip link set wlan0 promisc on

-- 
Regards,
Pavel Roskin

[ath9k-devel] Monitor mode in ath9k

[Mohammed Shafi]

On Mon, Jun 27, 2011 at 10:29 PM, Pavel Roskin <proski@gnu.org> wrote:
> On 06/27/2011 12:55 PM, mahaveer gupta wrote:
>> Hi Pavel,
>>
>> ? ? ?After setting the device in monitor mode, I was dumping out the
>> packets at the kernel level by modifying some parts of the driver code
>> (dumping from ath_rx_tasklet( ) before call to ieee80211_rx( )). I am
>> not using any user-space software

driver does not seems to drop it..
 /*
                 * Reject error frames with the exception of
                 * decryption and MIC failures. For monitor mode,
                 * we also ignore the CRC error.
                 */
                if (ah->is_monitoring) {
                        if (rx_stats->rs_status &
                            ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
                              ATH9K_RXERR_CRC))
                                return false;
i wil take a look at mac80211 should_drop_frame function
ieee80211_rx_monitor later

>
> Then use ifconfig or ip to set promiscuous mode, e.g.
>
> ip link set wlan0 promisc on
>
> --
> Regards,
> Pavel Roskin
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>



-- 
shafi

[ath9k-devel] Monitor mode in ath9k

[mahaveer gupta]

> driver does not seems to drop it..
> ?/*
> ? ? ? ? ? ? ? ? * Reject error frames with the exception of
> ? ? ? ? ? ? ? ? * decryption and MIC failures. For monitor mode,
> ? ? ? ? ? ? ? ? * we also ignore the CRC error.
> ? ? ? ? ? ? ? ? */
> ? ? ? ? ? ? ? ?if (ah->is_monitoring) {
> ? ? ? ? ? ? ? ? ? ? ? ?if (rx_stats->rs_status &
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ATH9K_RXERR_CRC))
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return false;
Thats true, from the driver's point of view it doesn't seem to be
dropping packets with failed CRC. As I mentioned earlier, I am seeing
50% of the packets with have failed CRC which wouldn't be possible if
driver code was dropping them.

However, the question is, where are the other 50% packets going. Is
the hardware dropping them because it sees a high bit error rate in
the data section of the packet after decoding the header?

Also, I am able to see all of the packets, if I transmit them at base
rate (rate at which preamble and plcp headers are transmitted)

MAC layer functions wouldn't matter for me because I am dumping
packets before they reach MAC layer.

Thanks,
M
> i wil take a look at mac80211 should_drop_frame function
> ieee80211_rx_monitor later
>
>>
>> Then use ifconfig or ip to set promiscuous mode, e.g.
>>
>> ip link set wlan0 promisc on
>>
>> --
>> Regards,
>> Pavel Roskin
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
>
>
> --
> shafi
>

[ath9k-devel] Monitor mode in ath9k

[Adrian Chadd]

The thing to do here is to enable PHY error reception and see if any
of the PHY errors correspond with your 50% missing packets.

It's a difficult thing to catch because the PHY errors may also occur
due to background noise, so you'll likely be looking for increases in
the PHY error rates when you do packets, on top of whatever your
background noise level is.

Thanks,


Adrian

On 28 June 2011 20:05, mahaveer gupta <mgupta1616@gmail.com> wrote:
>> driver does not seems to drop it..
>> ?/*
>> ? ? ? ? ? ? ? ? * Reject error frames with the exception of
>> ? ? ? ? ? ? ? ? * decryption and MIC failures. For monitor mode,
>> ? ? ? ? ? ? ? ? * we also ignore the CRC error.
>> ? ? ? ? ? ? ? ? */
>> ? ? ? ? ? ? ? ?if (ah->is_monitoring) {
>> ? ? ? ? ? ? ? ? ? ? ? ?if (rx_stats->rs_status &
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ATH9K_RXERR_CRC))
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return false;
> Thats true, from the driver's point of view it doesn't seem to be
> dropping packets with failed CRC. As I mentioned earlier, I am seeing
> 50% of the packets with have failed CRC which wouldn't be possible if
> driver code was dropping them.
>
> However, the question is, where are the other 50% packets going. Is
> the hardware dropping them because it sees a high bit error rate in
> the data section of the packet after decoding the header?
>
> Also, I am able to see all of the packets, if I transmit them at base
> rate (rate at which preamble and plcp headers are transmitted)
>
> MAC layer functions wouldn't matter for me because I am dumping
> packets before they reach MAC layer.
>
> Thanks,
> M
>> i wil take a look at mac80211 should_drop_frame function
>> ieee80211_rx_monitor later
>>
>>>
>>> Then use ifconfig or ip to set promiscuous mode, e.g.
>>>
>>> ip link set wlan0 promisc on
>>>
>>> --
>>> Regards,
>>> Pavel Roskin
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>>
>>
>> --
>> shafi
>>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Monitor mode in ath9k

[mahaveer gupta]

> The thing to do here is to enable PHY error reception and see if any
> of the PHY errors correspond with your 50% missing packets.

Thats an interesting comment, do you have an idea how to do that? I
tried the following in hw.c to enable phy errors

void ath9k_hw_setrxfilter(struct ath_hw *ah, u32 bits)
{
	u32 phybits;

	ENABLE_REGWRITE_BUFFER(ah);

	REG_WRITE(ah, AR_RX_FILTER, bits);

	phybits = 0;
	if (bits & ATH9K_RX_FILTER_PHYRADAR)
		phybits |= AR_PHY_ERR_RADAR;
	if (bits & ATH9K_RX_FILTER_PHYERR)
		phybits |= AR_PHY_ERR_OFDM_TIMING | AR_PHY_ERR_CCK_TIMING;

/*IMPORTANT*/
	REG_WRITE(ah, AR_PHY_ERR, 0xffffffff); (Modified part of the code,
setting all error bits)

It didn't work too well for me though (I see only two distinct values
in the received "rx_status" which correspond to correct packets and
CRC failed packets. I didn't see an rx_status value corresponding to
phy errors).

My guess is that some packets are getting dropped in functions like
"ath9k_rx_skb_preprocess()" (called by ath_rx_tasklet() ) and its
callees. Is there a way to get around this without messing up with the
receive queue.

Also, why should there be phy layer errors since the preamble and plcp
header are being decoded correctly?

Thanks,
M


>
> It's a difficult thing to catch because the PHY errors may also occur
> due to background noise, so you'll likely be looking for increases in
> the PHY error rates when you do packets, on top of whatever your
> background noise level is.
>
> Thanks,
>
>
> Adrian
>
> On 28 June 2011 20:05, mahaveer gupta <mgupta1616@gmail.com> wrote:
>>> driver does not seems to drop it..
>>> ?/*
>>> ? ? ? ? ? ? ? ? * Reject error frames with the exception of
>>> ? ? ? ? ? ? ? ? * decryption and MIC failures. For monitor mode,
>>> ? ? ? ? ? ? ? ? * we also ignore the CRC error.
>>> ? ? ? ? ? ? ? ? */
>>> ? ? ? ? ? ? ? ?if (ah->is_monitoring) {
>>> ? ? ? ? ? ? ? ? ? ? ? ?if (rx_stats->rs_status &
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ATH9K_RXERR_CRC))
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return false;
>> Thats true, from the driver's point of view it doesn't seem to be
>> dropping packets with failed CRC. As I mentioned earlier, I am seeing
>> 50% of the packets with have failed CRC which wouldn't be possible if
>> driver code was dropping them.
>>
>> However, the question is, where are the other 50% packets going. Is
>> the hardware dropping them because it sees a high bit error rate in
>> the data section of the packet after decoding the header?
>>
>> Also, I am able to see all of the packets, if I transmit them at base
>> rate (rate at which preamble and plcp headers are transmitted)
>>
>> MAC layer functions wouldn't matter for me because I am dumping
>> packets before they reach MAC layer.
>>
>> Thanks,
>> M
>>> i wil take a look at mac80211 should_drop_frame function
>>> ieee80211_rx_monitor later
>>>
>>>>
>>>> Then use ifconfig or ip to set promiscuous mode, e.g.
>>>>
>>>> ip link set wlan0 promisc on
>>>>
>>>> --
>>>> Regards,
>>>> Pavel Roskin
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>
>>>
>>>
>>>
>>> --
>>> shafi
>>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>

[ath9k-devel] Monitor mode in ath9k

[Adrian Chadd]

Hi,

You need to make sure that you set phybits to 0xfffffff, not just
write it directly.

because;

>.......if (phybits)
>.......>.......REG_SET_BIT(ah, AR_RXCFG, AR_RXCFG_ZLFDMA);
>.......else
>.......>.......REG_CLR_BIT(ah, AR_RXCFG, AR_RXCFG_ZLFDMA);

That enables DMA RX of zero-length frames - ie, error frames like PHY
errors which have no payload. You just get the descriptor.

Then the RX routine (ath9k_rx_rxprocdesc) will set the phy error:

>.......>.......else if (ads.ds_rxstatus8 & AR_PHYErr) {
>.......>.......>.......rs->rs_status |= ATH9K_RXERR_PHY;
>.......>.......>.......phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
>.......>.......>.......rs->rs_phyerr = phyerr;

Then ath_debug_stat_rx() will increment the relevant counter.

Look for where ATH9K_RXERR_PHY is checked in the RX path and make sure
that error frames aren't being prematurely discarded before they're
being counted for statistics.

HTH,


Adrian