> 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-boun...@wireshark.org> On Behalf Of Guy
Harris
Sent: den 16 februari 2021 11:46
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Subject: Re: [Wireshark-dev] pcapng decoding error when preamble is shortened
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
___________________________________________________________________________
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
