radiotap.netbsd.org archive mirror
 help / color / mirror / Atom feed
* Bad FCS flag
@ 2008-09-05 20:25 Johannes Berg
       [not found] ` <1220646325.11109.21.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2008-09-05 20:25 UTC (permalink / raw)
  To: radiotap

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Hi,

Sorry I haven't actually updated my proposal, had other stuff.

Here's a representation of the non-conflict we're running into with RX
flags:

 * wireshark defines that bit 6 in field 1 ("flags") means "bad FCS".
 * the unofficial RX-flags stuff defines that bit 0 in "RX flags" means
   "bad FCS"

I want to avoid having _two_ "bad FCS" bits and chose the RX flags one
to leave room for possible generic flags in "flags"/1, but I don't
really care either way.

Opinions?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bad FCS flag
       [not found] ` <1220646325.11109.21.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
@ 2008-09-05 20:38   ` David Young
       [not found]     ` <20080905203839.GV29499-eZ+MEZF6i8Dc+919tysfdA@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: David Young @ 2008-09-05 20:38 UTC (permalink / raw)
  To: radiotap

On Fri, Sep 05, 2008 at 10:25:24PM +0200, Johannes Berg wrote:
> Hi,
> 
> Sorry I haven't actually updated my proposal, had other stuff.
> 
> Here's a representation of the non-conflict we're running into with RX
> flags:
> 
>  * wireshark defines that bit 6 in field 1 ("flags") means "bad FCS".

Johannes,

TCPDump uses this bit, too.  I think that we are stuck with it.

>  * the unofficial RX-flags stuff defines that bit 0 in "RX flags" means
>    "bad FCS"

Any users of this bit?

I think that TCPDump & Wireshark probably out-number the radiotap
interpreters who use the rx-flags bit :-), but I don't know how many
drivers there are who write headers with "bad FCS" in the rx flags bit.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933 ext 24

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bad FCS flag
       [not found]     ` <20080905203839.GV29499-eZ+MEZF6i8Dc+919tysfdA@public.gmane.org>
@ 2008-09-05 20:44       ` Johannes Berg
  0 siblings, 0 replies; 3+ messages in thread
From: Johannes Berg @ 2008-09-05 20:44 UTC (permalink / raw)
  To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]


> TCPDump uses this bit, too.  I think that we are stuck with it.

Alright. I'll amend my old proposal to drop the shortGI bit for now (not
interested in 11n, let somebody else define those things) and make this
the "bad FCS" bit rather than the first bit in "RX flags".

> >  * the unofficial RX-flags stuff defines that bit 0 in "RX flags" means
> >    "bad FCS"
> 
> Any users of this bit?

Not sure, I think we might create it in Linux, but it's easy to change.

> I think that TCPDump & Wireshark probably out-number the radiotap
> interpreters who use the rx-flags bit :-), but I don't know how many
> drivers there are who write headers with "bad FCS" in the rx flags bit.

Yeah. I'll mark the RX flags bit as reserved though so we don't run into
odd things there.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-09-05 20:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-05 20:25 Bad FCS flag Johannes Berg
     [not found] ` <1220646325.11109.21.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
2008-09-05 20:38   ` David Young
     [not found]     ` <20080905203839.GV29499-eZ+MEZF6i8Dc+919tysfdA@public.gmane.org>
2008-09-05 20:44       ` Johannes Berg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).