RadioTap Archive mirror
 help / color / mirror / Atom feed

From: freeman <freeman.wang-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
To: radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org
Subject: Re: limit radiotap header size
Date: Tue, 16 Sep 2014 17:01:30 +0000 (UTC)	[thread overview]
Message-ID: <loom.20140916T185055-769@post.gmane.org> (raw)
In-Reply-To: 1410869888.2335.6.camel@jlt4.sipsolutions.net

Johannes Berg <johannes@...> writes:

> 
> On Mon, 2014-09-15 at 20:10 +0000, freeman wrote:
> 
> > Linux latest kernel (3.16) doc says there are only 13 argument options now.
> > Is it still true?
> 
> Where does it say that? I don't think there's any size limit on the
> radiotap header since multiple things could show up multiple times etc.
> and with the vendor namespace you could carry all kinds of other things.
> 
> > If we are concerned about the size of radiotap header and want to limit the
> > set of info we pass to the sniffer, can we arbitrarily remove any arguments
> > from the bitmap? I know it is probably designed so, just want to double
check :)
> 
> Not really, no, you'd have to adjust the rest of the header as well,
> basically parse and recreate it. Why would you want to anyway though?
> 
> johannes
> 
> 

Johannes

Thanks for the help.
It seems this kernel doc needs some update
http://lxr.free-electrons.com/source/Documentation/networking/radiotap-headers.txt

I think I was not clear in last email. If we have a tiny firmware to
generate the radiotap header for received packets, and we have limited RAM,
it might look attractive to only create a trimmed version radiotap header to
the sniffer application. 

Given the design of the bitmap in the fixed header, I guess it allows us to
only include a subset of all arguments, although it is always better to have
more info sent up. So in memory constrained systems, how much freedom we
have in creating radiotap headers?

My dream is that a user application can send a 32bit bitmap to the device
driver as a bitmask and the device only sends up those arguments enabled by
the mask.

Thanks
Freeman
 

next prev parent reply	other threads:[~2014-09-16 17:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 20:10 limit radiotap header size freeman
     [not found] ` <loom.20140915T220101-881-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2014-09-16 12:18   ` Johannes Berg
2014-09-16 17:01     ` freeman [this message]
     [not found]       ` <loom.20140916T185055-769-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2014-10-06 14:20         ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20140916T185055-769@post.gmane.org \
    --to=freeman.wang-dy08kvg/lbpwk0htik3j/w@public.gmane.org \
    --cc=radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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 read-only IMAP folder(s) and NNTP newsgroup(s).