* [ath9k-devel] Monitor mode in ath9k @ 2011-06-26 2:08 mahaveer gupta 2011-06-27 15:55 ` Pavel Roskin 0 siblings, 1 reply; 9+ messages in thread From: mahaveer gupta @ 2011-06-26 2:08 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ath9k-devel] Monitor mode in ath9k 2011-06-26 2:08 [ath9k-devel] Monitor mode in ath9k mahaveer gupta @ 2011-06-27 15:55 ` Pavel Roskin 2011-06-27 16:55 ` mahaveer gupta 0 siblings, 1 reply; 9+ messages in thread From: Pavel Roskin @ 2011-06-27 15:55 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ath9k-devel] Monitor mode in ath9k 2011-06-27 15:55 ` Pavel Roskin @ 2011-06-27 16:55 ` mahaveer gupta 2011-06-27 16:59 ` Pavel Roskin 0 siblings, 1 reply; 9+ messages in thread From: mahaveer gupta @ 2011-06-27 16:55 UTC (permalink / raw) To: ath9k-devel 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ath9k-devel] Monitor mode in ath9k 2011-06-27 16:55 ` mahaveer gupta @ 2011-06-27 16:59 ` Pavel Roskin 2011-06-28 10:29 ` Mohammed Shafi 0 siblings, 1 reply; 9+ messages in thread From: Pavel Roskin @ 2011-06-27 16:59 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ath9k-devel] Monitor mode in ath9k 2011-06-27 16:59 ` Pavel Roskin @ 2011-06-28 10:29 ` Mohammed Shafi 2011-06-28 12:05 ` mahaveer gupta 0 siblings, 1 reply; 9+ messages in thread From: Mohammed Shafi @ 2011-06-28 10:29 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ath9k-devel] Monitor mode in ath9k 2011-06-28 10:29 ` Mohammed Shafi @ 2011-06-28 12:05 ` mahaveer gupta 2011-06-29 1:35 ` Adrian Chadd 0 siblings, 1 reply; 9+ messages in thread From: mahaveer gupta @ 2011-06-28 12:05 UTC (permalink / raw) To: ath9k-devel > 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ath9k-devel] Monitor mode in ath9k 2011-06-28 12:05 ` mahaveer gupta @ 2011-06-29 1:35 ` Adrian Chadd 2011-06-30 3:28 ` mahaveer gupta 0 siblings, 1 reply; 9+ messages in thread From: Adrian Chadd @ 2011-06-29 1:35 UTC (permalink / raw) To: ath9k-devel 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ath9k-devel] Monitor mode in ath9k 2011-06-29 1:35 ` Adrian Chadd @ 2011-06-30 3:28 ` mahaveer gupta 2011-06-30 6:09 ` Adrian Chadd 0 siblings, 1 reply; 9+ messages in thread From: mahaveer gupta @ 2011-06-30 3:28 UTC (permalink / raw) To: ath9k-devel > 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 >> > ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ath9k-devel] Monitor mode in ath9k 2011-06-30 3:28 ` mahaveer gupta @ 2011-06-30 6:09 ` Adrian Chadd 0 siblings, 0 replies; 9+ messages in thread From: Adrian Chadd @ 2011-06-30 6:09 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-06-30 6:09 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-06-26 2:08 [ath9k-devel] Monitor mode in ath9k mahaveer gupta 2011-06-27 15:55 ` Pavel Roskin 2011-06-27 16:55 ` mahaveer gupta 2011-06-27 16:59 ` Pavel Roskin 2011-06-28 10:29 ` Mohammed Shafi 2011-06-28 12:05 ` mahaveer gupta 2011-06-29 1:35 ` Adrian Chadd 2011-06-30 3:28 ` mahaveer gupta 2011-06-30 6:09 ` Adrian Chadd
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.