Hi, if I have a virtual miniport that generates ethernet frames,
should it be the one in charge of also attaching the Ethernet preamble
and Frame Check Sequence beyond the Destn./Src. MAC addresses and the
Type/Length field already populated by NDIS? I am a bit confused about
this aspect since the NetVMini sample in WDK doesn’t appear to be
performing this pre-amble and CRC addition to the frames before
handing out the frames to the other virtual adapters. Without this,
the frames aren’t “true” Ethernet2 frames, correct?
I am also a bit confused by the fact that when I attach Wireshark to
my proper NIC interface in a machine, the incoming Ethernet frames
sometimes do show the CRC fields while at other times, they don’t. I
would have expected the CRC and pre-amble to be stripped off by hw
before Wireshark can get to the pkt - why does it show up on certain
occasions (it seems always for ICMP).
Preamble & FCS are meaningful only on ‘the wire’ and are the responsibility
of the hardware typically.
NDIS could not care less about them.
NetVMini does not needlessly bother itself with emulating Ethernet MAC level
[wire] peculiarities. Why bother? Preamble is to ensure clock recovery.
FCS is to ensure that the bits received were (to some degree of certainty)
the bits that were sent. Neither of these issue exist when passing data
round in system memory.
As for Wireshark, I have no idea where you [or it] thinks it is getting an
Ethernet FCS from.
Every symbol the transmitter transmitted contains enough information for
the receiver’s clock recovery circuitry to recover the clock. Indeed, the
MAC can see preamble, SOF, data, FCS before clock recovery. Preamble tells
the frame cracker of the MAC to get ready for an arriving frame. It serves
as delimiter for frames.
I agree that OP should not concern about it unless he is debugging at L1
and hardware level.
Calvin
On Fri, Nov 30, 2012 at 12:42 PM, David R. Cattley wrote:
> Preamble is to ensure clock recovery. > FCS is to ensure that the bits received were (to some degree of certainty) > the bits that were sent. Neither of these issue exist when passing data > round in system memory. > > As for Wireshark, I have no idea where you [or it] thinks it is getting an > Ethernet FCS from. > > Good Luck, > Dave Cattley > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >