Hey!
> 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... > That makes sense, and the patch is likely an easy one :) thanks for debugging this.
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
