window "capture->Interfaces" cannot be closed
Build Information: wireshark 0.99.7 (SVNRev 22493) Copyright 1998-2007 Gerald Combs <gerald@wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled with GTK+ 2.10.13, with GLib 2.12.12, with libpcap 0.9.5, with libz 1.2.3, with libpcre 6.6, with Net-SNMP 5.2.1.2, without ADNS, without Lua, with GnuTLS 1.4.4, with Gcrypt 1.2.2, without Kerberos, without PortAudio, without AirPcap. Running on Linux 2.6.22-gentoo-r2, with libpcap version 0.9.5. Built using gcc 4.1.2 (Gentoo 4.1.2). -- (1) start wireshark (2) open Capture->Interface (3) start capturing (4) click at the "Close" button of the interface window now this window hangs
According to gdb, when performing the actions described in the bug, Wireshark hangs at the wait() call (actually followed by a wait4() call on my OS X machine) at line 700 of file capture_sync.c: if (wait(&fork_child_status) != -1) { This seems to be waiting for the second copy of dumpcap to end (the one doing the capturing) instead of the first one started (that lists all of the interfaces). My suspicion of this being the case is backed up by a test where you can use the Unix kill command to terminate the first (interface listing) copy of dumpcap and the interfaces window will go away (although the capturing dumpcap seems to die next). This functionality/code was introduced by Gerald in SVNrev 22071 as part of privilege separation efforts.
Hi, Sergio Barjola did some more debugging on this issue, and found the following, looking at the process: gksudo---wireshark---dumpcap I've found that gksudo is ignoring SIGPIPE signal, (ps -eo pid,ignored), so all childs process too, unless they change with sigaction. Enable default action of SIGPIPE before gksudo create the child process works for me. (libgksu.c line 2506). I've looking for why is SIGPIPE ignored in gksu process, and I found that it's caused by communication with gconfd server. When a application connect to the gconfd daemon to get properties, the underlaying communication with CORBA it's ignoring SIGPIPE signal to avoid that if server crash, the process receive the signal and terminate. package: liborbit2 1:2.14.12-0.1 file: linc2/src/linc.c (line: 247 see comment why is signal ignored).. He came up with a patch to make wireshark work again, by enabling the default action for SIGPIPE. I attach the patch here for your review. Thanks, James
Created attachment 2335 [details] patch to enable default SIGPIPE action
(In reply to comment #3) > Created an attachment (id=2335) [details] > patch to enable default SIGPIPE action > Committedrevision 26621. Thanks for the patch!
*** Bug 2736 has been marked as a duplicate of this bug. ***
Created attachment 2523 [details] set sa_flags variable The patch is not setting sa_flags field of the sigaction structure. We could set it to 0, but I think SA_RESTART is more suitable. What do you think ? Attaching patch (the affected code has moved from capture_opts.c to dumpcap.c meanwhile).
Committedrevision 26851. Thanks! (In reply to comment #6)
Hhm, probably I've to do a complete rebuild but the issue isn't solved with that svn commit ....
I'd like to reopen this bug b/c the issue isn't solved with this version: ^Ctfoerste@n22 ~/devel/wireshark $ ./wireshark -v wireshark 1.1.2 (SVNRev 26875) Copyright 1998-2008 Gerald Combs <gerald@wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled with GTK+ 2.12.11, with GLib 2.16.5, with libpcap 0.9.8, with libz 1.2.3, without POSIX capabilities, with libpcre 7.8, without SMI, without c-ares, without ADNS, without Lua, with GnuTLS 2.4.1, with Gcrypt 1.4.0, without Kerberos, without GeoIP, without PortAudio, without AirPcap. Running on Linux 2.6.26-gentoo-r3, with libpcap version 0.9.8. Built using gcc 4.1.2 (Gentoo 4.1.2 p1.0.2).
Could you check bug 2736? I think it both bugs are caused by the same problem. Could you check your dumpcap version, too? (In reply to comment #9)
Right, if I kill the dumpcap process (I see 2 withi the process list) I can continue to work with wireshark. Furthermore I use "su " to start wireshark: tfoerste@n22 ~ $ su -c /home/tfoerste/devel/wireshark/wireshark Password:
BTW, here are the 2 processes, I killed the 2nd : tfoerste@n22 ~ $ ps -efla | grep dumpcap 4 S root 9300 9242 0 80 0 - 3191 - 14:50 pts/1 00:00:00 /home/tfoerste/devel/wireshark/.libs/lt-dumpcap -S -M 4 S root 9316 9242 0 80 0 - 3191 - 14:50 pts/1 00:00:00 /home/tfoerste/devel/wireshark/.libs/lt-dumpcap -i eth0 -p -Z none 0 S tfoerste 9344 9332 0 80 0 - 936 - 14:50 pts/2 00:00:00 grep --colour=auto dumpcap
Strange, i see one dumpcap process on my machine at a given time: 4 S root 8131 7564 0 80 0 - 3160 - 12:33 pts/3 00:00:00 /home/rbalint/Projects/wireshark/.libs/lt-dumpcap -i eth0 -Z none or: 4 S root 12223 7564 0 80 0 - 3160 - 13:04 pts/3 00:00:00 /home/rbalint/Projects/wireshark/.libs/lt-dumpcap -S -M Could you check the signal mask of your dumpcap processes? (ps -eo pid,ignored) (In reply to comment #12)
tfoerste@n22 ~ $ ps -efla | grep dumpcap | fgrep -v grep 4 S root 9028 8738 0 80 0 - 3191 - 15:22 pts/1 00:00:00 /home/tfoerste/devel/wireshark/.libs/lt-dumpcap -S -M 4 S root 9095 8738 0 80 0 - 3192 - 15:22 pts/1 00:00:00 /home/tfoerste/devel/wireshark/.libs/lt-dumpcap -i eth0 -p -Z none tfoerste@n22 ~ $ ps -eo pid,ignored | grep -e 8738 8738 0000000000000000
The signal mask is ok. I think your problem is caused by compiling wireshark without POSIX capabilities. Could you install libcap-dev and recompile wireshark? (In reply to comment #14) > tfoerste@n22 ~ $ ps -efla | grep dumpcap | fgrep -v grep > 4 S root 9028 8738 0 80 0 - 3191 - 15:22 pts/1 00:00:00 > /home/tfoerste/devel/wireshark/.libs/lt-dumpcap -S -M > 4 S root 9095 8738 0 80 0 - 3192 - 15:22 pts/1 00:00:00 > /home/tfoerste/devel/wireshark/.libs/lt-dumpcap -i eth0 -p -Z none > tfoerste@n22 ~ $ ps -eo pid,ignored | grep -e 8738 > 8738 0000000000000000 >
I emerged the Gentoo package sys-libs/libcap-2.11 and run $> ./configure CC="ccache gcc" again, during that step I read this : ... checking for mprotect... yes checking for sysconf... yes ./configure: line 32931: : command not found configure: creating ./config.status config.status: creating Makefile config.status: creating doxygen.cfg ... but it finished with : ... The Wireshark package has been configured with the following options. Build wireshark : yes Build tshark : yes Build capinfos : yes Build editcap : yes Build dumpcap : yes Build mergecap : yes Build text2pcap : yes Build idl2wrs : yes Build randpkt : yes Build dftest : yes Build rawshark : yes Install dumpcap setuid : no Use plugins : yes Build lua plugin : no Build rtp_player : no Use threads : no Build profile binaries : no Use pcap library : yes Use zlib library : yes Use pcre library : yes Use kerberos library : no Use c-ares library : no Use GNU ADNS library : no Use SMI MIB library : no Use GNU crypto library : yes Use SSL crypto library : no Use IPv6 name resolution : yes Use gnutls library : yes Use POSIX capabilities library : yes Use GeoIP library : no ... but hte issue still remains. BTW "Capture"->"Interfaces" gives : tfoerste@n22 ~ $ ps -efla | grep dumpcap | fgrep -v grep 4 S root 16978 16439 0 80 0 - 3204 - 18:19 pts/3 00:00:00 /home/tfoerste/devel/wireshark/.libs/lt-dumpcap -S -M After that I did an "Capture"->"Start", which yields into this state : tfoerste@n22 ~ $ ps -efla | grep dumpcap | fgrep -v grep 4 S root 16978 16439 0 80 0 - 3204 - 18:19 pts/3 00:00:00 /home/tfoerste/devel/wireshark/.libs/lt-dumpcap -S -M 4 S root 17078 16439 0 80 0 - 3205 - 18:19 pts/3 00:00:00 /home/tfoerste/devel/wireshark/.libs/lt-dumpcap -i eth0 -p -Z none closing now the interface windows did not work, but doing this : tfoerste@n22 ~ $ su Password: n22 /home/tfoerste # kill 17078 brought back the application with a window saying : "Child capture process died: Broken pipe".
I fixed the harmless error in configure (Commit 26893). Are you sure that you have recompiled dumpcap, too? (In reply to comment #16)
(In reply to comment #17) > Are you sure that you have recompiled dumpcap, too? Yes, double checked it (made "make clean" before and checked "ls -l dumpcap")
Could you try a make distclean, too? If it does not eliminate the problem could you upload the preprocessed dumpcap.c?
Created attachment 2550 [details] gcc -E for dumpcap.c The output of $>make distclean && ./autogen.sh && ./configure CC="ccache gcc" gives : The Wireshark package has been configured with the following options. Build wireshark : yes Build tshark : yes Build capinfos : yes Build editcap : yes Build dumpcap : yes Build mergecap : yes Build text2pcap : yes Build idl2wrs : yes Build randpkt : yes Build dftest : yes Build rawshark : yes Install dumpcap setuid : no Use plugins : yes Build lua plugin : no Build rtp_player : no Use threads : no Build profile binaries : no Use pcap library : yes Use zlib library : yes Use pcre library : yes Use kerberos library : no Use c-ares library : no Use GNU ADNS library : no Use SMI MIB library : no Use GNU crypto library : yes Use SSL crypto library : no Use IPv6 name resolution : yes Use gnutls library : yes Use POSIX capabilities library : no Use GeoIP library : no And the output of $>tfoerste@n22 ~/devel/wireshark $ gcc -E dumpcap.c -I /usr/include/glib-2.0/ -I wsutil/ -I /usr/lib/glib-2.0/include/ >dumpcap.c_gcc-E dumpcap.c:85:31: error: wsutil/privileges.h: No such file or directory is attached.
I tried to reproduce the problem with a freshly installed Gentoo. First, i installed the latest Gentoo using the live CD iso (Man, it took ages! :-)) in a virtal machine then i preformed the following steps: emerge sync emerge portage # set USE="X gtk gnome -alsa" in /etc/make.conf # followed instructions on http://bugs.gentoo.org/show_bug.cgi?id=234907 emerge -NuDav --fetchonly world emerge -C ss com_err e2fsprogs emerge -NuDav --nodeps e2fsprogs-libs e2fsprogs echo "sys-libs/com_err" >>/etc/portage/package.mask echo "sys-libs/ss" >>/etc/portage/package.mask echo "sys-libs/com_err-1.40.11" >>/etc/portage/profile/package.provided echo "sys-libs/ss-1.40.11" >>/etc/portage/profile/package.provided # full update to avoid problems caused by outdated software emerge -NuDav world emerge wireshark subversion elinks adduser -m virtual gpasswd -a virtual wheel passwd virtual # logged in as virtual (a normal user) su -c wireshark # works sudo wireshark # works svn co http://anonsvn.wireshark.org/wireshark/trunk/ wireshark ./autogen.sh ./configure make make install su -c "bash -c 'LD_LIBRARY_PATH=/usr/local/bin /usr/local/bin/wireshark'" # works sudo bash -c 'LD_LIBRARY_PATH=/usr/local/bin /usr/local/bin/wireshark' # works I suspect that there is some special configuration in your system or the problem is caused by outdated software. Could you perform a deep update, install Gentoo's wireshark and try to reproduce the problem again?
(In reply to comment #21) > (Man, it took ages! :-)) in a virtal machine then i preformed the following steps: Yep, Gentoo is a good compiler stress-test distribution, but since some days there are weekly built LiveCD w/ up-to-date packages available. > I suspect that there is some special configuration in your system Probably yes > or the problem is caused by outdated software. because I regularly make a (full/deep) update of all of my installed packages. > Could you perform a deep update, install Gentoo's wireshark and try to > reproduce the problem again? Made it and I can reproduce the problem with the current gentoo package too - therefore probably a problem at my system ? :-(
(In reply to comment #22) > > Could you perform a deep update, install Gentoo's wireshark and try to > > reproduce the problem again? > Made it and I can reproduce the problem with the current gentoo package too - > therefore probably a problem at my system ? > :-( > I suspect. Could you upload your make.conf to make me able to match your system better in my virtual machine?
Created attachment 2603 [details] config.h (In reply to comment #23) > Could you upload your make.conf to make me able to match your system better in > my virtual machine? Yes, but I do not have that file but probably you mean config.h ?
(In reply to comment #24) > Created an attachment (id=2603) [details] > config.h > > (In reply to comment #23) > > Could you upload your make.conf to make me able to match your system better in > > my virtual machine? > Yes, but I do not have that file but probably you mean config.h ? > I tried the same configure parameters you probably used to produce the attached config.h (--without-krb5 --without-adns --without-libcap) and i still can't reproduce the problem. I meant /etc/make.conf, btw.
Created attachment 2612 [details] make.conf (In reply to comment #25) > I meant /etc/make.conf, btw. Ah ok, attached.
BTW, the point (3) of this : >(1) start wireshark >(2) open Capture->Interface >(3) start capturing >(4) click at the "Close" button of the interface window should be better written as (3) open Capture->Start If I click at the start button within Capture->Interface it works well.
At least there is another user : http://forums.gentoo.org/posting.php?mode=quote&p=5401133&sid=2a61c55c9a96880e7f06877959689387 therefore it seems not to be a specific problem at my machine.
Another Gentoo user here hitting the same bug. I'm using Gentoo's net-analyser/wireshark-1.0.5 ebuild. I haven't tried the patches here yet, but have an additional nugget of information. Gentoo allows ordinary users that are members of the "wireshark" group to run wireshark. The bug only seems to occur when running wireshark as one of these ordinary users. When run as root, there is no problem with the Capture Interfaces dialog (at least for me, but YMMV).
For the record, the forum can be found here: http://forums.gentoo.org/viewtopic-t-722531.html Evildad posted on the referenced topic that net-analyzer/wireshark-1.1.1 worked for him. Could you try net-analyzer/wireshark-1.1.2? (In reply to comment #28) > At least there is another user : > http://forums.gentoo.org/posting.php?mode=quote&p=5401133&sid=2a61c55c9a96880e7f06877959689387 > > therefore it seems not to be a specific problem at my machine. >
(In reply to comment #30) > Could you try net-analyzer/wireshark-1.1.2? > The latest svn version still contains the bug.
Guys, why above patches were not applied to 1.0.x branch. Users still experience this problem: https://bugs.gentoo.org/show_bug.cgi?id=260457 Please, backport them.
I have increased priority as this is the first thing new user will run in. Tested on Solaris while Wireshark 1.0.6 is started via pfexec (net_rawaccess privilege). patch to enable default SIGPIPE action is solving this.
Comment on attachment 2335 [details] patch to enable default SIGPIPE action Checked in several months ago inr26621.
Right now we set a SIGPIPE handler in print_statistics_loop(), which means we only set it when we run "dumpcap -S". Would it make more sense to set the handler no matter what?
Committedrevision 28549. Toralf, could you try that modified fix? (In reply to comment #35) > Right now we set a SIGPIPE handler in print_statistics_loop(), which means we > only set it when we run "dumpcap -S". Would it make more sense to set the > handler no matter what? >
issue seems to be solved :-)
