ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 5892] Wireshark capture cannot be stopped under heavy traf

Date: Thu, 5 May 2011 20:22:52 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5892

--- Comment #3 from liaodh10@xxxxxxxxx 2011-05-05 20:22:51 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > Can you try a newer version of Wireshark, specifically 1.4.6.  Numerous
> > improvements have been made since 1.2.x series.  I also see that your GTK+
> > version is quite old (2.8.6).  We still support that version, but there may be
> > improvements in newer versions that will help (Wireshark will only use
> > improvements in a newer GTK+ version when recompiled).
> Thanks for the quick response and hints. I did some troublshooting in the code
> and found that the problem is due to the 'dumpcap' sending packets much faster
> than its parent (wireshark) can process. When the user clicks "stop", it has
> successfully terminated the child process dumpcap, but there are still a lot of
> packets buffered in the pipe and wireshark continue to read from pipe. 
> I added a logic in capture.c 'capture_input_new_packets()' so that it'll start
> to discard the packets when user pressed 'Stop' ( when capture_stop() is called
> I added a flag to tell the user has clicked stop). That works fine, however it
> then hang for a long time in 'capture_input_closed()' when reading what remains
> of the capture file (when calling cf_finish_tail()). So the capture still
> cannot be stopped since capture_opts->state has not been changed to
> "CAPTURE_STOPPED". 
> This does't look like a GUI problem so I don't think changing the GTK library
> will help... also we couldn't upgrade the wireshark yet due to its dependency
> on all the libraries that are built in our own package. I did look at the
> source code of V1.5.1 and didn't see enhancement for handling in
> sync_pipe_stop(), etc, functions, which handles the stop of the capture.
> I wonder if you can give any suggestion based on the information described
> above, or you can generate high volumn of traffic and you should be able to see
> that happen. 
> Thanks,

I've been able to improve the cf_finish_tail() speed by skipping the read for
remaining data after user clicks 'stop', using the flag set in stop_capture().
Now the stop button looks to work fine under heavy traffic load. Can someone
help to review the code for me? Thanks.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.