From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20080213 Red Hat/1.5.0.12-11.el5_1 Firefox/1.5.0.12 Description of problem: when using a remote wireshark connected via ssh usiong ipv6 and X tunneling, capture fails Version-Release number of selected component (if applicable): wireshark-gnome-0.99.7-1.el5 How reproducible: Always Steps to Reproduce: 1. ssh -X ipv6_addr%eth0 2. wireshark 3. start capture Actual Results: Denaila of capture on any interface (inluding lo) see attached image. Expected Results: capture starts Additional info:
Created attachment 298779 [details] error message when attempting to start capture described as per BZ
It should be noted that no display or capture filters were defined by the user at any stage. All other interfaces fail with the same error message except 'any': it fails on not being able to set promiscous mode on any
originally observed with RHel5u1, bumping to RHEL5.2
Wireshark fills in a default capture filter when it's being run "over the wire" in some sense, e.g. from an ssh connection or an X11 connection from another machine. The default capture filter is intended to filter out traffic for that connection, so that, for example, updates to the X11 display for Wireshark, or printed output for packets from TShark, don't *themselves* generate traffic that Wireshark or TShark will display, said display then causing more traffic, *ad infinitum*. That's the capture filter that showed up in the error message. It got a "scoped" IPv6 address (see RFC 4007), and put that into the capture filter; however, as libpcap doesn't support scoped addresses in filters (and the scope ID doesn't show up on the wire, so there's nothing for it *to* support). Wireshark should remove any scope IDs from addresses it puts into the default capture filter. Please file an upstream bug at http://bugs.wireshark.org (it's Bugzilla, so you'll need to create an account) about this, and put my comments into the bug.
patch sent upstream: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4945
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Looks like the issue cannot be reproduced with tshark, so manual verifictaion only.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0125.html