At various points in February 2021, Timmy Brolin <t...@hms.se> 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@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
