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
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 poss
Re: BCM4322 and b43 driver
On Wednesday 18 February 2009 03:40:24 Celejar wrote: > On Tue, 17 Feb 2009 11:35:16 -0600 > Larry Finger wrote: > > > Rafał Miłecki wrote: > > > 2009/2/16 Larry Finger : > > >> We are making progress. The last bits of the specs for the LP version > > >> were added > > >> to the specs last week, and the next RE push will be on the N PHY code. > > > > > > Do I understand right? Specification for LP PHY is 100% complete now?? > > > > > > Wow, that sounds great, why didn't you make any announcement on > > > bcm43xx-dev!? :) Congratulations for that whole work! :) > > > > I guess I should have. I did announce that I had finished to Michael > > Buesch, who > > is the only one working on converting specs to code. > > Thanks very much! I'm looking forward to finally getting OpenWrt with > 2.6 working on my Asus 520gu. If there's any testing I can do when > Michael starts releasing code, I'll certainly be glad to do it. I am releasing the code as I write it. I'll never pile up patches locally. So wireless-testing will contain tip LP code. Of course, there's nothing to test, yet. I'll announce on the list when people can start testing. -- 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 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? Anyway, could you elaborate why you think it would _crash_? I think it shouldn't crash in any case. > - 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. > 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. 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. > 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. > - 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? I neither know nor care. If you do, please send patches. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
