Sorry, I forgot answering this:
> 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.
The real world does unfortunately not align perfectly with the IEEE
> 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 .
> 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
On Feb 16, 2021, at 2:41 AM, Shai Shapira via Wireshark-dev
wrote:
> I'm researching Microsoft's Network Monitor captures format (.cap files)
Unfortunately, you probably can't download NetMon from Microsoft any more, so
you probably can't get the help file that documents the capture file
At various points in February 2021, Timmy Brolin 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
Hi all,
I'm researching Microsoft's Network Monitor captures format (.cap files) and I
need a lead in WS's code.
Based on the 'link layer type' parsed from the file header the packets might be
802.11 frames with NM's special header.
This dissector is known as "netmon_802_11" in wireshark.
Hi,
Would anyone mind if I submit a merge request which makes Wireshark capable of
dissecting all valid Ethernet mPackets according to IEEE 802.3br?
It is a reasonably small change. But I don’t want to put in the effort if the
merge request would be blocked.
Jaap:
Note that Figure 99-4 has
