Wireshark Dissector for QMI Protocol

[Markus Gothe]

Hi,
I found this one very interesting... Didn't knew you could dissectors in LUA for Wireshark these days.
However I didn't get it working with Wireshark 1.4.x... :-/ Just segfaulting in tshark on Ubuntu.

The 'qmidb' repo...? Is it anything interesting that's not available from CodeAurora (yes, the C++ code they released is horrible ;-) )

Best,
//Markus - The panama-hat hacker

On May 15, 2012, at 21:10, Aleksander Morgado wrote:

> 
>>> 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
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel