Hi, > > Hi Cary, > > <<WinPCap returns 47 bytes compared to EtherPeeks 64 bytes>> > > I ran into this when I was first learning about WinPCap. > Turns out that for packets transmitted from the machine on > which you're running WinPCap, the padding bytes needed to > bring packets up to the minimum Ethernet frame of sixty bytes > (less the hardware-generated 4-byte CRC) are not logged. So, > for example, if you run WinPCap and try doing a ping from the > machine on which you're running WinPCap, the captured ARP > request packets will show up in Ethereal as being 42 bytes > long. Go to another machine on the same network and try a > ping, and the captured ARP request packets will show up as > being 60 bytes long. > > Although I'm not intimately acquainted with the innards of > WinPCap, I've been told this effect is caused by the layer at > which the NDIS miniport driver intercepts the Ethernet packet > sending calls.
That's correct. From this point of view, winpcap just "relies" what NDIS passes to its driver (which is a protocol driver). Turns out that, when transmitting a packet, the padding is added at the underlying layers, and so it's not received by WinPcap. The same for the CRC: NICs (or NIC drivers) normally check and remove it before giving the packet to the protocols. Loris > Rob--- > > > > > ================================================================== > This is the WinPcap users list. It is archived at > http://www.mail-archive.com/[email protected]/ > > To unsubscribe use > mailto: [EMAIL PROTECTED] > ================================================================== > ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[email protected]/ To unsubscribe use mailto: [EMAIL PROTECTED] ==================================================================
