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
