Re: pcapng decoding error when preamble is shortened

[Guy Harris <gharris () sonic net>]

On Feb 16, 2021, at 4:03 AM, Timmy Brolin <tib () hms se> wrote:

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

I.e., the packet, as stored in a capture file (pcap, pcapng, whatever), will have somewhere between 1 and 7 octets of 
0x55, followed by an SMD?

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

Why is this necessary?  Is the goal here to indicate the on-the-wire preamble length?  If so, why not just write 0x50 
rather than 0x55 as the first octet if the least significant nibble is a padding nibble?

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

Those flags come from an example given in the documentation of the flags field of the pcapng Enhanced Packet Block"

        https://pcapng.github.io/pcapng/draft-tuexen-opsawg-pcapng.html#name-enhanced-packet-block-flags

which says

        link-layer-dependent errors (Bit 31 = symbol error, Bit 30 = preamble error, Bit 29 = Start Frame Delimiter 
error, Bit 28 = unaligned frame error, Bit 27 = wrong Inter Frame Gap error, Bit 26 = packet too short error, Bit 25 = 
packet too long error, Bit 24 = CRC error, other?? are 16 bit enough?).

Currently, we support that flag in DOS Sniffer files; we do *not* yet interpret the link-layer-dependent errors in 
pcapng files.

And the "unaligned frame error" should perhaps be renamed "misaligned frame error".

See, for example, this page of an Ethernet adapter manual:

        
https://manualsdump.com/en/manuals/asante_technologies-asante_maccon_family_ethernet_network_cards_for_the_macintosh/142796/53

in which it lists various error indications, including Frame Alignment Error, which means the frame didn't not end in 
an 8 bit boundary.

That says nothing about the preamble.  It's talking about "octet-boundary alignment of the end of the frame", to quote 
section 4.1.2.1.2 "Reception without contention":

        ...It also checks for invalid MAC frames by inspecting the frame check sequence to detect any damage to the 
frame enroute, and by checking for proper octet-boundary alignment of the end of the frame. Frames with a valid FCS may 
also be checked for proper octet-boundary alignment.

So there are at least 3 reasons not to use that flag:

        1) that's not what its intended use is;

        2) it's not currently implemented in the pcapng reader;

        3) it's not available in pcap - this isn't a "pcapng decoding error", it's a packet decoding error, and there 
should be as few cases as possible where a packet from a pcapng file (if all the interfaces in the pcapng file have the 
same link-layer type and snapshot length) could not be written to a pcap file and properly decoded by a program reading 
the pcap file.
___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe