Wireshark Dissector for QMI Protocol

[Aleksander Morgado]

>> 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
> type
>   "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
> to.

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
> still...
> 

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.

-- 
Aleksander