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

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

It’s not a matter of *what* the program is reading, but *where* it's reading in the buffer. This makes it usable for *all* programs reading this file format, not just Wireshark. Prefixing it with zero padding (even a nibble) would achieve that.

I’m done.

On 16 Feb 2021, at 10:05, Timmy Brolin <tib@xxxxxx> wrote:

Hi,

 

Would anyone mind if I submit a merge request which makes Wireshark capable of dissecting all valid Ethernet mPackets according to IEEE 802.3br?

It is a reasonably small change. But I don’t want to put in the effort if the merge request would be blocked.

 

 

Jaap:

Note that Figure 99-4 has absolutely no information about how to dissect the CRC, SMD, FRAG_COUNT and PREAMBLE.

 

Wireshark

• Dissects the CRC according to section 99.3.6 and figure 99-6
• Dissects the SMD according to section 99.3.3 and figure 99-6
• Dissects the FRAG_COUNT according to section 99.3.4 and figure 99-6

But it does NOT dissect the PREAMBLE according to figure 99-6

 

Are you not reading a little too much into a single line of text on the tcpdump webpage?

If figure 99-4 is the only specification for ‘type 274 - LINKTYPE_ETHERNET_MPACKET’, do you think dissection of the CRC, SMD and FRAG_COUNT according to sections 99.3.3, 99.3.4, 99.3.6 and figure 99-6 should be removed from Wireshark?

 

The intention is obviously that pcapng type “LINKTYPE_ETHERNET_MPACKET” should be able to hold any and all valid Ethernet mPackets according to IEEE 802.3br.

Regards,
Timmy Brolin

 

 

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

 

Hi,

 

A not uncommon, but unfortunate misconception is that of Wireshark being a capture device, or receiver as you put it. In short Wireshark doesn’t capture, it is a program reading files, containing packets conforming to specifications as laid out in the Link Layer Header Types on the tcpdump website, among others. To accommodate users it does provide interfaces to capture filters, most famous to BPF via libpcap, and as of recent to Npcap, as well as extcaps. These programs are invoked to interface between the Link Layer (L2) and the wiretap interface build into Wireshark to read capture file formats. In that respect Wireshark sits on top of the Data Link Layer of whatever medium is underneath.

 

In the context of Ethernet, Wireshark indeed expects the capture filter to provide well-formed packets, starting at the first octet after the SFD and optionally with an FCS. The fact wether or not to accept a frame with an invalid FCS is up to the network driver combined with the hardware (MAC/PHY). In normal cases the driver/hardware does filter out incorrect frames, either for their destination MAC not matching, invalid FCS, but also short frames (<64 octets), too long frames (jabber), or otherwise corrupted frames. To allow for wider packet sniffing capabilities some of these checks can be configured being off, the promiscuous mode. This holds true for destination MAC and FCS and maybe others.

 

Regardless of mode (promiscuous or normal) the capture filter is still expected to deliver the packet beginning with the first octet of the destination MAC address. Whether or not the FCS is to be part of the captured packet is a bit of a contentious subject, but there’s no ambiguity about where the captured packet should begin. That is at the first octet after the SFD. The MAC is reponsible to hunt for this frame synchronisation, the capture filter is sending the correctly aligned packet to the capture engine.

 

Where the format for Ethernet (Link Layer Header Type 1) is somewhat loosely defined as "IEEE 802.3 Ethernet”, in case of Link Layer Header Type 274 this is made very explicit:

"mPackets, as specified by IEEE 802.3br Figure 99-4, starting with the preamble and always ending with a CRC field.” Notwithstanding the text and/or figures in the rest of this IEEE standard, this figure is the format to which packets need to adhere in order to be valid packets of Link Layer Header Type 274. To accommodate an even lower level of IEEE 802.3br packet reception an additional Link Layer Header Type would need to be defined, with additional specification of the packets’ physical reception characteristics. The number of received preamble symbols would be one of them, the IPG length could be another, and maybe even other data for TSN purposes. This would then be an evolved alternative to the currently defined Link Layer Header Type for capture filters that requires this. Or a Link Layer Header Type with a pseudo header containing these physical reception characteristics of the packet, followed by the mPacket data as per Figure 99-4. This would then be alike Link Layer Header Type 127, "Radiotap link-layer information followed by an 802.11 header.”, where the existing IEEE 802.11 dissector is being reused, while providing extra reception information from the Radiotap header.

 

Regards,

Jaap

 

 

 

On 14 Feb 2021, at 00:57, Timmy Brolin <tib@xxxxxx> wrote:

 

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

 

___________________________________________________________________________
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

 

___________________________________________________________________________
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