[Timmy Brolin <tib@xxxxxx>]

I have submitted a proposal here:

https://gitlab.com/wireshark/wireshark/-/merge_requests/2137

 

* Added support for dissecting mPackets with arbitrary preamble length, in accordance with IEEE 802.3br-2016

   Changed fpp.preamble type from FT_UINT64 to FT_BYTES

* Use PACK_FLAGS_UNALIGNED_FRAME to signal non-integer preamble length.
   Added fpp.preamble.pad to indicate any alignment padding bits inserted by capture device.

* Added missing printouts of SMD types i.e. SMD-E, SMD-V, SMD-R, SMD-S0, ...

* Added missing printouts of decoded fragment numbers i.e. 0, 1, 2, 3

 

 

 

Here it is shown dissecting a mPacket with shortened preamble.

I have added some decoding texts which were missing before. New decoding texts are marked in green.

 

 

I interpret the flag PACK_FLAGS_UNALIGNED_FRAME as an indication that the capture device had to insert 4 bits at the beginning of the preamble due to non-integer preamble length.
An alternative interpretation could be that PACK_FLAGS_UNALIGNED_FRAME signals that the capture device had chopped off 4 bits to accomplish alignment. As far as I can tell, PACK_FLAGS_UNALIGNED_FRAME is not precisely defined anywhere.

I prefer the former interpretation since the alternative involves losing 4 bits of capture data.

The dissector shows the alignment padding as a 4bit field, and also takes it into account in the displayed preamble reduction.

28 bits = 3.5 Bytes of missing preamble in this case.

 

 

 

And this is a mPacket with normal preamble:

 

 

-----Original Message-----
From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf Of Timmy Brolin
Sent: den 16 februari 2021 13:27
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

 

Sorry, I forgot answering this:

 

> On the *transmission* side, you're supposed to transmit 7 octet of preamble; I haven't seen anything about reducing the size of the *transmitted* preamble being acceptable behavior.

 

The real world does unfortunately not align perfectly with the IEEE specification in this regard.

 

It has become rather common practice for Ethernet PHY components to randomly reduce preamble in TX, RX or both, directions. By 0, 4, or 8 bits.

They do it because it helps them get the data across internal clock domain crossings without increasing latency or jitter.

 

I would say about a third of all PHYs out in the world does this.

And I think virtually all RJ45 SFPs on the market does it.

 

 

Another case is the industrial Ethernet protocol Profinet, where preamble reduction can be enabled as a user configurable option to increase network performance. I think they reduce it down to just one byte if I recall correctly.

Profinet uses a lot of small Ethernet frames, which makes the preamble a significant waste of bandwidth for them.

 

 

 

-----Original Message-----

From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf Of Timmy Brolin

Sent: den 16 februari 2021 13:03

To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>

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

 

> Section 12.9.2 "DTE timing" of IEEE Std 802.3-2018 says:

>                          DTEs shall correctly receive frames that are preceded by 13 or more bits of preamble plus 8 bits of <sfd>.

> which I assume means that, on the *receiving* end, if you miss up to 43 bits of the 56-bit preamble - or up to 35 bits of the 48-bit preamble in some mPackets - once you're synced up, and see the SFD, you should continue the reception process and hand what you have up to the MAC sublayer.

 

Exactly.

 

 

> Once frame preemption is introduced, the packet capture can be at various layers:

>                          3) at the Reconciliation Sublayer, in which case they get bit streams for packets, again including the preamble and SFD.

> To get mPackets, the tap would, I think, have to be at 3).

> 

> That means that, if the *received* preamble can be as little as 13 bits, the mPacket could have as few as 13 bits of preamble, meaning that neatly aligning the packet for dissection could involve a lot of bit shifting.

> Is that what you're proposing?

 

 

Yes. mPackets require hardware capture at the Reconciliation Sublayer (or lower).

The Reconciliation Sublayer is however not really a bit stream. It typically receives a stream of 4bit nibbles over the MII or RGMII interface from the PHY layer.

 

The only Ethernet standard which actually encodes bits individually is 10Mbit Ethernet. And the 10Mbit Ethernet standard requires the PHY layer to align the incoming preamble bits to a 4 bit boundary before it is sent via MII/RGMII to the Reconciliation Sublayer.

 

100Mbit Ethernet encodes bits in groups of 4. So it can never have a alignment problem lower than 4 bits.

 

