Wireshark Dissector for QMI Protocol

[Bjørn Mork]

Aleksander Morgado <aleksander at lanedo.com> writes:

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

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

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.


Bjørn