QMI CID leaks
teijo.kinnunen at uros.com
Wed Apr 15 07:37:25 UTC 2020
On 14.4.2020 17.55, Teijo Kinnunen wrote:
> Possibly this could also be something in qmi-proxy side. I assume it is
> expected that even after MM disconnects from it, it's supposed to
> execute all queued QMI operations. Looking at the code, it seems that if
> sending the response from device_command_ready() fails for the first of
> the QMI Release CID operations (which sounds plausible, in case MM has
> disconnected), untrack_client() gets called and it may close the QMI
> device, blocking the execution of the remaining QMI commands.
> I didn't actually debug it yet to find out if this is what really
> happens, but maybe I can look at it tomorrow.
OK, got it sorted now. What happens between MM and qmi-proxy is as follows:
- MM sends 6x Release CID to qmi-proxy (using libqmi) and disconnects
- The socket handler in qmi-proxy (connection_readable_cb) receives
these messages in two batches. The first batch contains 2...3
Release CID messages (which are processed OK) and the second batch
contains the remaining ones. The second call has *both* G_IO_IN and
G_IO_HUP set. As connection_readable_cb() processes G_IO_HUP first, it
will never get to handle the remaining Release CID messages.
=> This leads to CID leak.
So it looks like this could be fixed most easily in qmi-proxy. I will
post a patch candidate for review/merging to libqmi project soon...
More information about the ModemManager-devel