Wireshark-dev: Re: [Wireshark-dev] usb decoding
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 10 Jul 2008 02:41:20 -0700

On Jul 9, 2008, at 3:55 PM, Gordon McNutt wrote:


Hello all,
I'm interested in translating USB capture files from Total Phase Beagle 
USB analyzers into something wireshark will display.
If you know the format of those files, why not just write code for Wireshark, in the Wiretap library, to read those files directly? That means you don't have to convert the files to have Wireshark read them. 


Maybe later I can write a capture plugin so Wireshark
can drive the beagle directly.
Note that capturing is done in libpcap; it currently has no support for plugins loaded at run-time, but it does have the ability to support more capture mechanisms than the OS's native capture mechanism (or, on Windows, the WinPcap driver and packet.dll) with built-in code. 


The linux encapsulation appears to be the one with the best existing
support, as the usb raw displays don't show a heck of a lot other than
the data, and my poking around on the web suggests that dlt 189 was an
early version.
Unlikely - DLT_ values are assigned in numerical order by age, so the DLT with a value of 186, DLT_USB, was assigned earlier than the one with a value of 189, DLT_USB_LINUX.
DLT_USB was assigned 186 in early October 2006; DLT_USB_LINUX was assigned 189 in December 2006, in order to add some fields. 


The linux encapsulation displays are better, but they are definitely
oriented around displaying what is happening in the usb driver stack
(what with the request/response stuff) as opposed to what a bus analyzer 
shows, which is more like the straightforward traffic that wireshark's
ethernet displays show (timestamp:data).


Both were designed for use in Linux to get information from the stack.
Ideally what I want is to show plain old usb traffic just like ethernet, either with literal packet display (eg, an IN packet on one line, then a 
DATA0 packet with a payload on the next, then an ACK or NAK packet on
the next) or maybe with transaction display (With IN/DATA0/ACK all on
the same line).
That sounds as if it might be lower-level than either DLT_USB or DLT_USB_LINUX.
If so, then if you write code for Wireshark to read the Beagle files directly, you won't need a new DLT_ value, but you'll need a new WTAP_ENCAP_ value. 


So, I finally get around to my questions:

1. Is dlt 189 a development dead end?


No.


2. Was dlt 189 also oriented around submit/response, or was it more
suitable to what I'd like to do?


I think it might not be low-level enough for what you want.


3. Should I just reserve a new dlt number and make a new dissector?
You'll probably need to make a new dissector, so you'll need a new WTAP_ENCAP_ value. You'll only need a new DLT_ value if you don't write code to directly read Beagle files.