3

I'm debugging a Linux embedded platform which has an interface where regular ethernet frames have an additional 82-octet platform header tacked on the front. I am able to sniff from this interface using tcpdump, but tcpdump is not able to usefully decode because the ethernet headers are not starting where it expects them to. Thus all I can see is a hex dump with the -x option, but for convenience I would like tcpdump to decode them. I am not interested in the contents of 82-octet header, but would like to see a decode of the subsequent encapsulated ethernet frame.

Is there a way I can tell tcpdump to start decoding the ethernet header starting 82 octets offset from the start of the captured packet, rather than the usual 0 octets?

2 Answers 2

2

Not other than modifying tcpdump source.

If you want to do that, I'd suggest either using one of the DLT_USERn DLT_/LINKTYPE_ values for that device, or getting one officially assigned by tcpdump.org, hacking libpcap to return that DLT_ value for those devices, and hacking tcpdump to decode that by skipping (or decoding, if useful) the 82-octet platform header.

1
1

I ran into this again, forgetting I had asked this question but google brought me right back here :).

I figured out a workaround for this if you happen to have editcap (from wireshark) available. No source-code changes necessary:

tcpdump -i eth0 -w - | editcap -C 82 - - | tcpdump -r -

The first tcpdump invocation captures packets and dumps them in pcap format into a pipe. editcap then chops off 82 bytes from the start of each packet in the pcap packet stream. Then the final tcpdump invocation reads the pcap packet stream and dissects it as normal.

Note that the pipes cause a good deal of buffering, so output is not necessarily immediate. tcpdump has the -l option for line-oriented buffering, but even with stdbuf -i0 -o0 I wasn't able to remove buffering completely. YMMV.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .