Wireshark Dissector for QMI Protocol

[Aleksander Morgado]

>> I was playing with QMI-capable devices a lot the last few days and
>> created a dissector for Wireshark,
>> that helps me to monitor Windows-based connection manager running in
>> VirtualBox and my own app.
>> I'm sure you will find it useful too: https://gist.github.com/2641557
> 
> I'm sure I will.  That's really nice.  Great idea!
> 
> For anyone not having looked at this yet: Ilya uses the existing usbmon
> capabilities of wireshark, so this dissector can be used regardless of
> how you communicate with your QMI device. cdc-wdm, qcqmi (Gobi driver),
> or virtual machine passthrough - anything can be snooped.
> 

That is super cool; I've written protocol dissectors for Wireshark in
the past myself, I just didn't know you could also use it for USB.

> Would be even nicer though if there was some way to (semi-)automatically
> generate the message and TLV tables from existing data in e.g. libqmi,
> to avoid having yet another place where these must be entered
> manually...
> 


Dan's `qmidb' in the upstream repo tries to create packed structs for
specific messages directly from the Gobi database files; so that could help.

I've also been playing around with something related but a bit
different; which is defining the messages myself manually in a JSON file
(see [1]) and then autogenerating the message creator/parser code
directly from there with some python-based codegen (see [2]). The
'qmi-codegen' branch in my libqmi-glib tree does all this (actually, it
still fails to generate something compilable... :-). Anyway, this
approach tries to handle additional things than just reading every
possible TLV from a specific QMI message, like (a) the case where some
TLVs are given only if some other TLV exists and has a specific value
(e.g. 'call end reason' TLV is only given in the 'wds start network'
response if the response status was FAILURE and the error code was 'call
failed'); or (b), the case where some given TLV has one meaning or
another based on a previous TLV (e.g. 3gpp or 3gpp2 specific values on
the same TLV, based on a previous TLV which defined whether it is 3gpp
or 3gpp2).

But what I think we all agree is that libqmi should really expose not
only a client-based high-level API, it should also include the low-level
message creation/parsing API as well, which this dissector could use to
get the message contents translated.



[1]
https://gitorious.org/lanedo/libqmi-glib/blobs/qmi-codegen/data/qmi-service-ctl.json
[2]
https://gitorious.org/lanedo/libqmi-glib/trees/qmi-codegen/build-aux/qmi-codegen


-- 
Aleksander