Wireshark-bugs: [Wireshark-bugs] [Bug 5919] New: Netflow: IE 89 Forwarding Status - Incorrect De
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 13 May 2011 07:39:39 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5919

           Summary: Netflow: IE 89 Forwarding Status - Incorrect Decoding
           Product: Wireshark
           Version: 1.5.x (Experimental)
          Platform: x86
        OS/Version: Windows XP
            Status: NEW
          Severity: Minor
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: jamaswise@xxxxxxxxx


Build Information:
Version 1.5.1 (SVN Rev 36537 from /trunk)

Copyright 1998-2011 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 (32-bit) with GTK+ 2.16.6, with GLib 2.24.2, with WinPcap (version
unknown), with libz 1.2.3, without POSIX capabilities, without libpcre, with
SMI
0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.10.3,
with
Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built
Apr
10 2011), with AirPcap.

Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.2
(packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.10.3, Gcrypt 1.4.6, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 21022
--
Issue:
The forwarding status information element (89) is not being dissected
correctly.  The dissector correctly determines that the forwarding status is
either: unknown, forwarded, dropped or consumed. It is second portion of the
field, forwarding status code, that is wrong.  This information element is a 1
byte field, the top two bits are the forwarding status, the bottom 6 bits hold
the code. The issue is that the dissector code is masking the forwarding status
code correctly, but the table it is looking the mapping with was written using
the full field value.

Solutions:
- Change the dissector code to do the forwarding status and code look up in one
operation. Looses the field breakdown but is probably the easiest.
- Change just the forwarding status code look up to use the full field. It will
mess up the displaying of an unknown value.
 - The most complete solution would be to add 4 new forwarding status tables,
one for each status type. The values in those tables should be the 6 bit masked
values that are currently in the forwarding_status_code table. 

Thanks
Jamas

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