Wireshark · Wireshark-dev: Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

[Timmy Brolin <tib@xxxxxx>]

Yes, the capture device is indeed capturing data completely accurately.

You are referring to the transmission section of IEEE 802.3br-2016.
If you look at the receive section on page 51, you will find that receivers are required to accept any length preamble. Hence, Wireshark is not compliant with the IEEE 802.3br-2016 specification.

It is just like the specification requires the FCS to always be transmitted correct, but receivers are required to also expect and handle an incorrect FCS without breaking down.

Wireshark does not require capture devices to repair any faulty FCS, does it?

Preamble reduction is quite common practice. In this particular case I have a SGMII RJ45 SFP on the network which randomly chops off one byte of the preamble on some packets. This is common and accepted behavior for various pieces of network equipment.

The entire point of using a mPacket capture device is to be able to correctly monitor and debug everything from the lowest to the highest level aspects of Ethernet.
All specification-compliant packets on the wire should decode properly in Wireshark, and Wireshark should not lie to the user about how the packet looks on the wire.

Regards,
Timmy Brolin

 

From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf Of Jaap Keuter
Sent: den 13 februari 2021 10:43
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

 

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

 

___________________________________________________________________________
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