Wireshark-users: Re: [Wireshark-users] OpenBSD enc0 capture from tcpdump failes to decode
From: Brad Guillory <[email protected]>
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  
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 },

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

Brad Guillory