Wireshark-bugs: [Wireshark-bugs] [Bug 6045] Dissector for the Apple USB Multiplexing (USBMUX) pr

Date: Fri, 1 Jul 2011 07:55:10 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6045

Tyson Key <tyson.key@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tyson.key@xxxxxxxxx

--- Comment #8 from Tyson Key <tyson.key@xxxxxxxxx> 2011-07-01 07:55:03 PDT ---
Hi Chris,

Thanks for looking at this code. Whilst developing it, I only had access to the
tools and headers supplied with "libimobiledevice" and various other
iProduct-related tools and libraries for Linux, and an older document (that I
think was from the "iPhone Dev Team" - but I could be wrong) that can only be
found deep within Archive.org now.

At a fairly early stage of development, I noticed that those tools and my
handset were seemingly only generating TCP packets (of type 6 - which also
nicely coincides with the official protocol number from IANA), so I intuitively
decided to add "6 - TCP Packet" to the list of message types.

I also did a brute-force search in my trace files for other packet types by
changing the "6" in the heuristics to other message type IDs, but came up with
nothing.

Although I'm open to adding support for the other message types (and considered
doing so), I decided against it until I could generate traces containing them
to test my dissector against.

All of the packets that I've seen so far are also padded with 0x00 (which made
sense to me at the time, given that structure's definition is getting "packed"
by the toolchain), and since I couldn't find a definition of its meaning, I
decided to skip it and move onto the "message type" byte.

I should probably ask myself "What would iTunes/Apple's official tools do?"
though, and get around to firing up a Windows VM in order to create some more
traces - since although the tools that I have "work" (i.e. they'll let users
manipulate their devices), they're obviously not fully exercising the protocol.

As for heuristics, I'm currently testing against the first few bytes (including
the padding), since I couldn't find any other obvious magic number. I'm also in
agreement with regards to potential conflicts, too - in fact, I already disable
the Ethernet dissector when working with USB traffic, unless I know that I'll
need it.

I'll certainly take your suggestions into account for the next revision of the
patch, though.

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