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 <t...@hms.se> 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-boun...@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 <t...@hms.se <mailto:t...@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-boun...@wireshark.org > <mailto:wireshark-dev-boun...@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 > <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 <t...@hms.se <mailto:t...@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: > > > > 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: t...@hms.se <mailto:t...@hms.se> > 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 <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 > <https://www.wireshark.org/lists/wireshark-dev> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > <https://www.wireshark.org/mailman/options/wireshark-dev> > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > <mailto:wireshark-dev-requ...@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 > <https://www.wireshark.org/lists/wireshark-dev> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > <https://www.wireshark.org/mailman/options/wireshark-dev> > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > <mailto:wireshark-dev-requ...@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-requ...@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-requ...@wireshark.org?subject=unsubscribe
