Hey, > > Thanks for your kind reply. > As you have mentioned, the issue we met has been fixed in commit > 16383670dcb471d6a5b802a9cca1e2a24eb86de5, but we failed to find this commit > in your gitlab. > Can you please give us a link about this? >
Not sure where you looked for it :) https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/commit/16383670dcb471d6a5b802a9cca1e2a24eb86de5 > Also, we have tested thousands times with Modem Manager(1.18.2) and > libqmi(1.31.2). When we repeated the > Syetemctl restart Modem Manager service, there were still CID leaks. And from > the hardware signal analysis of modem, > when restarting Modem Manager, the modem of Quectel did not receive all > signal to release, which led to CID leaks. > The modem failed to reinitialize and stopped to offer service. > > And under same hardware and software conditions, we have tried to modify > value of killmode into process on MM and to > reset MM while not reset qmi-proxy. It seems that there is no abnormality of > CID. The QMI clients were implicitly tracked by > qmi-proxy and the CID was used repeatedly. > > So here is our question. When the service of qmi-proxy stopped, it seems that > it's necessary to release the QMI clients which > are in charge of qmi-proxy. There are no QMI clients in charge of qmi-proxy, qmi-proxy tracks the clients managed by other processes. Also, the qmi-proxy must not be stopped if there are other processes using it. E.g. if MM is still running, qmi-proxy must never exit, until MM is stopped. Also, can you confirm you're not running qmicli commands in addition to MM managing the modem? > > Can you help to explain the root cause of this issue? > Not possible without looking at debug logs of both MM and qmi-proxy while the issue is happening :) I think it's better if you gather those logs, find exactly where the issue is happening in the log, and post them for review to a new Issue in gitlab. -- Aleksander https://aleksander.es
