Re: pcapng decoding error when preamble is shortened

[Timmy Brolin <tib () hms se>]

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

Yes.

Technically IEEE says a mPacket receiver should accept any number of 0x55 octets. So it could in theory be more than 7 
octets.
But in real world it would normally be 1-7 octets. Including half-octets...


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

Yes, indication of the true on-wire preamble is what I am trying to achieve.

I think you are right in that just writing 0x50 as first octet would work.

But the dissector would have to deviate slightly from IEEE. A "0" at the beginning would constitute a SFD error. But in 
practice it should be essentially impossible for the reconciliation sublayer to see anything but "5" at the beginning 
of a frame. Due to the way the Ethernet PHY layers are specified. So making an exception for the first byte might be 
acceptable?


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

> 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

Ok!

Then I certainly cannot use that flag.


Regards,
Timmy Brolin


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