Re: Capturing FCS error frames using b43 driver
On Feb 17, 2009, at 11:54 PM, Michael Buesch wrote: Please read the code. There are lots of sanity checks in b43 and mac80211 that make it impossible to receive completely corrupted frames. I reconsidered this message because I too did some tests in capturing frames with proprietary firmware. As Bo said, we can capture corrupted frames with R351 but we can't with R410. The reason is that this firmware seems to not even check whether or not bit B43_MACCTL_KEEP_BAD is set so I believe no kernel patch could correct this problem, because it is on the firmware side. Cheers, -FG On Tuesday 17 February 2009 23:05:51 Bo Han wrote: Hi, I am interested in capturing FCS error frames using b43 driver. My hardware information is as follows. b43-phy9: Broadcom 4318 WLAN found b43-phy9 debug: Found PHY: Analog 3, Type 2, Revision 7 b43-phy9 debuf: Found Radio: Manuf 0x17f, Version 0x2050, Revision 8 I am using firmware version 410.2160 with linux kernel version 2.6.27.10. I told the firmware to keep the bad frames by setting ctl |= B43_MACCTL_KEEP_BAD just before b43_write32(dev, b43_MMIO_MACCTL, ctl) in b43_adjust_mode(...) in main.c. From b43_rx(...) in xmit.c, I can only see packets dropped because their rate_idx == -1. The length of all the dropped packets is 80 bytes and they look like the following: 8fae 0308 0b01 0085 1500 482c 50b3 0b01 0085 5fa0 1500 482c 50b3 0003 850b cdcc 1b00 1d00 b945 c0cd b905 630a 5e10 0101 0601 0b06 000b 07d6 bab9 addb 35fd 33e8 cd8f 8eaa 6f77 b9e8 However, there is still no packet received with macstat B43_RX_MAC_FCSERR. I also tried the 351 firmware for which I saw several FCS error frames in PIO mode. But the sniffing tools like Wireshark cannot get any packets. including the correct ones, when using that firmware. Am I missing something? Thanks, -Bo -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Capturing FCS error frames using b43 driver
On Feb 18, 2009, at 11:15 AM, Michael Buesch wrote:
On Wednesday 18 February 2009 03:33:01 Francesco Gringoli wrote:
On Feb 18, 2009, at 12:23 AM, Michael Buesch wrote:
On Wednesday 18 February 2009 00:07:56 Bo Han wrote:
I think I am working on the first sanity check in the driver, but
still
cannot see any FCS error frames. Is setting B43_MACCTL_KEEP_BAD
the only
thing we need to do for the firmware?
No. I suggest you don't touch that flag anyway and change the
corresponding
mac80211 filter flag. You most likely can do that through cfg80211/
nl80211/iw.
It will take care to set the b43 flag.
Michael is right, the new iw interface eases all this stuff.
There are however a few points that should be discussed
- why b43_rx(...) (in xmit.c) does not mark the status with
RX_FLAG_FAILED_FCS_CRC when the firmware reports a B43_RX_MAC_FCSERR:
IMHO this should be done to prevent mac80211 to be corrupted and
crash
the pc when a _very_ noisy frame arrives
Well, I think the mac80211 flag was invented afterwards. Remember
that b43
was the first mac80211 driver ever and quite a few things didn't
exist when
I ported the stuff.
So do you care to send a patch?
ok, I will send.
Anyway, could you elaborate why you think it would _crash_? I think
it shouldn't
crash in any case.
No. But I have to analyze more because I think there is a problem with
the firmware too (all firmwares) that not always sets up correctly the
corrupted frame flag when the KEEP_BAD_FRAME bit is activated. I will
check this and what happens when KEEP_BAD_FRAME is set and we have a
mistake even at the plcp sublayer (see below).
However, if RX_FLAG_FAILED_FCS_CRC is not set up in the status field,
mac80211 will process this frame: should not be something related to
the skb, probably somewhere it is shortened without checking its
actual size, as mac80211 trusts the driver that should already had
checked that the skb size correspond to something written in some
header, well, just speculating, I'm confused about.
- is that correct to have status.rate_idx filled by functions
b43_plcp_get_bitrate_idx_ofdm and b43_plcp_get_bitrate_idx_cck that
compute those values reading the plcp?
Yes I think so. This seems to be the best way to do it.
After some thoughts I'm wondering how these fields could be wrong
since the PLCP is protected on its own by another checksum external to
MPDU. Probably the firmware keep also frames whose PLCP is wrong,
while b43_rx only check for FCS problems within the MPDU. Will
investigate.
When a frame is ok, values are
correct and mac80211 uses them without problems. If instead the frame
is not ok, then mac80211 can warn a lot of message because values are
out of range.
If the PLCP header is corrupt you're completely fucked anyway.
It is a basic and safe assumption that the PLCP header is correct.
But it shouldn't _crash_ if it's not correct. But I think it doesn't.
Well, I think that capturing noisy frames is interesting for all those
guys willing to use data for research purposes without buying a
network analyzer that basically do the same...
So if you crank up the flags to pass PLCP corrupted frames it's kind
of
expected that they are dropped somewhere in the driver, because we
cannot
trust the contents of the frame anyway.
How do we know the PLCP length field is still correct for a
corrupted PLCP?
So we don't even know if the frame would have the correct length.
Should not we parse these values when FCS is bad and
sanitize them if out of range so that dmesg does not get filled with
warnings?
These warnings were removed some time ago. Please update your kernel.
Uhm... I updated it before writing this mail to check about this
possibility but I believed these warns were still there
[taken from __ieee80211_rx() pulled from git yesterday night]
if (status-flag RX_FLAG_HT) {
/* rate_idx is MCS index */
if (WARN_ON(status-rate_idx 0 ||
status-rate_idx = 76))
return;
/* HT rates are not in the table - use the highest
legacy rate
* for now since other parts of mac80211 may not yet
be fully
* MCS aware. */
rate = sband-bitrates[sband-n_bitrates - 1];
} else {
if (WARN_ON(status-rate_idx 0 ||
status-rate_idx = sband-n_bitrates))
return;
rate = sband-bitrates[status-rate_idx];
}
Or probably there is another method to get those values,
e.g., the firmware can provide them reading from the radio instead of
computing them reading fields from the plcp?
I don't see why this is necessary and how it would be possible.
You are right, we have simply to trash real noise (frames whose plcp
was corrupted) so to avoid to decode the Microwave Owen as you were
Re: Capturing FCS error frames using b43 driver
On Wednesday 18 February 2009 12:51:13 Francesco Gringoli wrote:
- is that correct to have status.rate_idx filled by functions
b43_plcp_get_bitrate_idx_ofdm and b43_plcp_get_bitrate_idx_cck that
compute those values reading the plcp?
Yes I think so. This seems to be the best way to do it.
After some thoughts I'm wondering how these fields could be wrong
since the PLCP is protected on its own by another checksum external to
MPDU.
Yes you're right.
Probably the firmware keep also frames whose PLCP is wrong,
while b43_rx only check for FCS problems within the MPDU. Will
investigate.
Well, there is a bug that misaligned frames are sometimes passed up to the
driver.
It happens with any firmware and any driver (including open fw).
So it might be a silicon bug in the DMA. I'm not sure yet.
So you'll hit the rate_idx failure from time to time. That's expected and
nonfatal.
It just happens for one packet of say 1000. I don't really know.
If the PLCP header is corrupt you're completely fucked anyway.
It is a basic and safe assumption that the PLCP header is correct.
But it shouldn't _crash_ if it's not correct. But I think it doesn't.
Well, I think that capturing noisy frames is interesting for all those
guys willing to use data for research purposes without buying a
network analyzer that basically do the same...
Note that the PLCP is casted into hardware. You cannot change it or else
you will corrupt basic assumptions in the radio silicon.
So you better not touch it or buy a radio analyzer.
That's simply a limitation of the consumer hardware.
These warnings were removed some time ago. Please update your kernel.
Uhm... I updated it before writing this mail to check about this
possibility but I believed these warns were still there
[taken from __ieee80211_rx() pulled from git yesterday night]
if (status-flag RX_FLAG_HT) {
/* rate_idx is MCS index */
if (WARN_ON(status-rate_idx 0 ||
status-rate_idx = 76))
return;
/* HT rates are not in the table - use the highest
legacy rate
* for now since other parts of mac80211 may not yet
be fully
* MCS aware. */
rate = sband-bitrates[sband-n_bitrates - 1];
} else {
if (WARN_ON(status-rate_idx 0 ||
status-rate_idx = sband-n_bitrates))
return;
rate = sband-bitrates[status-rate_idx];
}
Ok, well. I don't know about mac80211. But the warnings in b43 were removed
(also some warnings were removed in mac80211).
I think these warnings should also be removed. You can do patches and send
them to Johannes.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Capturing FCS error frames using b43 driver
Please read the code. There are lots of sanity checks in b43 and mac80211 that make it impossible to receive completely corrupted frames. On Tuesday 17 February 2009 23:05:51 Bo Han wrote: Hi, I am interested in capturing FCS error frames using b43 driver. My hardware information is as follows. b43-phy9: Broadcom 4318 WLAN found b43-phy9 debug: Found PHY: Analog 3, Type 2, Revision 7 b43-phy9 debuf: Found Radio: Manuf 0x17f, Version 0x2050, Revision 8 I am using firmware version 410.2160 with linux kernel version 2.6.27.10. I told the firmware to keep the bad frames by setting ctl |= B43_MACCTL_KEEP_BAD just before b43_write32(dev, b43_MMIO_MACCTL, ctl) in b43_adjust_mode(...) in main.c. From b43_rx(...) in xmit.c, I can only see packets dropped because their rate_idx == -1. The length of all the dropped packets is 80 bytes and they look like the following: 8fae 0308 0b01 0085 1500 482c 50b3 0b01 0085 5fa0 1500 482c 50b3 0003 850b cdcc 1b00 1d00 b945 c0cd b905 630a 5e10 0101 0601 0b06 000b 07d6 bab9 addb 35fd 33e8 cd8f 8eaa 6f77 b9e8 However, there is still no packet received with macstat B43_RX_MAC_FCSERR. I also tried the 351 firmware for which I saw several FCS error frames in PIO mode. But the sniffing tools like Wireshark cannot get any packets. including the correct ones, when using that firmware. Am I missing something? Thanks, -Bo -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Capturing FCS error frames using b43 driver
I think I am working on the first sanity check in the driver, but still cannot see any FCS error frames. Is setting B43_MACCTL_KEEP_BAD the only thing we need to do for the firmware? Thanks, -Bo On Tue, Feb 17, 2009 at 5:54 PM, Michael Buesch m...@bu3sch.de wrote: Please read the code. There are lots of sanity checks in b43 and mac80211 that make it impossible to receive completely corrupted frames. On Tuesday 17 February 2009 23:05:51 Bo Han wrote: Hi, I am interested in capturing FCS error frames using b43 driver. My hardware information is as follows. b43-phy9: Broadcom 4318 WLAN found b43-phy9 debug: Found PHY: Analog 3, Type 2, Revision 7 b43-phy9 debuf: Found Radio: Manuf 0x17f, Version 0x2050, Revision 8 I am using firmware version 410.2160 with linux kernel version 2.6.27.10. I told the firmware to keep the bad frames by setting ctl |= B43_MACCTL_KEEP_BAD just before b43_write32(dev, b43_MMIO_MACCTL, ctl) in b43_adjust_mode(...) in main.c. From b43_rx(...) in xmit.c, I can only see packets dropped because their rate_idx == -1. The length of all the dropped packets is 80 bytes and they look like the following: 8fae 0308 0b01 0085 1500 482c 50b3 0b01 0085 5fa0 1500 482c 50b3 0003 850b cdcc 1b00 1d00 b945 c0cd b905 630a 5e10 0101 0601 0b06 000b 07d6 bab9 addb 35fd 33e8 cd8f 8eaa 6f77 b9e8 However, there is still no packet received with macstat B43_RX_MAC_FCSERR. I also tried the 351 firmware for which I saw several FCS error frames in PIO mode. But the sniffing tools like Wireshark cannot get any packets. including the correct ones, when using that firmware. Am I missing something? Thanks, -Bo -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Capturing FCS error frames using b43 driver
On Wednesday 18 February 2009 00:07:56 Bo Han wrote: I think I am working on the first sanity check in the driver, but still cannot see any FCS error frames. Is setting B43_MACCTL_KEEP_BAD the only thing we need to do for the firmware? No. I suggest you don't touch that flag anyway and change the corresponding mac80211 filter flag. You most likely can do that through cfg80211/nl80211/iw. It will take care to set the b43 flag. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Capturing FCS error frames using b43 driver
On Feb 18, 2009, at 12:23 AM, Michael Buesch wrote: On Wednesday 18 February 2009 00:07:56 Bo Han wrote: I think I am working on the first sanity check in the driver, but still cannot see any FCS error frames. Is setting B43_MACCTL_KEEP_BAD the only thing we need to do for the firmware? No. I suggest you don't touch that flag anyway and change the corresponding mac80211 filter flag. You most likely can do that through cfg80211/ nl80211/iw. It will take care to set the b43 flag. Michael is right, the new iw interface eases all this stuff. There are however a few points that should be discussed - why b43_rx(...) (in xmit.c) does not mark the status with RX_FLAG_FAILED_FCS_CRC when the firmware reports a B43_RX_MAC_FCSERR: IMHO this should be done to prevent mac80211 to be corrupted and crash the pc when a _very_ noisy frame arrives - is that correct to have status.rate_idx filled by functions b43_plcp_get_bitrate_idx_ofdm and b43_plcp_get_bitrate_idx_cck that compute those values reading the plcp? When a frame is ok, values are correct and mac80211 uses them without problems. If instead the frame is not ok, then mac80211 can warn a lot of message because values are out of range. Should not we parse these values when FCS is bad and sanitize them if out of range so that dmesg does not get filled with warnings? Or probably there is another method to get those values, e.g., the firmware can provide them reading from the radio instead of computing them reading fields from the plcp? - I noticed that when in monitor mode and when set up to keep bad frames, the radiotap header is not reporting FCS wrong for malformed or corrupted frame as it should be, is that correct? Should not the radiotap header be built on the status filled by first the driver then mac80211? Cheers, -FG -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
