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 [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
