[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

The capture file (View | Reload as File Format/Capture) contains an Interface Descriptor Block which states Link Type 274.

According to https://www.tcpdump.org/linktypes.html the Packet Data in the capture file must adhere to "mPackets, as specified by IEEE 802.3br Figure 99-4, starting with the preamble and always ending with a CRC field.” 

According to IEEE 802.3br-2016 the mPacket has either 

* 7 octets preamble (0x55), 1 octet SMD followed by the mData and 4 octets CRC.

* 6 octets preamble (0x55), 1 octet SMD, 1 octet fragment count followed by the mData and 4 octets CRC.

The first packet in the capture has 7 preamble octets and an SMD-E making it an Express Packet.

The second packet in the capture has 6 preamble octets, an SMD-E and a frag_count field of 0x01. That format does not align with the mPacket specification. The SMD has to be of a different type and the frag_count field has to be properly encoded.

In the second packet, when counting out from the SMD, the first and second sextet look like Ethernet MAC addresses (from the same device sending the first packet to the LLDP multicast address) with the LLDP ether type. So the intended mData seems to be a valid Ethernet packet. 

What is wrong though is that the capture device is creating a capture file, declaring to write Link Type 274 packet blocks, which are as defined in IEEE802.3br figure 99-4, but fails to adhere to that format in all circumstances. It assumes that writing short(-er) preambles is okay, but this violates the Link Type specification.

I can think of two reasons why this is done. 1) the capture device wants to record as accurately as possible what its receiver is able to detect on the wire. While that means that it may miss symbols due to its slicer still getting in sync, it shows what it can. 2) the capture devices misaligns the received symbols into the receive buffer, thereby distorting the intended receive frame.

From what you write it seems that reason 1) is applicable. Unfortunately the chosen Link Type is not suitable for this. The Link Type 274 is not intended for mPackets where the reader is to hunt for frame synchronisation. That task is left to the receiver before writing IEEE802.3br compliant mPackets in the file. Currently there is no defined Link Type for that, nor a dissector capable of this.

What you could do is to contact the supplier of the capture device and discuss the options, or write a program to correct these capture files before loading them in Wireshark.

Regards,

Jaap

On 9 Feb 2021, at 11:21, Timmy Brolin <tib@xxxxxx> wrote:

Hi,

 

It seems Wireshark fails to decode captured packets with shortened preamble?

 

Normally Ethernet packets have a preamble and SFD like this:
55555555555555D5

But during transmission over Ethernet, sometimes the preamble arrives slightly shorter at the receiving end. Some bytes, or even half a byte(!), at the start of the preamble can go missing for various technical reasons.

This is considered normal, and all Ethernet MACs are required to properly decode packets with shortened preamble, as well as packets where the preamble is a non-integer number of bytes.

But it seems Wireshark does not?

 

 

Decoding failure when preamble is shortened:

Normal preamble, decoding successful:

 

 

I have attached a pcapng file with these two packets.

 

Timmy Brolin
M.SC. Computer Systems Engineering

HMS Industrial Networks AB
Stationsgatan 37, Box 4126
300 04 Halmstad, Sweden

Email: tib@xxxxxx
Direct: +46 35 17 29 32

HALMSTAD | BARCELONA | BEIJING | BOSTON | BUCHEN | CHICAGO | COVENTRY | DUBAI | HEDEL | IGUALADA |

KARLSRUHE | MILAN | MULHOUSE | NIVELLES | PUNE | RAVENSBURG | SEOUL | SINGAPORE | TOKYO | WETZLAR

www.hms-networks.com

 

Attachment: shortened_preamble.pcapng
Description: Binary data

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe