Re: pcapng decoding error when preamble is shortened

[Timmy Brolin <tib () hms se>]

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 () wireshark org> On Behalf Of Jaap Keuter
Sent: den 15 februari 2021 21:12
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
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 () hms se<mailto:tib () hms se>> 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 () wireshark org<mailto:wireshark-dev-bounces () wireshark org>> On Behalf 
Of Jaap Keuter
Sent: den 13 februari 2021 10:43
To: Developer support list for Wireshark <wireshark-dev () wireshark org<mailto:wireshark-dev () wireshark org>>
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 () hms se<mailto:tib () hms se>> 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:
[cid:image001.png@01D70448.F645E090]

Normal preamble, decoding successful:
[cid:image002.png@01D70448.F645E090]


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 () hms se<mailto:tib () hms se>
Direct: +46 35 17 29 32
[cid:image003.png@01D70448.F645E090]

HALMSTAD | BARCELONA | BEIJING | BOSTON | BUCHEN | CHICAGO | COVENTRY | DUBAI | HEDEL | IGUALADA |
KARLSRUHE | MILAN | MULHOUSE | NIVELLES | PUNE | RAVENSBURG | SEOUL | SINGAPORE | TOKYO | WETZLAR

www.hms-networks.com<http://www.hms-networks.com/>

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

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

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