Hi again,
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
immediately (qmi_device_close_async).
- 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...
BR,
- Teijo
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
