ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 4386] New: Wireshark Does Not Dissect Loopback Frames In A

Date: Mon, 11 Jan 2010 15:41:34 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4386

           Summary: Wireshark Does Not Dissect Loopback Frames In Attached
                    OpenSolaris 2009.06-Originated Snoop File
           Product: Wireshark
           Version: SVN
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: Minor
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: tyson.key@xxxxxxxxx


Created an attachment (id=4129)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=4129)
Loopback interface frames collected from Snoop under OpenSolaris 2009.06

Build Information:
TShark 1.3.3-SVN-31499

Copyright 1998-2010 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 GLib 2.20.5, with libpcap 1.1-PRE-CVS, with libz 1.2.3, with
POSIX
capabilities (Linux), with libpcre 7.8, with SMI 0.4.8, with c-ares 1.6.0, with
Lua 5.1, without Python, with GnuTLS 2.6.6, with Gcrypt 1.4.4, without
Kerberos,
with GeoIP.

Running on Linux 2.6.30.10-105.fc11.i686.PAE, with libpcap version 1.1-PRE-CVS,
GnuTLS 2.6.6, Gcrypt 1.4.4.

Built using gcc 4.4.1 20090725 (Red Hat 4.4.1-2).

--
Back in Wireshark 1.2.2, the attached file was not recognised at all as a valid
Sun Snoop file. At least with the latest SVN version that I have tested
(1.3.3-SVN-31499), the file is correctly recognised as a Sun Snoop file;
although many the frames within are considered malformed, and are not dissected
correctly. 

I'm not too certain about what the end result should look like as far as
headers are concerned, although I know that it at least contains SMB, mDNS, and
RLogin packets. Unusually, it seems that pieces of text from various packets
are being used as the source of garbage data length values within the IPNet
headers.

For example:
No.     Time        Source                Destination           Protocol Info
    129 720.849034                                              IPNET   
Solaris IPNET[Malformed Packet]

Frame 129: 65 bytes on wire (520 bits), 65 bytes captured (520 bits)
    Arrival Time: Jan  9, 2010 14:40:23.971632000 GMT
    Epoch Time: 1263048023.971632000 seconds
    [Time delta from previous captured frame: 1.400719000 seconds]
    [Time delta from previous displayed frame: 1.400719000 seconds]
    [Time since reference or first frame: 720.849034000 seconds]
    Frame Number: 129
    Frame Length: 65 bytes (520 bits)
    Capture Length: 65 bytes (520 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: ipnet]
Solaris IPNET
    Header version: 1
    Address family: Unknown (4)
    Hook type: Unknown (24)
    Data length: 1081045093
    Interface index: 0
    Group interface index: 0
    Source Zone ID: 0
    Destination Zone ID: 0
[Malformed Packet: IPNET]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Message: Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

0000  01 04 00 18 40 6f 70 65 00 00 00 00 00 00 00 00   ....@ope........
0010  00 00 00 00 00 00 00 00 45 00 00 29 77 f4 40 00   ........E..)w.@.
0020  40 06 00 00 7f 00 00 01 7f 00 00 01 03 f7 02 01   @...............
0030  19 ce 5a c0 19 d0 f2 35 50 18 c0 00 00 15 00 00   ..Z....5P.......
0040  75                                                u

No.     Time        Source                Destination           Protocol Info
    252 803.108589                                              IPNET   
Solaris IPNET[Malformed Packet]

Frame 252: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
    Arrival Time: Jan  9, 2010 14:41:46.231187000 GMT
    Epoch Time: 1263048106.231187000 seconds
    [Time delta from previous captured frame: 0.070212000 seconds]
    [Time delta from previous displayed frame: 0.070212000 seconds]
    [Time since reference or first frame: 803.108589000 seconds]
    Frame Number: 252
    Frame Length: 64 bytes (512 bits)
    Capture Length: 64 bytes (512 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: ipnet]
Solaris IPNET
    Header version: 1
    Address family: Unknown (4)
    Hook type: Unknown (24)
    Data length: 2003792484
    Interface index: 0
    Group interface index: 0
    Source Zone ID: 0
    Destination Zone ID: 0
[Malformed Packet: IPNET]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Message: Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

0000  01 04 00 18 77 6f 72 64 00 00 00 00 00 00 00 00   ....word........
0010  00 00 00 00 00 00 00 00 45 00 00 28 78 6f 40 00   ........E..(xo@.
0020  40 06 00 00 7f 00 00 01 7f 00 00 01 e2 19 00 17   @...............
0030  1b 08 c6 da 1b 09 d3 92 50 10 c0 00 00 14 00 00   ........P.......

However, it seems that another Snoop Loopback capture file that I found
elsewhere is parsed correctly. I can provide that file, if necessary.

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