First I think that it is not really feasible to change the DLT type again.
Looking at traces from the current DLT189 and the updated (and now
functional) usb dissector there are a few observations.
The pseudoheader given to the dissector lacks several useful fields
which would make life easier.
1, the pseudoheader does not contain a flag which states whether the
frame is a request or a response.
The field for URBtype is not sufficient in this case since eventhough
this field is either a SUBMIT call or a COMPLETE this still does not
work correctly when dissecting packets since for URB_INTERRUPT frames
the exchange is actually (at least this is what usbmon spits out
through libpcap and wireshark just have to deal with it)
1, COMPLETE
2, SUBMIT
I.e. these transactions are "reversed" and thus to make any kind of
sense of them the usb dissector contains code to
assume that a SUBMIT is a request unless we are in an URB_INTERRUPT
frame because in this case it is a response.
It would be nice if usbmon could have provided this information to the
application but as far as I can tell the linux_usb_phdr that we
receive from libpcap does not contain such information.
It would be nice if this information was available from usbmon but it is not.
Modulo changing the DLT value AGAIN the only three possibilities I see are:
1, lear to live with some extra code in packet-usb.c to heuristically
determine what is a request and what is not.
2, change USBMON to use yet a new DLT value which i think would be
insane and i would hope the pcap guys would veto.
3, change wiretap so that we use a different "extended" pseudoheader
between wiretap and the dissector and keep the suboptimal one as is
between libpcap and wiretap. This would imho be pointless since we
should still need the heuristics and would just move the uglyness from
packet-usb.c and hide it inside the wiretap code instead. But the
heuristics would still need to be there.
I am not sure if it is optimal to use two different linux_usb_phdr
strutures anyway.
ideas?