Just some additional pieces of information about my setup, in case somebody was about to ask:
OS: Windows 2000 Ethernet cards: Intel Pro/100 and Pro/1000T, several of each per computer, all used "simultaneously". CPU Speeds: I have a couple. All are single-processor machines. At 400 MHz I think I have all the "bugs" out,... at 850 MHz, I'm not so sure. So, the issues I was seeing may be timing related, and a faster processor seems to exacerbate the malfunctions in my case. (Mostly I mention this because the note in the changelog says "fixed a data structure overlapping that sometimes messed up the read event under WinNTx"... so I'm wondering whether this affected Windows 2k or not.) Regards, David -----Original Message----- From: Beattie, David [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 5:06 PM To: '[EMAIL PROTECTED]' Subject: [WinPcap-users] Packet.DLL 2.3 receive timing bugs... perhaps fixed in 3.0? Hi, I have been using the Packet.DLL API as a support library in some automated test equipment. I simply send and receive raw Ethernet packets, using PacketSendPacket and PacketReceivePacket (plus of course all the other Packet.DLL API calls when appropriate). In my application, being test equipment, receiving packets in a timely manner is very important... the instant a packet is read off the wire, I would like to have it in my application buffers ASAP, because it needs to be responded to in a simulation of TCP/IP, or any other protocols I choose to simulate. I also use timeouts extensively, and if a packet does not come within a certain amount of time, I need to know that too. I just completed a stability bugfix of my application, and my conclusions were the following: 1. PacketReceivePacket, in version 2.3 of the library, will occasionally return early.--well before the timeout has expired. I was having problems with this (my application not waiting long enough to receive a particular packet, and returning an error, causing a false "test failure"), so I implemented my own timers, wrapped around my call to PacketReceivePacket, and I would do a retry, resetting the timeout to whatever time remaining in the testing interval my independant timers showed as remaining. 2. After I solved that problem, I also noticed that there were times when PacketReceivePacket (again in version 2.3) would return late. It would return the packet that I saw on the wire with a sniffer, but, perhaps a whole second after the packet was received, as corroborated by external sniffers, WinDump running in parallel on the same interface, or even the timestamp in the bpf_hdr. I would notice this because I would get TCP retries from the remote system. In fact, the time the first packet was returned corresponded with the arrival of the retry. (So both packets would be returned at that point.) I eventually solved this problem in my application by re-implementing PacketReceivePacket from the DLL, bypassing it, and calling the ReadFile call that I see in the source code for that DLL, without first waiting on the ReadEvent. Examining the source code for driver handling the ReadFile call lead me to believe that this would work, since ReadFile would call the wait internally if there were no packets in the buffer. It would simply be waiting in Kernel mode instead of User mode. Now that I have completed this work, I see that the WinPcap project has, as of today, released an alpha release of 3.0, and that one of the bugfixes was related to the ReadEvent getting corrupted. Can anyone confirm that upgrading to this 3.0 alpha version of the library would eliminate the symptoms I saw? Also, are there things in 3.0 alpha that are known to be problematic, so that now that I have solved my problems by workarounds compatible with version 2.3, I would definitely be better not to upgrade until they are fixed? Or on the other hand, are there other stability bugfixes that others have experienced that would make it highly recommended for me to upgrade in my situation? I will of course continue to monitor the mailing lists for further developments... as this is the first time I've written the mailing list, I just want to convey my special thanks to the developers of WinPcap for their work, as, without it, I would basically have had to develop the NDIS raw packet send-receive functionality myself... which we all know would be NOT FUN! This way I can get by without the Windows DDK! Thanks a lot, David Beattie Software Test Engineer Intel Corporation
