Re: sniffing from USB bus: current shortcoming

[Guy Harris <guy () alum mit edu>]

Paolo Abeni wrote:

> A new binary interface for USB sniffing is making it's way into the
> current kernel tree and I hope that will be available in the near
> future. This will solve both problem and the relevant ABI has yet been
> fixed, so I can produce the pcap code to use it. The new ABI will
> provide also a memory mapped access to the sniffed data, because the
> sniffing process will require at least an in-kernel copy of whole URB
> data. In order to achieve better performance, should I use this kind of
> access  ?!?

Yes.  You might want to fall back on the older mechanism with kernels 
that don't support the newer one.

> Now comes the issues I produced. The kernel produce and make available
> to libpcap a couple of 'events' for each transmitted/received URB. A
> 'submit' event when the transfer begin. A 'complete' event when the
> transfer is completed with success and an 'error' event when the
> transfer is completed without success. The actual URB data is present in
> only one of this events. Currently all events are passed to the
> application, but is not possible for the application to know which kind
> of event it's processing, because this information is not available in
> the header I build up and pass to the application with the data.
>
> A few others useful information are missing in the build-up USB header: 
> the usb bus the URB come from and a 'direction' flag for the occurred
> transfer.
>
> This data can be added to the current usb header retaining binary
> compatibility with old traces for USB data link type, because there is
> some room available in the current header format.

I.e., you're replacing

        bpf_u_int32 urb_type;

with

        u_char transfer_type;
        u_char event_type;
        u_short bus_id;

with the expectation that existing files will have event_type and bus_id 
values of 0?

If urb_type is written in big-endian format, then, on a big-endian 
machine, that's

        +--------+--------+--------+--------+
        |xfertype|evttype |     bus id      |
        +--------+--------+--------+--------+

which puts the bus ID in the lower 16 bits of urb_type.  That won't work 
if urb_type just had pcap_urb_type_t values in it.

On a little-endian machine, it'd be

        +--------+--------+--------+--------+
        |     bus id      |evttype |xfertype|
        +--------+--------+--------+--------+

but, if urb_type is in big-endian format, presumably it'd be 
byte-swapped on a little-endian machine, so the same problem would occur.

> But there is a (hopefully) last issue: due to my total ignorance of the
> USB protocol at the time I wrote the code, I used the network byte order
> for encoding each field of the headers I build up in the pcap
> processing. Now I know that USB use a little endian encoding. In order
> to retain the binary compatibility with old traces the the network byte
> order should be retained, but this looks quite ugly... should I move to
> the little endian encoding ?!?

You might want to.

Currently, the USB support is not in any official libpcap release - it's 
only in the main branch.  As such, there might not yet be a lot of code 
that supports it or files that use it, and you could provide a program 
that reads a file and fixes it for the files that do use it.  As such, 
you might be able to get away with changing it.

Alternatively, you could get a new DLT_ value for the little-endian format.

> Note: the pcap_usb_setup header is currently build up from the pcap code
> (in network byte order), but, with the new binary interface, will be
> provided from the kernel (in little endian byte encoding).

Will that be the case even on big-endian machines?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.