Gigabit Ethernet and higher encodes bits in groups of 8, so they never have any alignment problems.

 

 

In practice, this is what I would propose:

* Wireshark dissector made capable of accepting any whole-byte preamble length mPackets.

* mPacket capture devices are made responsible for detecting any frames with non-integer preamble, and correct for it by adding 4 bits extra preamble at the beginning. That way the dissector never has to realign a whole frame on bit level.

* A capture device which has added 4 bits of preamble, shall indicate this by setting the “unaligned frame error” bit in epb_flags, to let the dissector know that it should ignore the least significant nibble of the first preamble byte.

 

 

While a mPacket with 4 bits of missing preamble is not actually an error, I can think of no other meaningful use for the “unaligned frame error” bit in epb_flags for mPackets. So it should be ok to make use of it for this purpose? Maybe?

Unless the “unaligned frame error” is actually intended to indicate “dribble error”? (An extra 4 bit nibble at the end of a frame) But dribble error is not a alignment problem, so I doubt that is the intention.

 

 

All-in-all this would allow for true display of mPackets as seen on the wire, and avoid the need for bitshifting in the dissector.

 

 

While it is possible for 10Mbit Ethernet to have preamble unalignment down to the 2-bit level, and my proposal of using just one bit in epb_flags can only indicate 4 bit unalignment. But in practice, 2-bit unalignment is not even sent up to the Reconciliation layer. So it is difficult to capture regardless. 1 bit unalignment can not really occur, due to the preamble bit pattern.

 

Allowing for 2-bit unalignment indication would require defining two new bits in EPB. Not sure how difficult that would be?

But I doubt it is worth it in practice.

 

Regards,

Timmy Brolin

 

 

-----Original Message-----

From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf Of Guy Harris

Sent: den 16 februari 2021 11:46

To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>

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

 

At various points in February 2021, Timmy Brolin <tib@xxxxxx> wrote:

 

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

 

I.e. according to the spec that says, on page 39:

 

                             * 99.3.2 Preamble

 

                             The preamble in the mPacket shown in part (a) of Figure 99–4 contains seven octets. The preamble in the mPacket shown in part (b) of Figure 99–4 contains six octets. Each octet contains the value of 0x55 (transmitted in order from left to right 10101010).

 

and thus that the preamble field is either 7 octets of 0x55 or 6 octets of 0x55?

 

> 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.

 

 

Section 12.9.2 "DTE timing" of IEEE Std 802.3-2018 says:

 

                             DTEs shall correctly receive frames that are preceded by 13 or more bits of preamble plus 8 bits of <sfd>.

 

which I assume means that, on the *receiving* end, if you miss up to 43 bits of the 56-bit preamble - or up to 35 bits of the 48-bit preamble in some mPackets - once you're synced up, and see the SFD, you should continue the reception process and hand what you have up to the MAC sublayer.

 

Most capture devices supply the data handled to the MAC layer in the MA_DATA.indication primitive to the host, possibly dropping the frame_check_sequence, and that's what the Wireshark Ethernet dissector expects as input.  I.e., the packet capture hardware and software is a MAC client.

 

On the *transmission* side, you're supposed to transmit 7 octet of preamble; I haven't seen anything about reducing the size of the *transmitted* preamble being acceptable behavior.

 

Once frame preemption is introduced, the packet capture can be at various layers:

 

                             1) at the pMac and eMAC layers, as a MAC client, in which case they would supply the data handled to the MAC layer in the MA_DATA.indication primitive, *possibly* including an indication of the MAC on which the packet was indicated (pMAC or eMAC) - that would be post-reassembly of preempt able packets;

 

                             2) at the MAC Merge sublayer, in which case they get bit streams for preemptable and express packets, including the preamble and SFD (see the calls to pRX_DATA(PREAMBLE) and pRX_DATA(SFD) in figure 99-6 and eRX_DATA(PREAMBLE) and eRX_DATA(SFD) in figure 99-7) - that would be after the MAC Merge processing;

 

                             3) at the Reconciliation Sublayer, in which case they get bit streams for packets, again including the preamble and SFD.

 

To get mPackets, the tap would, I think, have to be at 3).

 

That means that, if the *received* preamble can be as little as 13 bits, the mPacket could have as few as 13 bits of preamble, meaning that neatly aligning the packet for dissection could involve a lot of bit shifting.

 

Is that what you're proposing?

___________________________________________________________________________

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