On Apr 9, 2012, at 2:08 PM, Elliot Parsons wrote:
> I am working with an 802.3ah system. I have a third party packet capture device with its own packet processor, but I would like to have some of Wireshark's capabilities for processing the capture file offline.
>
> 802.3ah contains an Ethernet frame, but it adds a 6 byte preamble that contains a link layer id along with other information.
Is that the modified preamble as described in section 65.1.3.2 "Transmit" of 802.3-2008, with octet 3 of the 7-octet preamble replaced by a start of LLID delimiter (0xd5), octets 6 and 7 of the preamble replaced by a mode and logical link ID, and the SFD replaced by a CRC over octets 3 through 7 of the preamble? If so, what are the other 3 octets (or 4 octets if the 6-byte preamble doesn't include the CRC)?
> I have written a dissector to process this 6 byte preamble, which ends up calling the standard Ethernet dissector when it is complete. I currently know of two ways of kicking off this 802.3ah dissector:
>
> 1) Change the capture type in the header of the PCAP file.
>
> 2) Add a check in the Ethernet dissector that looks for the start of the 802.3ah preamble for each packet. This check is only enabled if an 802.3ah option is selected for Ethernet parsing.
>
> Is either of these methods preferred, or is there another way to start the new dissector that I have not considered?
I would vote for 1).
If a point-to-multipoint network is treated as a collection of (virtual) point-to-point networks, then a capture could be done on one of those networks, at the MAC layer, and it would just be a regular Ethernet (LINKTYPE_ETHERNET/DLT_EN10MB) capture.
For a capture at the reconciliation sublayer, capturing the more "raw" P2MP packets, there should be a separate link-layer header type value, defined to have the preamble (in some form) followed by a standard Ethernet frame.
This would obviate the need for a heuristic (heuristics are always ugly, even if necessary) and a preference setting.
