Hi.
We have already found the bug and corrected it in our development version
(it was a bug in the kernel driver).
Unfortunately, we are in a development stage in which we cannot release a
new driver for some days.
We will fix the problem by either releasing a new alpha, or sending a new
driver to the mailing list the next week.
Gianluca Varenni, on behalf of the WinPcap team.
----- Original Message -----
From: "Beattie, David" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 06, 2002 8:44 AM
Subject: RE: [WinPcap-users] Bug? caplen can be less by one after PacketSe
ndPacket in 3.0 alph a
> Seems like I'm talking to myself here, but I do realize there's quite a
time
> zone difference between many of us, and I'm doing some heavy duty research
> into this problem in the hopes that WinPcap 3.0 can be made as stable as
> possible. I have found yet more information about the problems in the
> PacketReceivePacket buffer that I have identified.
>
> I stepped through a modified version of the code I wrote to duplicate the
> problem (that I attached to the original e-mail I wrote on this topic) in
a
> debugger. I discovered two things of note.
>
> First, in the test application that I demonstrated source code for, I'm
only
> inspecting the first bpf_hdr structure returned by PacketReceivePacket.
> Either inspecting the rest of them by hand, or modifying my code to do it
> automatically, I see a much larger instance of the bh_caplen =
bh_datalen-1
> problem. (Not that it is happening more often, but I'm detecting it more
> often in my test app. In my real app of course, I read all packets, so I
> see it quite often.)
>
> Then I discovered that if I allow a large amount of data to queue between
> calls to PacketReceivePacket, really bad things happen. For example,
using
> TG.EXE from the example applications; for example the following command on
> my computer, while the code is stopped in the debugger.
>
> TG -i "\Device\NPF_{74455965-9CAF-45FC-BD4D-3773BFA6791A}" -n 60000 -s 150
>
> Then I allow PacketReceivePacket to run, and invariably, the buffer comes
> back with new data in it, but obviously shifted. Usually it will be
packet
> data right at the beginning (not the bpf_hdr structure, but data that I
> recognize from TG or from my PacketSendPacket call). Sometimes though, I
> have even occasionally seen a bpf_hdr structure overlapping the beginning
of
> the buffer... for example, the most recent time I tried this, I got what
> appeared to be the last 12 bytes of a (20 byte) bpf_hdr structure,
followed
> by packet data. In any case, it is quite likely given the above sequence
of
> operations, that the buffer will not start with a bpf_hdr followed by
packet
> data, as it should. This, of course, crashes any program that relies on
the
> buffer to be formatted properly.
>
> This may explain why WinDump 3.8 crashes periodically on my machine when I
> try to run it. It usually works for a while, but then I get a fatal
> exception. I suspect the libpcap library is seeing the same
> PacketReceivePacket buffer inconsistency from time to time that I am
seeing
> using the Packet.DLL API myself.
>
> Hope some of this information helps! I wonder whether these two bugs are
> related, or unrelated.
>
> Best regards,
> David
>
>
> -----Original Message-----
> From: Beattie, David [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 05, 2002 5:42 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [WinPcap-users] Bug? caplen can be less by one after
> PacketSe ndPacket in 3.0 alph a
>
>
> 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
> ==================================================================
>
>
> ==================================================================
> 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
> ==================================================================
==================================================================
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
==================================================================
