imho, if the CRC for the frame is wrong, the frame is discarded and counted
as bad frame (and not stat'ed by winpcap (?), but stat'ed e.g. by netstat)
So, even if you can't get it from winpcap, you can always compute a
posteriori the CRC that the hw received.
Dave Barratt wrote:
Is there any
Now - if Microsoft was to develop winpcap, and sell it ... hmm ...
that would probably make it safer, by definition (Microsoft =
security, as we all know). ;
That said, the security warning is not 100% fake ; if a malicious program
gets running on your machine, the fact that it can snoop
Hi Juim
It looks like the computers are now the bottlenecks, the sender and/or the
receiver CPU/bus is probably too slow transferring data to/from the NICs.
- If you must really go to GBE bandwidth, I suggest using several NICs
feeding a GBE switch (watch out for GBE rate switches) and then using
1) FCS (CRC) has 4 bytes, it is included in the Ethernet protocol, which
means it is actually going over the wire, but the applications won't see it.
Winpcap included. This explains the 4 bytes diff.
2) The 4764 is padding, again, over the wire, the minimum frame size for
Ethernet is 60+4 Bytes,
Hi
Some of the users of my SW, using Winpcap (3.1) , report me that
PacketGetAdapterNames( ) returns FALSE, or returns TRUE, but when looking
at the AdapterNames returned by the API, all there is is an e, even after
fresh installation + machine rebooting
The users however, always have either
Hi
I'm also using the packet API instead of pcap. The reason for Jens might be
(for me it is) performance. The more API layers it has to go through, the
slower the code. This is critical for low usage CPU (background)
applications that must capture live traffic, with repetitive calls to e.g.
Hello
Up to Winpcap 2.3, I've been using Ndiswan as the
adapter to be opened for all users of my tool that require packet measurements
via PPPoE (ADSL users) orEthernet (Cable users). I am using Packet.lib directly, and not wpcap.lib, and Windows
XP.
Unfortunately, some of my users keep
Hi
I have this behaviour that does not quite fall in the FAQ Q-11.
With Ethereal or with my software using mode
NDIS_PACKET_TYPE_ALL_LOCAL/NDIS_PACKET_TYPE_PROMISCUOUS, some frames sent
from my machine are captured by the machine with only 54 Bytes. The frames
(e.g. fromEmule) have 60 Bytes:
