Further information about the problem. I ran my test program in the background on my PC for several hours while I was doing other work. Apparantly, although the frequency of occurance is much higher when PacketSendPacket is being used by the same application that is reading the packets, it can also occur when packets are simply being read off the interface, and no sending activity is going on by the application with the interface open. My test program encountered several bpf_hdr structures with caplen+1 == datalen today. I then was able to reproduce it by downloading a large file, and right at the end, could've been a coincidence, but several packets were delivered to my test app with that problem. So I think I can reproduce it somewhat predictably it without sending any packets at all; given enough network traffic coming to my machine, it will happen.
For reference, it should've been obvious, but I didn't actually say it in my previous e-mail, this problem did not happen under WinPcap 2.3. Of course WinPcap 2.3 had its own problems, just not this one! Also, far less often, also only with WinPcap 3.0 alpha, I have seen a completely corrupted bpf_hdr structure with random data. --David -----Original Message----- From: Beattie, David [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 9:49 AM To: [EMAIL PROTECTED] Subject: [WinPcap-users] Bug? caplen can be less by one after PacketSendPacket in 3.0 alpha Hi, I've been testing the new WinPcap 3.0 alpha, and I've discovered the following problem: Occasionally, after sending a packet with PacketSendPacket, when I am receiving packets with PacketReceivePacket, I will get a seemingly corrupted header with bh_caplen = bh_datalen - 1; For example, sending 60 byte packets onto the network, I receive most of them as 60 byte packets but an occasional one as a 59 byte captured with 60 byte original data. This is a big problem for me. I have reproduced the problem using a simple test program, the source code of which I am attaching to this e-mail. Operation of the test program should be reasonably obvious from reading the source code, but basically it asks interactively for a device number to capture on, and then starts capturing packets, comparing bh_caplen to bh_datalen and printing them if they are mismatched, otherwise printing a spinning character, and sending packets in between. You can toggle sending packets on and off by pressing a key. I have not been able to reproduce the problem when receiving packets only. For example, using TG.EXE in another process and receiving those packets with my test program doesn't trigger the bug, no matter what packet size I use. Also, I have no packet filter set, so it shouldn't be a a filter problem. I have poured over the source code for all the various parts of the WinPcap library (mostly packet.dll and driver source) and haven't found any clues, but I'm hoping somebody who knows this from the inside will be able to reproduce it armed with my test program and figure out what is going on... Regards, David Beattie Software Test Engineer Intel Corporation P.S. Please ignore the filename; it is leftover from the previous use of this test program. ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[email protected]/ To unsubscribe use mailto: [EMAIL PROTECTED]?body=unsubscribe ==================================================================
