On Apr 28, 2013, at 8:54 AM, Luís Correia <lfpcorr...@gmail.com> wrote:

> Indeed I've seen a radiotap_iterator function in radiotap headers. But the 
> function "logic" was a little heavy for a 400mhz MIPS CPU. No?

Maybe *that* iteration logic is heavy, but some iteration logic is a 
*requirement*, unless:

        you know what the driver is adding as a radiotap header, and can make 
sure you know when the driver changes what it adds;

        the driver *always* puts out the *exact* same set of fields on *every* 
packet;

        if the driver injects *transmitted* packets into the capture path, then 
either "*every* packet" includes *transmitted* packets (so that the received 
signal strength field is put into the transmitted packets!) or you can 
distinguish between received and transmitted packets and will not look at the 
radiotap header on transmitted packets.

Note, by the way, that if the radiotap header length is not the same on all 
received packets, the header is not putting out the exact same set of fields on 
every packet.

If you cannot be 100% certain of all of those, you *CANNOT* assume that a given 
field will be at the same location in the header for all packets.

> From what I have read the parse packet function should be as fast as 
> possible.. what's your opinion on that? 

"As possible" is the key here.  To quote a line attributed to Albert Einstein, 
"Everything should be made as simple as possible, but no simpler."  "Simpler 
than possible" might include "no iterator" here.

> Do you think I should copy each packet for latter processing or do I have 
> "room" for in-flight processing?

Iteration has nothing to do with copying packets.  You don't need to copy the 
packet to use the presence bits as intended.

> Can't I just bit test the it_present field for one of the two rssi readings 
> and access the struct field?

Not unless you can achieve *all* of the conditions in my list above.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Reply via email to