Hey! > I added the "mmcli -m 0 -e" right after starting ModemManager, but in this > case I got the message: > error: couldn't find the ModemManager process in the bus >
Like directly after starting MM? MM needs time to boot and expose interfaces in DBus, you shouldn't be trying to enable a modem immediately after MM is started. Actually, there should not be any issue with starting MM right when the system starts, and you can start both NM and MM in parallel if needed. Then, only once the modem is probed and exposed in DBus, NM would start the autoconnection process. There shouldn't be any need for any other logic to be added, it's a bit surprising that you get these errors I think. > Then I added a "sleep 1" before the "mmcli -m 0 -e", but still got an error > message: > error: couldn't find modem at '/org/freedesktop/ModemManager1/Modem/0' > Well, MM needs time to probe the modem. You can monitor the availability of the modem with "mmcli -L" or "mmcli -M", or using your own custom program to do so via libmm-glib (e.g. even in Python). See the modem watcher example: https://cgit.freedesktop.org/ModemManager/ModemManager/tree/examples/modem-watcher-python ModemManager will only expose the modem in DBus (i.e. expose it to NM and other clients) once the modem is ready and fully probed, and that may take a while. > I looked a little more into what was going on and found that this TOBY-R200 > modem takes much longer than other u-blox modems I have used to initialize > the virtual USB serial ports on startup. It appears with the USB serial > ports appear after ModemManager has already started, the longer registration > occurs. When I put a delay before ModemManager is started until after the > USB serial ports appear, then I always get the fast registration. This is > without the "mmcli -m 0 -e" command being run at all. > So you mean that if MM tries to poke the ports *while* the TOBY is still booting, it makes it timeout in the registration? I have seen myself that in a different u-blox device the TTYs are *not* ready as soon as they're exposed by the kernel, it may take up to 10s-15s since they are exposed to be ready for AT commands (although it usually is something like 5s-8s). But I haven't seen a case where poking the TTYs early would end up triggering registration failures or delays. > I am not sure what in ModemManager is causing the registration issue based on > this ordering of which appears/starts first. > I've asked u-blox about this and hopefully they'll have an idea of what's happening here. > > Additionally it seems to take a really long time during a fast registration > for ModemManager to actually startup, probe the modem, and attempt to > connect. It looks like the time between when ModemManager starts and when a > simple connect can start because enough probing of the modem was finished is > 34 seconds. Much of this is waiting for 20 seconds for the /dev/ttyACM3, > /dev/ttyACM4, and /dev/ttyACM5 interfaces to timeout to probing and then > another 5 seconds as the same interfaces have AT commands sent to it and > timed out again. These are not AT command interfaces so it would be nice if > this could be optimized for this modem. I am not sure if this can be done or > how to do it with ModemManager. > That is easily solvable if the modem has predefined interfaces for different purposes, which is very probable in this case. See e.g. the TOBY-L4 port type rules defined here: https://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/ublox/77-mm-ublox-port-types.rules -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
