[Winpcap-users] ANNOUNCE: WinPcap 4.0 beta2 has been released

[Gianluca Varenni]

Embedded [GV]...

Have a nice day
GV

----- Original Message ----- 
From: "Alto Speckhardt" <1603 at gmx.de>
To: "Gianluca Varenni" <winpcap-users at winpcap.org>
Sent: Sunday, October 29, 2006 2:03 AM
Subject: Re[2]: [Winpcap-users] ANNOUNCE: WinPcap 4.0 beta2 has been 
released


Guten Morgen,

Sorry, it took me a while to get around to continue testing.


GV> By crashes you mean blue screen or application crashes?
GV> By freeze you mean the complete OS freezing (i.e. you need to reboot).
GV> Right?

Actually, I meant the same by both expressions: Windows ceasing to
respond, no more mouse movement, no reaction to keyboard toggles (caps
etc.) So yes, your definition for "freeze" is correct, while my use of
"crash" should have been omitted. ;-)


BTW: The "last exit", Ctrl-Scrol-Scroll to terminate Windows the hard
way still works, but that is the only thing.



[GV] Indeed, this is extremely useful. If you are able to crash the system 
with the "keyboard backdoor", you can generate a crash dump that I can 
analyze.
Can you please enable the kernel dump, cause a freeze/crash, and then upload 
the ZIPped crash dump into ftp://www.winpcap.org/pub/incoming (drop folder, 
write access only)?



GV> Is Windump crashing/freezing in the same way?

No, to my surprise it didn't. I started it maybe five times in a row
and it worked each time, wheras Wireshark, started right afterward,
caused a system freeze after the third "start capture" (the two first
start/stop captures worked all right, packets were shown.)

Is it normal that Windump just sits there at first, displaying

<timestamp> IP

for a few seconds before it continues like

<timestamp> IP <from> <to>
<timestamp> IP <from> <to>
<timestamp> IP <from> <to>
[...]


[GV] This is normal. The reason is that by default windump tries to resolve 
IPs into names contacting the DNS, hence the delay you are experiencing. In 
order to be sure that this is the cause, try "windump -n", this option 
disables address resolution.



and that it lags a little behind the actual traffic?



[GV] Uhm... what do you mean? There's usually a delay of up to 1sec between 
when the packet is captured, and when actually shows it. This is done for 
performance reasons (basically, packets are moved from the driver to the 
user level application in batches, and the timeout for this transfer is by 
default 1 second).