Wireshark Dissector for QMI Protocol
aleksander at lanedo.com
Wed May 16 01:29:08 PDT 2012
>> 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.
> Yup. I had a brief thought about "dictionaries" as a result of the
> Wireshark dissector (since I use RADIUS a lot and enjoy the usage of
> standard FreeRADIUS dictionaries with the Wireshark RADIUS dissector),
> but concluded that the protocol it too complex to make that fly.
> JSON might do it. But there are lots of protocol complexities of the
> "if (higher-level-condition-x) then everything-is-completely-different"
> Like the completely unmotivated transaction ID size for QMI_CTL. Or
> formats for the *same* system/msgid/tlv depending on whether it's a
> request, reply or indication. Or the required set of TLVs depending on
> some outside factor, like which radio system we happen to be connected
The different size of TID in QMI_CTL is just handled directly in the
generated code, no extra rule setup just for that. For the remaining
'rules', I was hoping to be able to use different prerequisites; like if
a given TLV has a different meaning depending on a previous TLV; I can
always write the TLV twice (same ID) with different struct members *and*
different/opposite prerequisites. The JSON will start to get complex in
that case anyway.
> And many of the TLVs are also unnessarily complex IMHO, packing a number
> of different settings into a single TLV. That's only a struct typedef,
> but if the number of them are expanded by system/msg/msgtype/tlv, then
> it is going to be messy. It's not as bad as that of course, but
Yes, they really try to make it super complex. One of my assumptions,
which I hope will always be valid, is that already defined TLVs won't
change in future releases. Adding new TLVs to existing messages or full
new messages (e.g. Get Bearer Data Technology & Get Current Bearer Data
Technology) shouldn't be a problem.
> But your JSON looks like it could handle most of this. Not too sure
> about the "mandatory" TLV flag. The answer might be "depends" in a lot
> of cases.
Well, a key with prerequisites is mandatory only if the prerequisites
are satisfied; so yes, actually depends. The only mandatory key ever is
the response status TLV in the response messages.
Anyway, this codegen is just a quick try of what could be done, it may
end up going nowhere.
More information about the libqmi-devel