Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

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

Date: Thu, 28 Jan 2010 18:20:08 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4386

Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeff.morriss.ws@xxxxxxxxx

--- Comment #1 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2010-01-28 18:20:03 PST ---
(In reply to comment #0)
> 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

IPNET support was added via bug 4284.  There's a capture file attached there
which works fine.

>From the above dissection output, it appears this is not a valid IPNET file. 
In particular the 2nd octet (Address family) should be either 2 or 26.  In your
capture file they are either 4 or 6, neither of which are valid in IPNET.

Looking at this capture file in hex, I can see plenty of "01 02" sequences
which could be the start of a valid IPNET frame (assuming this is IPv4) but
what follows that doesn't look valid (in particular what would be the data
length is way too big).  (There aren't any "01 1a" sequences which would mark
the start of an IPv6 IPNET packet.)

How did you generate this capture file?  Can Solaris' snoop read it?  If so,
can you provide a detailed-decode output for comparison?

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