On Tue, Mar 15, 2011 at 6:41 PM, Guy Harris <[email protected]> wrote:
> On Mar 15, 2011, at 5:58 PM, Sam Roberts wrote:
>> Whether or not the radio chips give the FCS to you when you run them
>> in sniffer mode depends on the chip. Many just validate the FCS, strip
>> it, and pass you the packet minus the FCS, but some give you the whole
>> packet, including the FCS. And some don't give you the FCS, they
>> replace it with a 2 byte indication of signal strength and quality,
>> which is useful,but unfortunately including that in the pcap would
>> require a different DLT_ type, because it is no longer a standard
>> physical layer frame.
>
> Yes, and it probably *SHOULD* get a different LINKTYPE_/DLT_ value, so that 
> it can be included in captures and dissected by programs that do captures and 
> read capture files.  (If it could be moved to the beginning of the packet 
> without doing any copying other than of the 2 bytes in question, that would 
> probably be best.)

It can, but the meaning might be specific to that chipset, I don't
know enough about the physical layer to comment. It took us a while to
figure out this was what was happening (as an FCS, it didn't compute).

>> How is it a heuristic to notice that the entire packet is not present
>> in the pcap?
>
> It's a heuristic to deduce that this is because the FCS wasn't provided by 
> the capture hardware rather than because the user captured with a "-s" flag.

Why would anyone want to deduce this? In wireshark, both dlt values
will map to the same dissector, and maybe they will bother putting
some kind of 'no FCS' phrase on the link layer section, but who cares
when looking at a PCAP about the internal details of the the capture
chip?

If a company makes an ethernet tap device, and for some reason, made
it refuse to return more than the first 60 bytes of ethernet frames
even with tcpdump -s80 (maybe its "super performance mode"), would you
allocate me a new DLT type, or just say I wrote broken hardware?

Cheers,
Sam
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Reply via email to