Hello David.
I would to answer to this e-mail with three points.
1.
The problem you're mentioning is true. We already got it; it should
disappear in the next version.
2.
Me, as a programmer, and all the WinPcap team, does not like very much mails
coming from Intel Corporation.
We have the *STRONG* feeling that Intel is not respecting our copyright
terms and it is using WinPcap in some commercial products. I can give you
the name of the product, if you want.
I would like to see Intel becoming a *generous sponsor* of our project, not
only using our tools for free, asking assistance for free, and so on.
Obviously, this is not something that I have to tell you; you, as an
engineer, by sure agree with me. This is something I should have to discuss
with your boss.
Anyway, we're feeling a bit upset about this behaviour.
3.
In any case, any effort done to improve WinPcap and putting the result in
the public domain is greatly appreciated.
Cheers,
fulvio
> -----Original Message-----
> From: Beattie, David [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 06, 2002 08:45
> To: '[EMAIL PROTECTED]'
> Subject: RE: [WinPcap-users] Bug? caplen can be less by one after
> PacketSendPacket 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
==================================================================
