Bug 438473 - wireshark via ssh -X on ipv6 link-local address fails to allow capture
wireshark via ssh -X on ipv6 link-local address fails to allow capture
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: wireshark (Show other bugs)
x86_64 Linux
medium Severity low
: rc
: ---
Assigned To: Jan Safranek
Miroslav Vadkerti
Depends On:
  Show dependency treegraph
Reported: 2008-03-21 04:37 EDT by Marco Grigull
Modified: 2013-01-08 00:01 EST (History)
4 users (show)

See Also:
Fixed In Version: wireshark-1.0.15-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
When Wireshark starts with X11 protocol being tunnelled through ssh connection, it automatically prepares its capture filter to omit these ssh packets. If the ssh connection is to link-local IPv6 address including interface name (like ssh -X <ipv6addr>%eth0), Wireshark erroneously parsed this address and constructed wrong capture filter and refused to capture packets with 'Invalid capture filter' message. In this update, parsing of link-local IPv6 addresses is fixed and Wireshark prepares correct capture filter to omit ssh over link-local IPv6 connection.
Last Closed: 2013-01-08 00:01:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
error message when attempting to start capture described as per BZ (78.26 KB, image/png)
2008-03-21 04:40 EDT, Marco Grigull
no flags Details

  None (edit)
Description Marco Grigull 2008-03-21 04:37:57 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20080213 Red Hat/ Firefox/

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):

How reproducible:

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:
Comment 1 Marco Grigull 2008-03-21 04:40:12 EDT
Created attachment 298779 [details]
error message when attempting to start capture described as per BZ
Comment 2 Marco Grigull 2008-03-21 04:42:30 EDT
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
Comment 3 Marco Grigull 2008-05-27 04:55:39 EDT
originally observed with RHel5u1, bumping to RHEL5.2
Comment 4 Guy Harris 2009-12-09 20:59:54 EST
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


(it's Bugzilla, so you'll need to create an account) about this, and put my comments into the bug.
Comment 5 Jan Safranek 2010-06-28 09:47:15 EDT
patch sent upstream: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4945
Comment 6 RHEL Product and Program Management 2012-04-02 06:26:26 EDT
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.
Comment 9 Miroslav Vadkerti 2012-07-31 11:01:05 EDT
Looks like the issue cannot be reproduced with tshark, so manual verifictaion only.
Comment 13 errata-xmlrpc 2013-01-08 00:01:32 EST
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.


Note You need to log in before you can comment on or make changes to this bug.