Modem-Manager blocking UART for AT commands


I’m using TorizonCore 6.5.0-build.8 on an iMX8MM with quectel modem.
I’m using Modem-Manager to manage the connections without problems.

I’ve only encountered a problem because I need to send some configs with AT commands over the serial port, and it seems modem manager sometimes is blocking the ttyUSB# for AT commands.
I know for sure it is the ModemManager because if I stop the service I’ve got no errors with the sending and receiving data from ttyUSB#. If I start the service, sometimes works, sometimes don’t.

I tried THIS approach by adding a new rule for the modem with the id and id product 2c7c:0125 for the USB modem,
ACTION=="add|change", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0125", ENV{ID_MM_DEVICE_IGNORE}="1"


but is seems it does not work

Not sure what is the best solution to exchange AT commands to the modem without stopping the service Modem-Manager.
Hope someone can give me some hints here.


I thought I remembered something about multiple channels on those modems that are exposed? How many ttyUSB# are listed after the system is up? Does modem-manager.mmcli -m 1 list them?

I have 4 ttyUSB ports, USB3 is for AT commands, and USB4 is for secondary AT commands.
Usually only USB3 responds to AT commands.

mmcli -m 1 lists the 4 virtual ports.

Hello @peterz,

From your description, it seems that Modem-Manager occasionally using the ttyUSB# port is the expected behavior.
Therefore, it would not be ideal to stop that communication.

An approach which could allow you to still send AT commands to the modem while keeping Modem-Manager working as expected is to handle the EBUSY error code when you try to open the ttyUSB# on your custom application.
If you get that error code you can try to open the port again some time later.

Best Regards,

Hello @bruno.tx ,

Waiting for the port to be available does not seems a solution for us, we need to check periodically some data using AT commands.

I’ve also encounter THIS alternative, which kind of works by starting the modem-manager in debug mode with:
sudo /usr/sbin/ModemManager --debug

We can later send AT commands and check response with:
sudo mmcli -m 0 --command="ATI"

The downside of this approach is the complete garbage of logs that modem-manager spits into journald :face_vomiting:
I really thought that a more elegant solution can be done here to use the serial ports in “parallel” with modem manager.

Hello @peterz,

If waiting for the port to be available is not an option, then using D-Bus to communicate with the ModemManager Daemon may be an alternative.

With it you should be able to achieve the same results you have when running ModemManager in debug mode and using mmcli.

The reference for the D-Bus API for ModemManager is available here: Part IV. D-Bus Reference: ModemManager Reference Manual

Best Regards,

So, are both USB3 and USB4 “supposed” to be available for AT commands? Is one of them specifically for modemManager access and the other for other users? Is your “usually” comment when you kill modemManager and are able to access or is there something else there? Does the modemManager use a lock file when it accesses the modem and then respects it when something else accesses the modem?

Hello @bruno.tx ,

Been there also.
Using the following:

dbus-send --system --dest=org.freedesktop.ModemManager1 --print-reply /org/freedesktop/ModemManager1/Modem/0 org.freedesktop.ModemManager1.Modem.Command string:'ATI' uint32:2000

Error org.freedesktop.ModemManager1.Error.Core.Unauthorized: Cannot send AT command to modem: operation only allowed in debug mode

I get the same error when trying to send AT command to the ModemManager, it need to be in debug mode, which we don’t want also.

Hello @peterz,

That is unfortunate, sorry for the incorrect advice.

So we have the following situation:

  • ModemManager and your application need to use the same serial port
  • Waiting to open the serial port on your application is not an option
  • Debug mode gives too many logs and is not ideal for production

I see two possible ways to handle the problem:

  • Create a custom plugin for ModemManager that does the tasks you require. If inter-process communication is required with your application, this would have to be implemented as well. This approach would be the most proper way to deal with your requirements.
  • Run ModemManager in debug mode and deal with the increased logs. While debug mode does not allow the log level to be reduced, the logs can be redirected somewhere else with --log-file=. This approach is not recommended, as the debug mode of ModemManager is only intended to be used for debugging.

Best Regards,