RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* limit radiotap header size
@ 2014-09-15 20:10 freeman
       [not found] ` <loom.20140915T220101-881-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: freeman @ 2014-09-15 20:10 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw

Hi

Linux latest kernel (3.16) doc says there are only 13 argument options now.
Is it still true?

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 :)

Thanks
Freeman

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

* Re: limit radiotap header size
       [not found] ` <loom.20140915T220101-881-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
@ 2014-09-16 12:18   ` Johannes Berg
  2014-09-16 17:01     ` freeman
  0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2014-09-16 12:18 UTC (permalink / raw)
  To: freeman; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw

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

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

* Re: limit radiotap header size
  2014-09-16 12:18   ` Johannes Berg
@ 2014-09-16 17:01     ` freeman
       [not found]       ` <loom.20140916T185055-769-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: freeman @ 2014-09-16 17:01 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw

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
 

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

* Re: limit radiotap header size
       [not found]       ` <loom.20140916T185055-769-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
@ 2014-10-06 14:20         ` Johannes Berg
  0 siblings, 0 replies; 4+ messages in thread
From: Johannes Berg @ 2014-10-06 14:20 UTC (permalink / raw)
  To: freeman; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw

On Tue, 2014-09-16 at 17:01 +0000, freeman wrote:

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

That should probably just point to www.radiotap.org :)

> 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?

You can chose to include or not include any information that you want.
The minimal radiotap header has a zero bitmap and no information at all
- but it's also useless. The more data you include, the more useful it
becomes.

> 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.

There's no API to send such down. If you invent API to send such down,
then you can of course build the header limited.

However, many times the capturing and analysis are done as two separate
steps, with the analysis being after the fact on a different system
etc., so I'm not sure how useful that would be. For my purposes I'd try
to always enable the maximum amount of information...

johannes

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

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
     [not found]       ` <loom.20140916T185055-769-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2014-10-06 14:20         ` Johannes Berg

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git