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

[Timmy Brolin <tib@xxxxxx>]

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