Thread: [zd1211-devs] monitor mode not capturing other BSS packets
Status: Beta
Brought to you by:
mayne
From: Benoit P. <ben...@fr...> - 2009-11-21 00:03:49
|
Hello there, I'm trying to use monitor mode with zd1211b device and I'm currently using 2.6.32-rc7-wl kernel from wireless-testing git tree. What happens in monitor mode is that I only get DATA packets send to as broadcast or multicast addr. I'd like to use the card to capture traffic from other bss. I tried the iw flags otherbss when creating the monitor interface, but this change nothing. Is this a known problem? If so, where should i look for a fix? I remember playing with this device years ago and there was a CR_SNIFFER register that was set to 1. Apparently, this register is set to 0 now. Could it be the root of this issue? Regards, Benoit |
From: Gábor S. <net...@gm...> - 2009-11-21 01:58:29
|
On Sat, Nov 21, 2009 at 12:35 AM, Benoit PAPILLAULT <ben...@fr...> wrote: > Hello there, > > I'm trying to use monitor mode with zd1211b device and I'm currently > using 2.6.32-rc7-wl kernel from wireless-testing git tree. > > What happens in monitor mode is that I only get DATA packets send to as > broadcast or multicast addr. I'd like to use the card to capture traffic > from other bss. I tried the iw flags otherbss when creating the monitor > interface, but this change nothing. > > Is this a known problem? If so, where should i look for a fix? > > I remember playing with this device years ago and there was a CR_SNIFFER > register that was set to 1. Apparently, this register is set to 0 now. > Could it be the root of this issue? Yes, that is probably the problem; please try this patch: http://patches.aircrack-ng.org/zd1211rw_inject_2.6.26.patch. It's just a hack, but it works. (Without the hack, only enabling CR_SNIFFER_ON will cause the card to return junk packets.) > > Regards, > Benoit > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/ > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) |
From: Benoit P. <ben...@fr...> - 2009-11-22 22:06:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gábor Stefanik a écrit : > Yes, that is probably the problem; please try this patch: > http://patches.aircrack-ng.org/zd1211rw_inject_2.6.26.patch. It's just > a hack, but it works. (Without the hack, only enabling CR_SNIFFER_ON > will cause the card to return junk packets.) Indeed. However : 1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON. 2. With both a STA interface and a monitor interface, performance drops significantly. Any explanation for this. 3. Could you tell me a bit more about your junk packet filtering? 4. I received lots of small RX packet of 4 or 5 bytes. What is causing this? Does your patch has been sent upstream already? Regards, Benoit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksJtdEACgkQOR6EySwP7oI0fwCg7wMKKTzlwGtEJax6oNBfuZi3 R6sAoOsCUrp1bZzxrrh6j4mycGXru00u =xMHN -----END PGP SIGNATURE----- |
From: Daniel D. <ds...@ge...> - 2009-11-22 22:30:40
|
Benoit PAPILLAULT wrote: > 1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON. The reason we flip-flopped once or twice in the past is because CR_SNIFFER_ON behaves wildly differently on different revisions of the ZD1211 hardware. Daniel |
From: Hin-Tak L. <hin...@ya...> - 2009-11-22 23:43:45
|
--- On Sun, 22/11/09, Daniel Drake <ds...@ge...> wrote: > Benoit PAPILLAULT wrote: > > 1. I did not receive junk packet so far with only > enabling CR_SNIFFER_ON. > > The reason we flip-flopped once or twice in the past is > because > CR_SNIFFER_ON behaves wildly differently on different > revisions of the > ZD1211 hardware. It is probably appropriate to document this as a comment next to CR_SNIFFER_ON in one of the headers. |
From: Benoit P. <ben...@fr...> - 2009-11-23 10:20:12
|
Hin-Tak Leung a écrit : > --- On Sun, 22/11/09, Daniel Drake <ds...@ge...> wrote: > > >> Benoit PAPILLAULT wrote: >> >>> 1. I did not receive junk packet so far with only >>> >> enabling CR_SNIFFER_ON. >> >> The reason we flip-flopped once or twice in the past is >> because >> CR_SNIFFER_ON behaves wildly differently on different >> revisions of the >> ZD1211 hardware. >> > > It is probably appropriate to document this as a comment next to CR_SNIFFER_ON in one of the headers. > > Very good point. I have two hardware here : one is zd1211 and the other is zd1211b. If I test with both, will it be ok? Regards, Benoit |
From: Daniel D. <ds...@ge...> - 2009-11-23 10:47:44
|
Benoit PAPILLAULT wrote: > Very good point. I have two hardware here : one is zd1211 and the other > is zd1211b. If I test with both, will it be ok? IIRC, 2 of my ZD1211B devices behave differently. Also, the reason that you lose performance is likely because the chip will stop synchronizing its clock to the clock of the BSS that you are connected to, and will instead attempt to be more flexible in terms of receiving data from anywhere at any given time. Daniel |
From: Gábor S. <net...@gm...> - 2009-11-22 22:52:03
|
2009/11/22 Benoit PAPILLAULT <ben...@fr...>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gábor Stefanik a écrit : >> Yes, that is probably the problem; please try this patch: >> http://patches.aircrack-ng.org/zd1211rw_inject_2.6.26.patch. It's just >> a hack, but it works. (Without the hack, only enabling CR_SNIFFER_ON >> will cause the card to return junk packets.) > > Indeed. However : > > 1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON. > 2. With both a STA interface and a monitor interface, performance drops > significantly. Any explanation for this. What do you mean by "performance loss"? Is there packet loss? Is TX rate dropping? > 3. Could you tell me a bit more about your junk packet filtering? It was not written by me - CCing SuD, who wrote the patch. > 4. I received lots of small RX packet of 4 or 5 bytes. What is causing this? > > Does your patch has been sent upstream already? > > Regards, > Benoit > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAksJtdEACgkQOR6EySwP7oI0fwCg7wMKKTzlwGtEJax6oNBfuZi3 > R6sAoOsCUrp1bZzxrrh6j4mycGXru00u > =xMHN > -----END PGP SIGNATURE----- > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) |
From: Benoit P. <ben...@fr...> - 2009-11-23 10:26:56
|
Gábor Stefanik a écrit : > 2009/11/22 Benoit PAPILLAULT <ben...@fr...>: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Gábor Stefanik a écrit : >> >>> Yes, that is probably the problem; please try this patch: >>> http://patches.aircrack-ng.org/zd1211rw_inject_2.6.26.patch. It's just >>> a hack, but it works. (Without the hack, only enabling CR_SNIFFER_ON >>> will cause the card to return junk packets.) >>> >> Indeed. However : >> >> 1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON. >> 2. With both a STA interface and a monitor interface, performance drops >> significantly. Any explanation for this. >> > > What do you mean by "performance loss"? Is there packet loss? Is TX > rate dropping? > > TX rate is dropping a lot (like 20 MBits down to 200 kbits/s). Using another card in monitor mode, I still see packets sent at 54 Mbits rate however. It seems that implementing monitor mode is not consistent over all zd1211 devices and it has an impact on performance. Maybe we can : 1. Dig a big deeper into understanding register settings needed for monitor mode. 2. Add a debugfs interface for enabling the use of CR_SNIFFER_ON in monitor mode. IMHO, it could be enabled by default since users not using monitor mode at all won't be affected and users doing monitor mode expect it to work. In order to warn people, we can add a syslog messages saying "Using CR_SNIFFER_ON register, your performance may degrade, check /sys/kernel/debug/zd1211rw/use_cr_sniffer_on settings". Comments? Regards, Benoit |
From: Alejandro G. <su...@la...> - 2009-11-23 02:10:43
|
Benoit PAPILLAULT escribió: > 1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON. > If you apply the patch and there is a lot of wireless traffic going on you will start getting random frames too (sniffing with tcpdump on monitor interface or whatever). I have a couple of zd1211rw usb devices, and both do it. > 2. With both a STA interface and a monitor interface, performance drops > significantly. Any explanation for this. > Not sure, maybe because you are sniffing all frames in the channel, not only your BSS ones. > 3. Could you tell me a bit more about your junk packet filtering? > That patch is the mac80211 port of an older ieee80211 patch which was not done by me. The ~0x21 is a magic value that seems to work filtering junk frames. But i don't know what it means. > 4. I received lots of small RX packet of 4 or 5 bytes. What is causing this? > Maybe you are getting acks, or maybe it's part of the junk/random frames. Btw, how about enabling the CR_SNIFFER_ON patch as a module parameter so everyone is happy? |
From: Hin-Tak L. <hin...@ya...> - 2009-11-23 02:27:11
|
--- On Mon, 23/11/09, Alejandro Grijalba <su...@la...> wrote: > Benoit PAPILLAULT escribió: > > 1. I did not receive junk packet so far with only > enabling CR_SNIFFER_ON. > > > If you apply the patch and there is a lot of wireless > traffic going on > you will start getting random frames too (sniffing with > tcpdump on > monitor interface or whatever). I have a couple of zd1211rw > usb devices, > and both do it. > > 2. With both a STA interface and a monitor interface, > performance drops > > significantly. Any explanation for this. > > > Not sure, maybe because you are sniffing all frames in the > channel, not > only your BSS ones. > > 3. Could you tell me a bit more about your junk packet > filtering? > > > That patch is the mac80211 port of an older ieee80211 patch > which was > not done by me. The ~0x21 is a magic value that seems to > work filtering > junk frames. But i don't know what it means. > > 4. I received lots of small RX packet of 4 or 5 bytes. > What is causing this? > > > Maybe you are getting acks, or maybe it's part of the > junk/random frames. > > Btw, how about enabling the CR_SNIFFER_ON patch as a module > parameter so > everyone is happy? Expose it through /sysfs or /proc (so that it is dynamically selectable after module loading) may be even better, if it can be done... |
From: Benoit P. <ben...@fr...> - 2009-11-25 21:31:31
|
Benoit PAPILLAULT a écrit : > TX rate is dropping a lot (like 20 MBits down to 200 kbits/s). Using > another card in monitor mode, I still see packets sent at 54 Mbits rate > however. > > I found out what is wrong with the TX throughput. In fact, when a packet is transmitted at 54 Mbits, the destination send back a 802.11 ACK which is ignored!!! As such, the packet is transmitted at 54 Mbits once again, then twice at 48 Mbits, then twice at 36 Mbits ... and so on down to 1 Mbits. Of course, this divide the throughput by 18 (twice for each 9 rates), leading to 200 - 300 kbits. When implementing proper TX status reporting, needed by minstrel rate control, I also found out that some 802.11 ACK where not received by the driver, but received by the card, leading to inconsistencies in the rate control code. Are there some registers that are responsible for ACK behavior? Regards, Benoit |
From: Gábor S. <net...@gm...> - 2009-11-26 09:47:49
|
2009/11/25 Benoit PAPILLAULT <ben...@fr...>: > Benoit PAPILLAULT a écrit : >> >> TX rate is dropping a lot (like 20 MBits down to 200 kbits/s). Using >> another card in monitor mode, I still see packets sent at 54 Mbits rate >> however. >> >> > > I found out what is wrong with the TX throughput. In fact, when a packet is > transmitted at 54 Mbits, the destination send back a 802.11 ACK which is > ignored!!! As such, the packet is transmitted at 54 Mbits once again, then > twice at 48 Mbits, then twice at 36 Mbits ... and so on down to 1 Mbits. Of > course, this divide the throughput by 18 (twice for each 9 rates), leading > to 200 - 300 kbits. > > When implementing proper TX status reporting, needed by minstrel rate > control, I also found out that some 802.11 ACK where not received by the > driver, but received by the card, leading to inconsistencies in the rate > control code. > > Are there some registers that are responsible for ACK behavior? > > Regards, > Benoit > > ACK handling and retrying is one of the known weak points of the zd1211(b) chipset - apparently enabling CR_SNIFFER causes the card to ignore ACKs received. Also, the retry plan for unACKed outgoing packets (retry count & rates) needs to be uploaded to the device on firmware init, and can't be controlled per-packet. Luis: Any chance of an open firmware release for the ZD1211, similarly to what was done for AR9170/ZD1221? That would probably allow for fixing these problems. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) |
From: Benoit P. <ben...@fr...> - 2009-11-30 21:06:45
|
Luis R. Rodriguez a écrit : > On Thu, Nov 26, 2009 at 01:47:14AM -0800, Gábor Stefanik wrote: >> 2009/11/25 Benoit PAPILLAULT <ben...@fr...>: >>> Benoit PAPILLAULT a écrit : >>>> TX rate is dropping a lot (like 20 MBits down to 200 kbits/s). Using >>>> another card in monitor mode, I still see packets sent at 54 Mbits rate >>>> however. >>>> >>>> >>> I found out what is wrong with the TX throughput. In fact, when a packet is >>> transmitted at 54 Mbits, the destination send back a 802.11 ACK which is >>> ignored!!! As such, the packet is transmitted at 54 Mbits once again, then >>> twice at 48 Mbits, then twice at 36 Mbits ... and so on down to 1 Mbits. Of >>> course, this divide the throughput by 18 (twice for each 9 rates), leading >>> to 200 - 300 kbits. >>> >>> When implementing proper TX status reporting, needed by minstrel rate >>> control, I also found out that some 802.11 ACK where not received by the >>> driver, but received by the card, leading to inconsistencies in the rate >>> control code. >>> >>> Are there some registers that are responsible for ACK behavior? >>> >>> Regards, >>> Benoit >>> >>> >> ACK handling and retrying is one of the known weak points of the >> zd1211(b) chipset - apparently enabling CR_SNIFFER causes the card to >> ignore ACKs received. Also, the retry plan for unACKed outgoing >> packets (retry count & rates) needs to be uploaded to the device on >> firmware init, and can't be controlled per-packet. >> >> Luis: Any chance of an open firmware release for the ZD1211, similarly >> to what was done for AR9170/ZD1221? That would probably allow for >> fixing these problems. > > I had asked a while back and there is no immediate motivation. I should > note for ar9170 I did all the review myself during my own time, and can't say > I have enough interest to do so for zd1211 as I can use my time to focus > on *newer* items. I'm not even sure about the compiler that was used and > still have yet to see more developer interest on ar9170.fw before making > arguments in favor for any other release. > > BTW use my mc...@gm... address if you want a quicker reponse, I tend > to use my atheros address only for internal stuff. > > Luis > I understand your concern. So far the current state of the driver is usable to me. Bad performance in monitor mode is not a problem since I only use it for debugging. Regards, Benoit |