Wireshark-dev: 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?
