On Jul 20, 2017, at 4:47 AM, Mihai Cîrîc via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:
> I have some capture files with packets encapsulated under ethernet. But
> these packets have a short header before the mac addresses
So you have
1) a header prepended before the Ethernet header
and
2) a protocol that runs on top of Ethernet, which means it has an Ethertype or an 802.2 SAP or a SNAP OUI/PID pair or the OUI Extended EtherType followed by an OUI/PID pair to identify it, and a payload that follows that.
This means you have *two separate* items.
Given that there's a header before the Ethernet header, the link-layer header type for your packets is *not* Ethernet, and whatever file format is used should use an identifier *other* than that file format's identifier for Ethernet traffic; for example, for pcap or pcapng files, the link-layer header type in the pcap file header or the pcapng Interface Description block should *NOT* be LINKTYPE_ETHERNET, i.e. it shouldn't be 1.
Then you should have a dissector that parses the header that comes before the Ethernet header and then calls the Ethernet dissector, and that dissector should be connected to the Wireshark link-layer header type value for those packets, so that *it* is called for files with that type of packet.
If these packets are in pcap or pcapng files, then:
1) you could use one of the LINKTYPE_USERn types, as per the suggestion in John Thacker's email;
2) you could get a permanently-assigned LINKTYPE_ value assigned, by sending an email to tcpdump-workers@xxxxxxxxxxxxxxxxx, and use that, and then add a new WTAP_ENCAP_ value, edit wiretap/pcap-common.c to map that LINKTYPE_ value to the new WTAP_ENCAP_ value, and have your dissector register in the wrap_encap dissector table for that WTAP_ENCAP_ value.