Hi, Mike!
On Fri, 2005-06-24 at 10:05 -0400, Mike Kershaw wrote:
> > I'm not convinced that getting frames with bad CRC is a feature needed
> > by many users. I see your patch adds some documentation to FAQ, but I
> > have never seen any questions about reporting frames with bad CRC in
> > monitor mode. FAQ is not a replacement for documentation. It should
> > answer questions that are actually asked by the users.
>
> Were it in a mainstream driver, I would use it (and the userbase who
> would use it would likely expand accordingly): being able to detect and
> process frames with a bad FCS allows for noise and congestion statistics
> and processing and lets us leverage the drivers the same way commercial
> wireless survey solutions like Fluke and AirMagnet do.
OK, I'm not against it, but I don't know of any standard way to indicate
whether the packet has valid FCS or not. I believe such flag would be
useful for Kismet and other tools. I don't feel good about lumping all
packets together without having a flag to tell good ones from corrupted
ones.
I see that AVS headers have made it into the kernel
(drivers/net/wireless/prism54/islpci_eth.h), but there is no place for
CRC flag in them. Could you ask linux-wlan-ng developers to add such
flag?
Another approach would be to use an fake FCS. From a comment in
linux-wlan-ng, file hfa384x.c: "0xffffffff is used as a flag to indicate
the FCS is bogus". What if we use another number to indicate that the
FCS is bogus and the packet had an FCS error? Do you know any other
number that cannot be a valid FCS?
--
Regards,
Pavel Roskin
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
|
