[Guy Harris <guy@xxxxxxxxxxxx>]

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.