http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1181
richardv@xxxxxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Comment #7 from richardv@xxxxxxxxxxxxx 2006-11-21 10:45 GMT -------
Why have you marked this fixed, Peter? Reopening.
There are other reasons for splitting of dumpcap than not dropping packets.
Merging it back in isn't the right way to go, even if it would fix the problem
(which it wouldn't in itself).
Jim: I'm afraid I haven't the entirety of comment #4; I suspect you're making
this harder than it needs to be.
I think there are two choices as to how to fix this:
1. Use appropriate "configure" magic to allow us to detect a system on which
it's possible to select() on the capture fd and implement a timeout for systems
which don't properly support packet batching.
2. Fix wireshark not to update the GUI on every update from dumpcap; then don't
bother with packet-batching at all in dumpcap.
For what it may be worth, I think the fault was introduced somwhere in the
changes Guy was making on 21 May; see
http://anonsvn.wireshark.org/viewvc/viewvc.py/trunk/capture_loop.c?r1=18192&r2=18201.
This may be worth re-raising on the dev list if you are seriously considering
fixing it. I for one would welcome a fix...
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
