Wireshark-users: Re: [Wireshark-users] OpenBSD enc0 capture from tcpdump failes to decode

From: Brad Guillory <brad@xxxxxxxxx>
Date: Fri, 25 Sep 2009 14:05:33 -0600

On Sep 25, 2009, at 12:53 PM, Guy Harris wrote:

Now, given that BSD/OS died a while ago, we could just treat a link-
layer type of 13 as "encapsulated IPSec packets".  (Of course, OpenBSD
could just write them out with a link-layer type of 109 in the file,
too - nothing *requires* that the value returned by pcap_datalink()
and the value in the file be the same, and, in fact, tcpdump.org's
libpcap maps them, precisely to *avoid* this problem.)

When I change the link type to 109 (6d) using a hex editor tshark was able to decode the packet so things look promising. Is there a tool that people regularly use to made this kind of change en-mass? I'm sure I can work something out in perl but I don't want to reinvent the wheel.

Try changing

#if defined(DLT_ATM_RFC1483) && (DLT_ATM_RFC1483 == 13)
	{ 13,		WTAP_ENCAP_ATM_RFC1483 },
#elif defined(DLT_ENC) && (DLT_ENC == 13)
	{ 13,		WTAP_ENCAP_ENC },
#endif

in wiretap/pcap-common.c in the Wireshark source to just

	{ 13,		WTAP_ENCAP_ENC },

and recompiling.

Making this change and recompiling works with unmodified capture files. Does the final solution need to be done here: ./epan/ dissectors/packet-enc.c?

It seems to me that if we make the change above it might break something for someone. But if we add the enc dissector to the end of linktype 13's chain, anything that fell through to the enc dissector was not going to decode anyway. I don't fully understand the architecture so that might be entirely wrongheaded.

I will try to code up an alternative to this fix that won't break anything else.

Thanks,

Brad Guillory