>Hello, Francesco!
Hi, Pavel, sorry for the delay, but I was out of office and whan I came
back I found I had my disk broken :-( I may also have lost some mail
sent on Friday.
>On Wed, 2005-06-01 at 10:54 +0200, Francesco Potorti` wrote:
>> Following up to my previous announcement, here is a slightly revised
>> patch. Now the ignore_crc flag is per device, rather than per driver.
>>
>> See <ftp://fly.isti.cnr.it/pub/software/linux/orinoco/>.
>>
>> I think I also understand the reason why I could not use the 0.15
>> series, so I hope that I will be posting a patch for that series too.
>
>I have fixed 2.4 support in CVS (all branches). The drivers compiles,
>but I wasn't able to test it on 2.4 kernels yet.
I will as soon as I find the time and let you all know.
>I'm not convinced that getting frames with bad CRC is a feature needed
>by many users.
In fact, the only usage of this feature I can think of is experimental:
making statistics on the kind of bit errors you get (I am working on
this), or working on using corrupted data for streaming applications
that can make use of partially wrong data, as long as they arrive on
time, which can be true true of both audio and video (I know people
working on that). Also things like differential encoding of data inside
the same frame, so that at least part of the data can be recovered.
> 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.
I added two things to the README file:
- text copied from <http://airsnort.shmoo.com/orinocoinfo.html> that
describes how to use Mike Kershaw's monitor mode
- text that I wrote that describes how to use my patch for ignoring CRC
Mike Kershaw:
>> 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.
Hi Mike.
If only for statistics of number and distribution of corrupted packets
(as opposed to number and distribution of corrupted bits), then you do
not need to get the packets with wrong CRC, but only their number.
Accessing the stats that the driver already collects would be enough,
but I have not seen any way to do it. (Well, I did not investigate so
deeply, to be true.)
Pavel Roskin:
>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.
If you are interested in bad packets for looking what's inside and
examining the wrong bits, then in any case you need to know what were
the original data. So a flag telling that the packet you receive has a
bad CRC is not absolutely necessary, because you can always compare the
received thata with th original ones.
That said, it would certainly be useful to have such a flag. It is also
reasonable that you can get such information only in monitor mode. So,
if you enable both bad_crc and monitor mode, you have a flag per packet
telling you whether the packet has a good crc. But if you only enable
bad_crc mode, and not monitor mode, you don't get this info. The most
natural place where to put the flag would be the Prism2 header, but I
don't know if we are free to add a field to the Prism2 header without
breaking other applications. Possibly yes, as I see the the Prism2
header has a sort of self-describing structure.
>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?
No, all other values are legal. But what is a "bogus CRC"? Maybe we
can use just the 0xffffffff value for indicating a bad CRC value, when
the bad_crc mode is enabled.
Mike Kershaw:
>Think of RT as super-avs, with cross-os compatability. Ethereal (and
>maybe tcpdump) and kismet all already understand it. If it looks like
>we may not be moving to radiotap, I'll get in touch with the avs folks.
>
>You can see the RT headers here:
>http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net80211/ieee80211_radiotap.h?rev=1.11&content-type=text/x-cvsweb-markup
>
>Radiotap, incidentally, also solves the FCS problem by defining header
>flags for if we have it or not.
Okay, when these go into the kernel then that will probably be the right
place for the flag.
But again: if the purpose is counting the number of corrupted packet,
what we need in fact is a way to access the stats from the driver.
--
Francesco Potortì (ricercatore) Voice: +39 050 315 3058 (op.2111)
ISTI - Area della ricerca CNR Fax: +39 050 313 8091
via G. Moruzzi 1, I-56124 Pisa Email:
Potorti-8I8jPFND8kM1GQ1Ptb7lUw@xxxxxxxxxxxxxxxx
Web: http://fly.isti.cnr.it/ Key: fly.isti.cnr.it/public.key
-------------------------------------------------------
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
|
