Wireshark-bugs: [Wireshark-bugs] [Bug 1921] New: Additional preferences for sFlow
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Thu, 18 Oct 2007 15:02:43 +0000 (GMT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1921

           Summary: Additional preferences for sFlow
           Product: Wireshark
           Version: SVN
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: acferen@xxxxxxxxx


Build Information:
wireshark 0.99.7 (SVN Rev 23225)

Copyright 1998-2007 Gerald Combs <gerald@xxxxxxxxxxxxx> 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.11, with GLib 2.12.11, with libpcap 0.9.8, with libz
1.2.3, with libpcre 6.7, without SMI, with ADNS, without Lua, with GnuTLS
1.4.4,
with Gcrypt 1.2.3, without Kerberos, with PortAudio <= V18, without AirPcap.

Running on Linux 2.6.20-16-generic, with libpcap version 0.9.8.

Built using gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4).

--
sFlow datagrams can contain sampled headers from conversations on the network.

Often it is convenient to have wireshark dissect these payload headers, but
doing so can also have undesirable side effects.  Dissected payload headers may
match filters looking for header fields that also happen to occur in the
payload.  This can cause surprising results.

Example
A filter like "ip.src == 10.1.1.1" this will find every sFlow packet where
*any* of the payload headers contain 10.1.1.1 as a src addr.  I think this may
not be the desired behavior.  It can certainly be confusing since the ip.src
being found is buried about 3 subtrees deep and the  subtrees might be under
any one of the sampled (payload) header trees.

Also TCP analysis will almost always flag errors on sampled headers.  They are,
after all, just a sample and many sequence numbers are sure to be missing.

There is probably a more general way to resolve these issues, but adding
preferences to enable/disable tcp analysis and dissection of sampled headers
will be a good start.  This will make it possible to examine the details of
sampled headers if desired or to disable dissection if the side effects of
dissecting sampled headers cause issues.


-- 
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.