Re: Quectel EC25 & AT connection Catch-22
Hey Bruce, Thanks to everyone who joined the discussion, all the points already raised are valid. Just some small notes from my side. > > I have a question about using both QMI and the serial interface with > ModemManager. > > I had little difficulty getting ModemManager's SimpleModem to connect to > T-Mobile (USA) using a Quectel EG25-G, but we found that modem wasn't > compatible with AT and/or a private APN used by one of our customers. We > were advised to use the Quectel EC25, and after engaging both Quectel and > AT, we were told that we need to insert the APN into the modem using an AT > command, AT+CGDCONT=1,"IPV4V6","mcm.com.attz". I had to tweak the kernel > config and the ModemManager build. That command is exclusively changing the contents of the connection profile stored with ID 1 in the modem. This profile with ID 1 is the one typically used for the LTE attach procedure during the registration process in Qualcomm based modems. You cannot change these APN settings with Simple.Connect(), as this API is used to establish a new connection attempt after you have been registered already. In your case, you need to change the settings before registering (they're really persistent, so changing once would be enough), and then you can reuse the same settings for the connection attempt. You can change the APN settings used during LTE registration using mmcli --3gpp-set-initial-eps-bearer-settings="apn=mcm.com.attz,ip-type=ipv4v6", you don't need to do it via AT commands. The next registration attempt after the settings are changed will be done with those new settings. After the registration happens, the "3GPP EPS" section in the mmcli output may include an "initial bearer path", and if you print the contents of the bearer using mmcli -b N, you can see the actual APN settings agreed with the network. -- Aleksander
Re: How to probe a modem exposing virtual ports (GSM 07.10 muxed ports)
Hey, > > I am in the same situation and my Quectel BG770A-GL modem is using the > EMUX instead of the standard CMUX mode. > > Quectel is only providing full PPP support for this EMUX mode and so > would like to know what could be > the best way to add support for thoses /dev/pts virtual devices in MM ? > > Im using ModemManager 1.18, is it possible to "force" a port (without > udev) in MM ? > I have not done any testing myself with this kind of ptys, but I don't think it should be very difficult to support them, at least e.g. manually. You can try to run the MM daemon with --test-no-udev, and then use mmcli --report-kernel-event to notify about the port additions as if they were notified by udev. See e.g. https://lists.freedesktop.org/archives/modemmanager-devel/2016-August/003269.html This approach *won't work* by default for ptys, but it may give you an initial way forward if you want to start testing custom MM changes to adjust the port probing to support these device types. The MMKernelDevice objects will need to be adjusted to support these device types that don't have a direct counterpart entry in sysfs. -- Aleksander
Re: SIM PIN Unlock Error in MM 1.22.0
Hey Amol,
>
> We are getting following error when trying to send pin to the SIM card. The
> problem is not observed in MM 1.20.4. However, please note that the SIM card
> does unlocks after the below command even though error is reported.
>
> # mmcli -i 0 --pin=1234
> error: couldn't send PIN code to the SIM:
> 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't get
> interface skeleton'
>
> Now, after looking through the code, following change is causing this issue.
> This change was not present in 1.20.4
>
> mm-broadband-modem-mbim.c:
> if ((self->priv->enabled_cache.last_ready_state !=
> MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED &&
> ready_state == MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED) ||
> (self->priv->enabled_cache.last_ready_state ==
> MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED &&
> ready_state != MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED)) {
> mm_obj_dbg (self, "Lock state change detected");
> active_sim_event = TRUE;
> }
>
> self->priv->enabled_cache.last_ready_state = ready_state;
>
> if (active_sim_event) {
> mm_iface_modem_process_sim_event (MM_IFACE_MODEM (self));
> }
>
> What is happening is when SIM PIN lock state changes then
> mm_iface_modem_process_sim_event () is called which eventually calls
> mm_base_modem_set_reprobe(). The reprobe, "unexports" the current modem
> instance (modem 0) and recreates a new modem instance (1). As a result, the
> above mmcli command is reporting error. I'm not sure why this should happen
> for SIM Lock state change.
I think this has been fixed in MM git main branch; is there any chance
you could test with that? See
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/19fd9c634b8f2876694d18a77a3b686a0c08bf34
--
Aleksander
Re: Re:Re:Re: May I commit binary files into MM project?
Hey, Sorry bother you again. In our local another PC, the way previous I used > don't work by method 'sudo systemctl start ModemManager'. > But command method 'sudo ModemManager' works. > There are 2 attachments for reference. > ModemManager.log was generated by command > 'sudo ModemManager --debug --log-level=DEBUG' > And ModemManager.service.log was generated by command > 'sudo systemctl start ModemManager' > > We can see modem can attach to NW in ModemManager.log since Fcc Lock > has been unlocked, even though there is no unlock message print(does it > reasonable?). But in another log, we can see modem was stuck in state3 and > state4. > > Looks like in the case of the systemd service start, MM is not finding the FCC unlock script for some reason? Try to enable debug MM logging in the systemd service file, and check the filesystem paths reported by the daemon where it's looking for the unlock script. -- Aleksander
Re: How to probe a modem exposing virtual ports (GSM 07.10 muxed ports)
On Tue, Apr 9, 2024 at 11:28 AM Garfield Watkins wrote: > > Is there any other workaround you can suggest ? I really do need these > virtual terminals exposed by the multiplexer. > Without adjusting MM to support the specific use case of the ptys, I'm not sure there is any easy way to handle this, I'm afraid. -- Aleksander
Re: How to probe a modem exposing virtual ports (GSM 07.10 muxed ports)
Hey > > No unfortunately they are not. They (the psuedo terminals) are created by > opening /dev/ptmx which creates a terminal(s) in /dev/pts/ . These are not > enumerated in any way. Oh well... let me try your suggestion and see if it > works. > If the ptys don't have an entry in sysfs, not even as virtual devices, then the no-udev path won't work either -- Aleksander
Re: How to recover from serial device being force closed.
Hey! > > I completely understand why there may be concerns at editing such critical > code for a use case that is not very common. > > Unfortunately my current situation requires renaming the interfaces. Multiple > modems may take turns being 'selected' (having the interface renamed) to pass > traffic. I hope to remove that need one day, but until then I will need this > patch. > So you have a modem that is in connected state but isn't selected to pass traffic, and when it gets selected, the net interface is renamed to some other name? I think it is the first time I've seen something like this :) Is it because some other app uses a hardcoded net interface name somewhere or something like that? > Even if this is an uncommon problem, I still think this change (or at least > my approach) could be useful to pull into ModemManager mainline. Yes, people > don't rename interfaces often, but it is something that Linux/udev support, > these events effectively breaks the Modem object lifecycle in ModemManager > (which makes ModemManager look buggy), the log messages that are printed out > do not make it clear that renaming the interface caused it (it took my a long > time to figure it out), and I have not seen any piece of documentation > warning that renaming any interface managed by ModemManager is unsupported. > Technically it is completely possible, but my worry is that it may introduce an amount of complexity that is not worth the effort. Updating the documentation to say that MM currently does not support interface renaming once the device has been initially probed would be quicker... and maybe we should do that right away even before thinking about supporting your usecase. > You do bring up an interesting point I had missed: what if someone renamed a > control interface? My code currently would not catch that, but maybe it > should! > Renaming the control interface would be overkill. Renaming the net port may be somewhat easier. > ModemManager handles tons of events and states for modems and all the weird > things they can do. If a user could do something with the ModemManager API > that caused strange errors like I described, the issue would be fixed in the > driver/etc. > > Linux Interfaces can be renamed using the Linux API, and while they are > renamed, ModemManager is in a precarious state until the interface is changed > back to its original name. Removing or resetting the modem in that precarious > state will cause ModemManager to act strangely for that modem until it is > removed again with the original interface name (which could be a problem if > another modem was added while the interface was renamed). And linux+udev > gives us all the tools to handle these known and supported events. I > personally think these are enough reasons to address this behavior. > > I see this as an issue of stability, reliability, and resiliency. Even if > this behavior is rarely encountered, I believe there are substantial reasons > to fix it. That does not mean that my code is the best way to do it. If you > end up agreeing that this behavior should be fixed, I will make revisions to > address your concerns. > MM also has a lot of limitations, and one of the limitations that I always warn about is that the state of the modem should not be touched out of MM's own APIs. E.g. if you run QMI commands that modify the state of the modem using qmicli, MM may not pick them up. If the state needs to be updated, it should be done using MM's own APIs. I think we can say the same about this problem, you're trying to modify the state of how the modem is exposed in the kernel out of MM's eyes, and expect MM to pick that up. Technically both things could be possible, but it may really be too much complexity introduced for little gain, especially when the issues can be avoided in other ways :/ > To the complexity of my code, I tried to made it pretty straight forward and > self contained. When a rename event happens, find the Modem object associated > with the old device name, remove the old name from the modem, and add the new > name. I could make the replacement logic into a function to keep the code > more readable if you would prefer. > Aren't we fully re-probing the modem from scratch upon the net interface rename? We could try to do that as an initial step, in the same way as we do the forced reprobing when e.g. the proxy dies or when the SIM card is switched. The reprobing logic will make MM re-detect the modem object with the new state. > You mention opening the door to more complex interactions, and that is > interesting. If I don't correctly handle the udev events, then I am not > really fixing anything! > > I just looked up all of the udev event types: add, remove, change, move, > online, offline, bind, and unbind. > > ModemManager already has support for add, remove, change (kind of, more on > that later), and with my patch move (I would argue that the upstream version > of
Re: How to probe a modem exposing virtual ports (GSM 07.10 muxed ports)
On Tue, Apr 2, 2024 at 3:43 PM Garfield Watkins wrote: > > Unfortunately there doesn't seem to be a way for to write a udev rule against > a pseudo terminal... > Are they not notified via udev really? You could also try to set it up with ModemManager not running with udev support (--test-no-udev) and then report the ports manually with mmcli (--report-kernel-event). -- Aleksander
Re: Empty APN, 2 PDP contexts and 1 PDP context
Hey!
>
> First of all I wanted to say thanks for developing and supporting a great
> piece of software.
>
Thanks to you for using it!
> We have a few thousand devices running ModemManager 1.18.6 and Quectel EC21
> modem. Our service provider Twilio/Kore keeps reporting that on some devices
> we have 2 simultaneous data sessions with different APNs: "super" and
> "de1.super".
>
> We use ModemManager's API to find the modem, enable it, then wait for
> auto-register done by the modem FW, and finally create a bearer with
> "de1.super" APN and connect. Operations are run over QMI protocol.
>
Ok, so if I'm reading this right, you do NOT explicitly configure the
attach APN settings, you only provide the data APN settings. The
attach APN settings are provided by the modem itself.
> We have autoselect disabled, so I'd expect to always use European APN
> "de1.super", instead of US "super" which is the default.
> mmcli -m 0 --command='AT+QMBNCFG="AutoSel"' response: '+QMBNCFG: "AutoSel",0
I don't know what AutoSel does in these modems, can you elaborate?
> We have made an experiment to show PDP contexts on the devices with
> AT+CGDCONT?, and noticed an interesting thing:
> On most of them, it only shows 1 PDP context:
> PdpContext { ctx_id: 1, pdp_type: IpV4V6, pdp_addr:
> \"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0\", apn: \"\", data_comp: Off, head_comp:
> Off, ipv4_addr_alloc: NasSignaling, request_type:
> ContextEstablishmentOrNon3GppAccessNetworkHandover }
>
> However, on 1 of the 200 devices, we see 2 PDP contexts:
> PdpContext { ctx_id: 2, pdp_type: Ip, pdp_addr: \"0.0.0.0\", apn:
> \"de1.super\", data_comp: Off, head_comp: Off, ipv4_addr_alloc: NasSignaling,
> request_type: ContextEstablishmentOrNon3GppAccessNetworkHandover }
>
> PdpContext { ctx_id: 1, pdp_type: IpV4V6, pdp_addr:
> \"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0\", apn: \"\", data_comp: Off, head_comp:
> Off, ipv4_addr_alloc: NasSignaling, request_type:
> ContextEstablishmentOrNon3GppAccessNetworkHandover }
>
> However, even on device with just 1 PDP context received from AT command
> # mmcli -m 0 --command='AT+CGDCONT?'
> response: '+CGDCONT: 1,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0'
>
> AT commands are run ~10 minutes after modem setup and connection is done with
> ModemManager.
> ModemManager always reports 2 bearers, I understand the 1st bearer is LTE
> default EPS bearer, while the 2nd one is the actual data session bearer:
>
Yes.
> # mmcli -b 0
> -
> General|path: /org/freedesktop/ModemManager1/Bearer/0
> |type: default-attach
> -
> Status | connected: yes
> | suspended: no
> | multiplexed: no
> | ip timeout: 20
> -
> Properties | apn: super
> | ip type: ipv4
>
> # mmcli -b 3
>
> General| path: /org/freedesktop/ModemManager1/Bearer/3
> | type: default
>
> Status | connected: yes
> | suspended: no
> |multiplexed: no
> | interface: wwan0
> | ip timeout: 20
>
> Properties |apn: de1.super
> |roaming: allowed
> |ip type: ipv4
>
> IPv4 configuration | method: static
> |address: 100.79.145.117
> | prefix: 30
> |gateway: 100.79.145.118
> |dns: 8.8.4.4, 8.8.8.8
> |mtu: 1360
>
> Statistics | duration: 3810
> | bytes rx: 513071
> | bytes tx: 296673
> | attempts: 1
> | total-duration: 3810
> | total-bytes rx: 513071
> | total-bytes tx: 296673
>
In the above output, your initial EPS default bearer that is brought
up during attach is using the "super" APN. I don't think this is what
you want, based on the previous comments? Not sure.
> I have some questions:
> 1. When using QMI, is it reliable to check modem state with AT commands? I
> don't care about immediate / race conditions, but I'd like to know that if I
> run some AT command e.g. 1 hour after it was set up by ModemManager with QMI
> it will tell me the accurate modem state.
>
Yes. As long as you don't modify state of the modem with the AT
commands, i.e. only use commands to read the state, you can safely run
them and they will give you the latest up to date info.
> 2. Why do some devices have only 1 PDP context with
Re: Modems not detected with the latest MM
Hey Radu, > > I attached 1 OK log (ModemManager-1.23.4-ok.log - git > 6a8797927c1ef9df1f56513b742f01de86f5167f), and one not ok log > (ModemManager-1.23.5-nok.log git 6388b583c7b9c25d3061a070f54f9d97d59e2b2c). > > Please let me know if I can be of any help. > Radu > I looked at the two logs and I cannot find any reason why mmcli would not report the modems. I can see the 2 modems being detected in both logs, and in both of them the "exported modem at path '/org/freedesktop/ModemManager1/Modem..." logs happen, showing that they are being exposed in DBus. I'm really interested in knowing why this failed for you, could you please try with the latest git main branch and maybe even run a git bisect between the two version to see if we find which commit is causing the problem? -- Aleksander
Deprecating 3GPP2 (CDMA/EVDO) and POTS
Hey! I think it is time to deprecate all 3GPP2 related implementations, which would include fully removing the Modem.Cdma interface and the support for CDMA/EVDO-only devices. Most (all?) networks have already phased out 3GPP2 based network technologies, and so there is really no point in maintaining this unused logic in ModemManager. * The Modem.Cdma interface is a feature interface that is only exposed if the modem supported 3GPP2 technologies, so we can just stop exposing it. In order not to break ABI, the corresponding methods in libmm-glib would be moved to the compat layer and basically make them no-ops. * 3GPP2-only plugins would also be removed. Regarding POTS (Plain Old Telephony System), we never really supported any of the dial-up modems properly as we focused exclusively in mobile broadband devices. In this case, I think it makes sense to state that we don't and won't support POTS devices, instead of still saying in multiple places that we may support them in the future. Is anyone aware of any issue if we do this? Comments welcome! -- Aleksander
Re: Modems not detected with the latest MM
Hey! This is strange, but possible, because I did touch device probing between those two releases. Could you send a MM debug log with your failed modem detection using git main? On Tue, Mar 26, 2024 at 10:05 PM Radu C wrote: > > Hi, > > As a test I tried the latest MM (git SHA-1 > 6388b583c7b9c25d3061a070f54f9d97d59e2b2c). On my setup, this version does not > detect the modems. The last version that detects the modems properly is the > one at commit 6a8797927c1ef9df1f56513b742f01de86f5167f. Is there something I > should do differently for the latest builds, or is this a known issue? > > Thank you, > Radu > > SHA-1 6388b583c7b9c25d3061a070f54f9d97d59e2b2c: > > root@MCG-67:~# mmcli --version > mmcli 1.23.5 > Copyright (2011 - 2023) Aleksander Morgado > License GPLv2+: GNU GPL version 2 or later > <http://gnu.org/licenses/gpl-2.0.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > root@MCG-67:~# mmcli -M > No modems were found > ^Ccancelling the operation... > > root@MCG-67:~# uptime > 20:21:11 up 4 min, 1 user, load average: 0.20, 0.28, 0.13 > > SHA-1 6a8797927c1ef9df1f56513b742f01de86f5167f: > > root@MCG-67:~# mmcli -M > No modems were found > (+) /org/freedesktop/ModemManager1/Modem/1 [Cinterion] Cinterion PID 0x00B3 > USB Mobile Broadband > (+) /org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless, Incorporated] > Sierra Wireless EM9291 > ^Ccancelling the operation... > > root@MCG-67:~# uptime > 20:53:53 up 1 min, 1 user, load average: 1.19, 0.37, 0.13 > root@MCG-67:~# mmcli --version > mmcli 1.23.4 > Copyright (2011 - 2023) Aleksander Morgado > License GPLv2+: GNU GPL version 2 or later > <http://gnu.org/licenses/gpl-2.0.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > -- Aleksander
Re: SIM Reconnection Issues (Modem Manager 1.20.4)
Hey Armand, > > Find attached a .zip with 4 logs files: > >- *mmlogs_P2.log*: is the ModemManager logs for one of the boards >(board P2) >- *nmlogs_P2.log*: is the NetworkManager logs for the board P2 (board >P2) >- *mmlogs_P4.log*: is the ModemManager logs for the other board >(board P4) >- *nmlogs_P4.log*: is the NetworkManager logs for the board P4 (board >P4) > > For both of the boards we have reproduced the same scenario in paral·lel > with the same enabling/disabling SIM times. > > The logs start Monday March 11th, at around 2:29 PM UTC for both boards. > At this point, SIMs are enabled, and get connected. > Then, aproximetly 3-4 min later, at 2:32 PM UTC, both SIMs are disabled > remotly: > >- For board P4, the epoch where the state changed is >[1710171130.242576] [modem0] state changed (connected -> registered) >- For board P2, the epoch where the state changed is >[1710171121.444769] [modem0] state changed (connected -> registered) > > The SIMs are now disabled for an entire day. This is now March 12th, at > around 8:06 AM UTC. We enable both SIMs. > In the logs, nothing changes. We leave it be for around 3 more hours to > see if at some point it is reconnected, but nothing changes. > > The modem is initially registered and connected with the Movistar network (21407). When the EMnify SIM card is disabled, we get kicked out of the network and eventually fully unregistered (registration_reject_cause = 'no-suitable-cells-in-location-area'). This process looks good enough to me. When the SIM card is enabled again, there is obviously no way to ask the modem to explicitly start a new registration with the Movistar network. We need to fully rely on the modem's own network search and selection logic. The problem here is that the modem ends up trying to register with *other* networks, and eventually it ends up registered with "limited" capabilities (e.g. for emergency services only) with Vodafone (21401). I don't have the 3GPP knowledge about this at hand, but I'd guess that no-suitable-cells-in-location-area instructs the modem not to attempt registering with the network any more. Can you try to repeat the test, but once re-enabling the SIM card, run an airplane mode cycle through NetworkManager, e.g. "nmcli radio wwan off", wait some seconds and "nmcli radio wwan on". That should put the modem in low power mode and then back on again, and it should very likely reset any network-specific state that was cached in the previous run. -- Aleksander
Re: ModemManager hangs SIMCOM A7602E-H modem
Hello Artem, > I am trying to get SIMCOM A7602E-H modem to work with ModemManager 1.14.12 > and the problem is the modem hangs after some time unless power cycled. If I > disable ModemManager, the modem is working for a long time. > Any chance you can get MM debug logs to see if any of the requests we send is the culprit? https://modemmanager.org/docs/modemmanager/debugging/ -- Aleksander
Re: SIM Reconnection Issues (Modem Manager 1.20.4)
Hey, > > Recently I have encountered an issue related to reconnecting cellular. > > *OS*: Raspian OS Lite (32 bits) -> Linux panells3 6.1.0-rpi7-rpi-v8 #1 > SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux > *Modem*: SIM7600G-H > > The SIM is active. Using mmcli I can see that the state is connected. I > then proceed to de-activate the SIM remotly. This is where the logs start > (Feb 29 13:00:00). > The logs then show a constant change in state where *enabled -> searching* > and *searching -> enabled* is constantly logged. > All the night is spent like this, switching the state. What I am trying to > test is that upon remot activation of the SIM, the connection is resumed > without problems. > So, fast forward to Mar 01, I activate the SIM remotely and nothing > happens. I end up reseting the modem with "mmcli -m 0 --reset" and then a > restart of the ModemManager.service and finally the connection is > established correctly. > > I am not sure what could be the issue. It is also worth noting that we > have tested this in other boards that have the same modem, and the > behaviour is not the same for every board. > > Would you be able to provide full MM debug logs including the times when the SIM was remotely deactivated and remotely activated? -- Aleksander
Re: Assistance Needed with SIM Card Issue Causing QMI Operation Failures
Hey, > > Still having serious issues with this issue.. > > Is there any insight where the QMI errors are coming from? Is it the modem > that is telling MM that there is something wrong? > The errors start to happen when we try to read information from the SIM card. The first problem in the debug log you provided was when reading the preferred operator list, and after that several other SIM file read operations fail. My guess is that either the SIM card gets in a bad state, or maybe it just needs more time to answer. If you have the SIM card at hand and you reproduce the problem, where MM just removes the modem object, you can try to manually run "qmicli -p -d /dev/cdc-wdm0 --uim-get-card-status" operations on the cdc-wdm control port to see if it ever replies or if the card got stuck. Another test would be to fully disable the loading of preferred operator list in MM (assuming that could be the culprit), by clearing up the function pointers in mm-sim-qmi.c: base_sim_class->load_preferred_networks = NULL; base_sim_class->load_preferred_networks_finish = NULL; -- Aleksander
Re: ModemManager Issue with multiple WWAN Sierrawireless Ubuntu 22.04
Hey Ankur, > > I want to report an issue with the modem manager in Ubuntu 22.04. Even though > the modem firmware is updated, the modem manager service causes frequent > disconnection issues. However, when I disable the modem manager service and > use qmicli and minicoM methods, the modem works fine without any > disconnections. I tried contacting the modem using Sierra MC7304 & MC7430, > but it did not solve the problem. The modem manager provides all the > necessary details, but it keeps resetting frequently when I use the internet > or live streaming applications. > I would appreciate your support in resolving this issue. > Please let me know if you require any additional information or logs. > I'm afraid there is not much we can do, if the issue is the modem crashing. You said that using qmicli or AT commands makes it more stable, so it could really be related to some of the setup MM does, but even in that case, only the manufacturer will be able to analyze the modem crashes. The best path forward you have would be to contact Sierra support so that they guide you in how to retrieve modem traces they can analyze :/ The MC7304 is one of the modems that I test on every MM release, and I haven't noticed any strange myself, but of course my network conditions are not the same as yours. -- Aleksander
Re: How to probe a modem exposing virtual ports (GSM 07.10 muxed ports)
Hey Garfield, > I have a situation where I have a ublox modem, the LISA u200, wired up using > its SPI bus as the communication channel. On the DTE side is a raspberry pi > SBC with a custom spi platform driver that exposes a tty device for modem. > This driver is not capable of multiplexing and exposing multiple virtual > channels. > > To overcome this I have a user mode daemon that performs this function by > connection to the single tty port exposed by the spi driver and in turn > creating 5 pseudo tty's (/dev/ptty1 -> /dev/ptty5) to interact with. These > are actually links to /dev/pts/1 to /dev/pts/5. > > I want the ublox plugin to manage this device but there seems to be no way to > filter/grab those ports. > You should be able to add the ID_MM_PHYSDEV_UID udev tags for all those pseudo TTYs, so that ModemManager can "bind" all those ports together to the same modem object, see https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/ModemManager-Common-udev-tags.html#ID-MM-PHYSDEV-UID:CAPS -- Aleksander
Re: Seems like MM_FILTER_RULE_TTY_WITH_NET overrides ID_MM_DEVICE_IGNORE
Hey Menno,
> > After many hours we finally found out ModemManager is probing the devices,
> > so we added the udev rules:
> >
> > /etc/udev/rules.d/78-custom-mm-blacklist-internal-modem.rules :
> >
> > ACTION!="add|change|move", GOTO="custom_mm_blacklist_internal_modem_end"
> > ATTRS{idVendor}=="[redacted1]" ATTRS{idProduct}=="[redacted2]",
> > ENV{ID_MM_DEVICE_IGNORE}="1"
> > ATTRS{idVendor}=="[redacted1]" ATTRS{idProduct}=="[redacted3]",
> > ENV{ID_MM_DEVICE_IGNORE}="1"
> > LABEL="custom_mm_blacklist_internal_modem_end"
> >
> > but looking at the logs I see:
> >
> > ModemManager[3751]: [filter] (tty/ttyACM0): port filtered: device
> > is blocklisted
> > ModemManager[3751]: [filter] (net/enxd[redacted4]) port allowed:
> > net device
> > ModemManager[3751]: [filter] (net/enxd[redacted4]) port allowed:
> > net device
> > ModemManager[3751]: [filter] (tty/ttyACM0): port allowed: device
> > also exports a net interface
> >
> > So if ModemManager successfully found the device is blocklisted, why does
> > it continue to probe the port?
>
> This is definitely a bug. I've opened
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/833
>
We've been trying to get an idea of why this issue is happening in
your setup but it's not really clear.
Would you be able to send a full MM debug log
(https://modemmanager.org/docs/modemmanager/debugging/#daemon-debug-logs)
and share a bit more about your system? e.g. is it openwrt based or
not, the output of "usb-devices" and "lsusb -v" for this device...
Thanks
--
Aleksander
Re: Feature phone with 3G modem capability used to work under 1.18 but no longer works under 1.20
Hey Alex, On Mon, Feb 19, 2024 at 2:31 AM Alex Villacís Lasso wrote: > > El 16/2/24 a las 17:48, Alex Villacís Lasso escribió: > > I have this old phone, a Samsung E3210B pre-Android feature phone that > > I wish to use as a fallback option when (more frequently than I would > > like) my broadband internet service goes down. When using ModemManager > > 1.18.x, I could plug in this phone, and it would expose a single > > /dev/ttyACM0 port for all interactions including AT commands and PPP. > > Then ModemManager could connect to the internet using the port as > > normal, using the "generic" plugin. Now, using ModemManager 1.20.6 > > under Fedora 39, the same phone fails (with a timeout) to establish a > > connection using ModemManager. However, it does setup a proper > > connection using wvdial from the command line, even under Fedora 39. > > > > After a while, I managed to perform a git bisect on the code, and > > pinpointed the first commit that breaks my phone, to commit > > 213cd81b3ade35024e2d702e2726273f00344185 "iface-modem-simple: wait for > > packet service 'attach' state in ConnectionStep". However, I am now at > > a bit of a loss at understanding the supposed purpose of this commit. > > Full details are at this bug report: > > > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/743 > > > > The patch no longer cleanly reverts under 1.20.x, so I cannot just rip > > it off... > > > > I have updated the bug report with a new discovery: ModemManager 1.20 > will dial into the phone immediately, if I first manually select some > phone feature that requires Internet access (such as Google Search), > then click OK in the little dialog that ask to connect to the Internet. > However, this manual interaction with the phone should be unnecessary, > because it was not needed with ModemManager 1.18 and is also not needed > when using the phone through wvdial. > > I need a way to tell ModemManager when using this particular phone to > connect, to IGNORE the "searching" status of the GPRS registration and > dial anyway, since the GPRS will be enabled by the very act of dialing > the Internet access sequence. Is there any existing way to do that? > I replied at the issue, I believe your problem would be solved with MM 1.22 and https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/179a800ab64b28f5437c3d06056640f702e68aa5. You may still experience some delay to connect, because MM will first wait some seconds for the attach state to come up automatically, and only otherwise try to send the operation to activate it. Either way, it looks like your device needs a much more relaxed logic in this regard, so fully ignoring the packet service attach state would be a better option probably. -- Aleksander
Re: ModemManager Issue with multiple WWAN Sierrawireless Ubuntu 22.04
Hey. > Please let me understand the issue with multiple WWANs frequently > disconnecting and reconnecting I am using Sierra wireless modems on the > Ubuntu 22.04 desktop. I have updated the drivers and tried all available > internet options, but no luck. It is not modems are not getting connected, > modems are connected but while giving some load on them they start > misbehaving (WWANs frequently disconnecting and reconnecting) I am using the > default modem manager app from free Desktop org > > Appreciate it if someone could help > This looks like the modem resetting itself, which could indicate modem firmware errors. Make sure you have the latest firmware available from Sierra installed in the device, and if it still happens, report it at https://forum.sierrawireless.com/c/modules/mc-em-series/34 -- Aleksander
Re: No IP address for a successful connection on LTE modem
On Wed, Feb 14, 2024 at 11:21 AM Garfield Watkins wrote: > > I think what confused me is that without the ModemManager i.e. using just > cgact=1,1 to manually connect, i suddenly got an ip address assigned to the > network interface provided by the modem. I thought it was NetworkManager > running its dhcp client on that interface after getting a dhcp discover ? > from the modem ? (i'm not too sure about how dhcp goes about its business) > > Anyway i have now tried to use Network Manager to setup and connect but now > am getting the following message: > > modem-broadband[ttyUSB0]: failed to connect 'meig': Connection requested both > IPv4 and IPv6 but dual-stack addressing is unsupported by the modem. > > and disabling ipv6 I get: > > failed to connect 'meig': Connection requested IPv4 but IPv4 is unsupported > by the modem. > > Any idea where to start debugging that ? > The "SupportedIpFamilies" property in the Modem interface is probably being reported empty? -- Aleksander
Re: Seems like MM_FILTER_RULE_TTY_WITH_NET overrides ID_MM_DEVICE_IGNORE
Hey,
>
>
> I'm running into trouble with ModemManager, there seems to be no way to
> disable probing for certain devices.
> I have found countless threads discussing the lack of this feature, but none
> of them refer to my specific troubles.
>
We did have lots of problems in the past with blocklisting certain
type of devices automatically, we were too optimistic trying to look
for TTY modems. I guess that is what you are referring to, bu that has
changed a lot in the past years.
>
> We have some CDC devices that implement ACM and ether.
> We want to communicate on the ttyACM of these devices, but our data keeps
> getting corrupted.
Are those ttyACM ports AT ports, or some other protocol? ModemManager
would only probe ttyACM ports that report themselves as using the AT
protocol in the USB descriptors.
> After many hours we finally found out ModemManager is probing the devices, so
> we added the udev rules:
>
> /etc/udev/rules.d/78-custom-mm-blacklist-internal-modem.rules :
>
> ACTION!="add|change|move", GOTO="custom_mm_blacklist_internal_modem_end"
> ATTRS{idVendor}=="[redacted1]" ATTRS{idProduct}=="[redacted2]",
> ENV{ID_MM_DEVICE_IGNORE}="1"
> ATTRS{idVendor}=="[redacted1]" ATTRS{idProduct}=="[redacted3]",
> ENV{ID_MM_DEVICE_IGNORE}="1"
> LABEL="custom_mm_blacklist_internal_modem_end"
>
> but looking at the logs I see:
>
> ModemManager[3751]: [filter] (tty/ttyACM0): port filtered: device is
> blocklisted
> ModemManager[3751]: [filter] (net/enxd[redacted4]) port allowed: net
> device
> ModemManager[3751]: [filter] (net/enxd[redacted4]) port allowed: net
> device
> ModemManager[3751]: [filter] (tty/ttyACM0): port allowed: device also
> exports a net interface
>
> So if ModemManager successfully found the device is blocklisted, why does it
> continue to probe the port?
This is definitely a bug. I've opened
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/833
> What is the recommended mechanism to disable the probing of these devices?
>
> I would prefer to exclude these specific devices, and not have to resort to
> heavy handed solutions that alter the global rules.
>
Your udev rules should have fully blocklisted the device, but they
didn't, sorry for that :/
Let's get this fixed.
--
Aleksander
Re: AT port not attacted with RM520N-GL
Hey Pradeep! > > Good morning. > Can you help to recommend to us which modemmanager to use for updating > from 1.16.6-3? > > I found these two stable releases, which one you recommend given that we are > currently using MM 1.16: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/tags/1.22.0 > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/tags/1.20.6 > Are there any libqmi and libmbim requirements for 1.20.6 ? > (modemmanager - 1.16.6-3 > libqmi - 1.28.6-3 > libmbim - 1.24.8-2) > My suggestion is always to use the latest stable, so 1.22.0. That version will require newer libqmi and libmbim versions, see https://modemmanager.org/docs/libmbim/dependencies/ The recent MM releases also require a switch of the build tools from autotools to meson, see https://modemmanager.org/docs/modemmanager/building/building-meson/ -- Aleksander
Re: No IP address for a successful connection on LTE modem
Hey! On Tue, Feb 13, 2024 at 1:49 PM Garfield Watkins wrote: > > Did you connect the modem using NetworkManager (e.g. using nmcli) or > did you connect the modem using mmcli? > > I see where you are going with this. It seems I expected more of the > interaction between the ModemManager and Network Manager . To answer your > question, no I have only used mmcli. Let me try the process with nmcli. > :) NM only processes the connections that have been started via NM. There's a fundamental reason for that, which is that all the network-specific routing is done at NM level, MM knows nothing about it. In order for NM to know how to route traffic to through the LTE connection, it needs to use its own connection settings. -- Aleksander
Re: AT port not attacted with RM520N-GL
> > Thanks for your reply, I will try out the suggested methods. > And another thing is we are planning to update ModemManager > ,currently we are at 1.16.6-2) and we can go to 1.20 stable versions. > Is there any stable version that you can push into ModemManager sources? > https://www.freedesktop.org/software/ModemManager/ > Please use the signed git tags to retrieve the stable versions, we stopped publishing tarballs some time ago. -- Aleksander
Re: No IP address for a successful connection on LTE modem
Hey, On Tue, Feb 13, 2024 at 1:18 PM Garfield Watkins wrote: > > Bearer 0 is the initial default bearer. > > Bearer 1 is the connected bearer > > Output from mmcli -b 1 is: > > - > General|path: /org/freedesktop/ModemManager1/Bearer/1 > |type: default > - > Status | connected: yes > | suspended: no > | multiplexed: no > | interface: enp0s20f0u2 > | ip timeout: 20 > | profile id: 1 > - > Properties | apn: internet > | roaming: allowed > | ip type: ipv4 > - > IPv4 configuration | method: dhcp > | prefix: 0 > - > Statistics | start date: 2024-02-13T12:08:31Z > |attempts: 1 > > Please note ModemManager is not responsible for running the DHCP > client in the net interface, so if your plugin is reporting "dhcp" IP > method in the connected bearer settings (in your get_ip_config_3gpp() > method), then whoever is the network management layer on top of > ModemManager would be the one in charge of running DHCP client. > > I have NetworkManager running. I was under the assumption that it would > automatically run its dhcp client on the interface. It seems to do this when > I manually issue AT+CGACT=1,1. Its only when running under ModemManager that > nothing seems to happen, in fact I have tried to run dhclient enp0s20f0u2 and > only then do i get an ip address. > Did you connect the modem using NetworkManager (e.g. using nmcli) or did you connect the modem using mmcli? -- Aleksander
Re: No IP address for a successful connection on LTE modem
Hey, On Mon, Feb 12, 2024 at 9:37 AM Garfield Watkins wrote: > > I have created a plugin for an LTE modem. This modem exposes 1 AT command > port (e.g. ttyUSB0) and one ethernet port via usb (cdc_ether). > > When the modem is inserted via USB, the kernel enumerates some serial > ports(ttyUSB0 -> ttyUSB7) and a network interface (enp0s20f0u1) > > The modem establishes a default bearer on network registration and to > establish a data network connection I need to create a pdp context > (AT+CGDCONT) with an APN and thereafter activate it with AT+CGACT=1,1 > > The modem, which is configured in router mode responds by activating its > internal dhcp server causing network managers dhcp client to work its magic > and eventually configure the ethernet port with all the info it needs > (gateways, dns servers, ip address etc). > > > This same process is essentially performed by my plugin and yet no IP address > get assigned to the ethernet adapter exposed by the modem. > > Why could this be happening ? > > My plugin, specifically the bearer interface implements the folloiwing: > > broadband_bearer_class->dial_3gpp = dial_3gpp; > broadband_bearer_class->dial_3gpp_finish = dial_3gpp_finish; > broadband_bearer_class->disconnect_3gpp = disconnect_3gpp; > broadband_bearer_class->disconnect_3gpp_finish = disconnect_3gpp_finish; > broadband_bearer_class->get_ip_config_3gpp = get_ip_config_3gpp; > broadband_bearer_class->get_ip_config_3gpp_finish = get_ip_config_3gpp_finish; Please note ModemManager is not responsible for running the DHCP client in the net interface, so if your plugin is reporting "dhcp" IP method in the connected bearer settings (in your get_ip_config_3gpp() method), then whoever is the network management layer on top of ModemManager would be the one in charge of running DHCP client. What's the output of "mmcli -b 0" (assuming 0 is the connected bearer object) once you perform the modem connection? -- Aleksander
Re: Assistance Needed with SIM Card Issue Causing QMI Operation Failures
> > i'm seeing similar (not necessarily related) problems with an EC21 when using > Telefonica SIM cards (other cards work fine, these work sporadically). It > seems as if those cards have a longer startup time. With the following patch > the cards work most of the time (ModemManager 1.18.6): > --- > src/mm-iface-modem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mm-iface-modem.c b/src/mm-iface-modem.c > index 8bf0893c01a2..be05bf4a7a8b 100644 > --- a/src/mm-iface-modem.c > +++ b/src/mm-iface-modem.c > @@ -420,7 +420,7 @@ mm_iface_modem_abort_invocation_if_state_not_reached > (MMIfaceModem *sel > * are modems on which the SIM takes more than 15s to be ready, luckily, > * they happen to be QMI modems where the SIM's iccid in load_sim_slots > * lets us know that there is a sim */ > -#define MAX_UNLOCK_REQUIRED_RETRIES_NO_SIM 6 > +#define MAX_UNLOCK_REQUIRED_RETRIES_NO_SIM 30 > #define MAX_UNLOCK_REQUIRED_RETRIES_SIM_EXISTS 30 > > /* Time between retries */ > > I have no idea why this patch is working since the EC21 is a QMI modem which, > according to the comment, should not be affected by this... > > If someone with a deeper understanding of ModemManagers internals would like > to look into this i would be happy to offer my support. > There have been several updates in this regard in MM git master, some of them may already be in MM 1.22, but don't know exact details. The main issue with this approach of increasing the number of retries is that for the case where there is no SIM card inserted at all, the modem would go over all the requested retries before it is exposed in DBus, so it would take a long time. Ideally, if we do 6 checks and it fails, we would mark the modem as invalid as we do. But as soon as the SIM card is then properly detected by the device, the device should notify about the change, and in that case we would re-probe the whole device from scratch. If that is not happening with MM git master, please let me know and we'll debug further. Maybe we're not setting up the event handlers properly while in failed state. -- Aleksander
Re: Is it possible to use mmcli with ublox L201 in Debian9
Hey > > I have some old devices that I cannot do OS upgrades, and they're running > Debian9, mmcli 1.6.4. Is it possible to do some sort of manual upgrade so > that it can work with ublox L201? > Yes, it should be possible to use a much newer ModemManager than 1.6.4 in that old box, likely supporting the u-blox TOBY-L2 modems as well. Look at https://modemmanager.org/docs/modemmanager/dependencies/ and check the minimum dependency versions that MM has, and see which is the max MM version you can build with your available glib2/libgudev versions in Debian 9. -- Aleksander
Re: AT port not attacted with RM520N-GL
Hey Pradeep!
>
> We are using RM520N-GL in our SD-WAN edge device in USB mode on M.2 Slot.
> We are facing an issue where AT USB ports(ttyUSB2, ttyUSB3) are not
> enumerated .
> We are using "modemmanager - 1.16.6-2" and also added RM520 blob to "
> /lib/udev/rules.d/77-mm-quectel-port-types.rules" but still the AT port is
> not attached .
> Please advise any changes needed to resolve this issue.
>
> # Quectel RM520
> # # ttyUSB0 (if #0): QCDM/DIAG port
> # # ttyUSB1 (if #1): GPS data port
> # # ttyUSB2 (if #2): AT primary port
> # # ttyUSB3 (if #3): AT secondary port
> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801", ENV{.MM_USBIFNUM}=="00",
> ENV{ID_MM_PORT_TYPE_QCDM}="1"
> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801", ENV{.MM_USBIFNUM}=="01",
> ENV{ID_MM_PORT_TYPE_GPS}="1"
> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801", ENV{.MM_USBIFNUM}=="02",
> ENV{ID_MM_PORT_TYPE_AT_PRIMARY}="1"
> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801", ENV{.MM_USBIFNUM}=="03",
> ENV{ID_MM_PORT_TYPE_AT_SECONDARY}="1"
>
> In debug message there is log about "port is not AT-capable"
> >>
> 2024-01-25T16:45:52.070 DEBUG daemon ModemManager[8350]:
> [ttyUSB3/probe] port is not AT-capable
> 2024-01-25T16:45:52.070 DEBUG daemon ModemManager[8350]:
> [ttyUSB2/probe] port is not AT-capable
>
If the USB ports are exposed by the kernel, but they are not
responsive by the time MM tries to use them, it may be that MM didn't
wait long enough. I know we have updated those timeouts many times in
past releases, and you may be using an older value of the timeout. It
could also be that MM cannot, for some reason, communicate properly
with the device.
You should investigate a bit more:
1) Let it detect the modem without AT ports, wait some minutes, then
restart ModemManager. Does MM use the AT ports in that case? If it
doesn't process them yet, then it's not a timing issue.
2) Try to ignore only one of the TTYs:
Edit 77-mm-quectel-port-types.rules and add:
ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0801",
ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_PORT_IGNORE}="1"
Then reboot the system. Does MM try to probe and process the non-ignored TTY?
--
Aleksander
Netlink failure when attempting to add multiplexed link in MBIM modem
Hey Bjørn, I'm getting some strange reports of failures in the netlink communication when adding new multiplexed links in a MBIM modem, using cdc_mbim. I also have the kernel dmesg but it doesn't give any reference to the error, the only valid thing I have is the MM debug log. Any idea why this may fail? If I'm not mistaken, the actual multiplexed net interface creation is a process done by the kernel alone, without any interaction with the device, so not sure what could be happening. 2024-01-15T06:52:20.192634Z NOTICE ModemManager[4658]: [modem6] state changed (registered -> connecting) 2024-01-15T06:52:20.192901Z DEBUG ModemManager[4658]: [modem6/bearer2] launching multiplexed connection with data port (net/wwan0) 2024-01-15T06:52:20.192912Z DEBUG ModemManager[4658]: [modem6/bearer2] setting up new multiplexed link... 2024-01-15T06:52:20.193219Z DEBUG ModemManager[4658]: Using dynamic session ID 1 2024-01-15T06:52:20.193259Z DEBUG ModemManager[4658]: Using ifname 'mbimmux6.1' and vlan id 1 2024-01-15T06:52:20.193506Z WARNING ModemManager[4658]: [modem6/bearer2] connection attempt #1 failed: failed to create net link for device: failed to add link for device: Could not allocate link: Failed to add link with session id 1: Netlink message with transaction 1 failed: Unknown error -1 2024-01-15T06:52:20.193634Z DEBUG ModemManager[4658]: [modem6/bearer2] cannot set unhandled domain error as connection error: failed to create net link for device: failed to add link for device: Could not allocate link: Failed to add link with session id 1: Netlink message with transaction 1 failed: Unknown error -1 2024-01-15T06:52:20.193684Z NOTICE ModemManager[4658]: [modem6] state changed (connecting -> registered) 2024-01-15T06:52:20.193973Z NOTICE ModemManager[4658]: [modem6/bearer2] connection #1 finished: duration 0s 2024-01-15T06:52:20.193996Z WARNING ModemManager[4658]: [modem6] couldn't connect bearer: failed to create net link for device: failed to add link for device: Could not allocate link: Failed to add link with session id 1: Netlink message with transaction 1 failed: Unknown error -1 -- Aleksander
Re: Can ModemManager connect to multiple PDUs networks?
> > Thank you for your answer. This works, indeed, and it is the information I > was looking for. However, I have a follow-up question: > > When using the multiplex property, a virtual interface called > mbimmux. is created. > > Is it possible to control the interface name and the VLAN ID used for this > interface? This would be useful for having a consistent/simple routing > configuration in the system. For example if the modem is being reset, the > virtual interface name will change as well. Having a predefined name for > the virtual interface might be easier. > > That is not possible right now, but it is a very good idea. -- Aleksander
Re: How to recover from serial device being force closed.
Hey, > In my application, I use ModemManager to connect the modem, and then I rename the network interface to a special name that is required by another part of my system (and change the name back if the modem disconnects). Is it not possible to rename the interface before even MM tries to grab the port? We could support a patch like yours, but it seems overly complicated and may open the door to even more complex interactions, e.g. what if someone comes with the idea of renaming the control port instead of the net port. I'm sure it's technically possible to do all that, but not sure how much benefit it will bring. -- Aleksander
Re: QUECTEL ECM with Modem Manager
Hey, > First of all, i would like to thank you for taking time reading and > answering this. > We are currently using Modem Manager on various project and planned to > move from SIMCOM (qmi) chipset to Quectel for cost reduction. > > We successfully makes Quectel working with ModemManager with PPP. But for > better compatibility with our other services it should be better with ECM. > > Is it possible for modem manager to priorise ECM instead of PPP by using > specific AT commands using plugin ? > And display bearer state such like ppp, qmi, mbim ? > > Is priorizing ECM on PPP via plugin in conform to Modem Manager mindset > and should be released inside Modem Manager? > > Yes, using ECM over PPP would be preferred, definitely. Now, the Quectel plugin in MM doesn't have any custom support for ECM setup, and that would need to be implemented. Being a Quectel modem, have you tried to set it up in QMI or MBIM mode instead of ECM? MM already supports QMI and MBIM so you would not need any additional change in the code to support those modes. If the Quectel modem you're trying to use does not support QMI or MBIM, then updating the Quectel plugin to support ECM would be best. -- Aleksander
Re: Bearer connection disconnect cause
Hey, > > We getting connection disconnect randomly with below log from MM. We do > have a way to recover from it but is there a way to know the cause of > disconnect? Such as whether it is "network initiated disconnection" or > "modem initiated". Any pointers in this regard will be helpful (to find out > the cause of disconnection) > > > [modem0] state changed (connected -> registered) > > [modem0/bearer1] connection #1 finished: duration 129s, tx: 1159 > bytes, rx: 112 bytes > > Please try to run MM with debug logs to get a better idea of why the modem connection stopped working -- Aleksander
Re: qmicli-firmware-update failure on a batch of EM7455
On Wed, Nov 8, 2023 at 9:49 AM Bjørn Mork wrote: > > Amol Lad writes: > > > It seems the failure is occurring at the last chunk (#61). The status > > returned in "134". Please advise if any idea what this error status means? > > > > Bjørn, I saw one of your post in the mailing list regarding > > qmi-firmware-update failure? Any idea what is this error? > > No idea. AFAIR, our knowledge is based on API docs made public in the > stone age. What API docs?! Did I miss those? I recall we reverse-engineered many usb captures from firmware upgrades happening in Windows... :D -- Aleksander
Re: FM350-GL (installed in ThinkPad P1 Gen 5)
On Tue, Nov 7, 2023 at 12:46 AM Thilo-Alexander Ginkel wrote: > > Problem solved. Just submitted a MR [1] for the unlock script. > > Thanks, > Thilo > > [1] > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1091 > > Thanks! You made a lot of people happy, you wouldn't guess. -- Aleksander
Re: EM9191 PCIe with CM4
Hey, > # mmcli -m 0 --simple-connect="apn=,multiplex=requested" > error: couldn't connect the modem: > 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code0: > failed to create net link for device: failed to add link for device: Could > not allocate link: Failed to add link with mux id 1: Netlink message with > transaction 1 failed' > This is strange indeed, looks like the netlink communication with the kernel is failing. Hoping any of the kernel experts in the list can shed some light on this kind of issue. -- Aleksander
Re: ussd does not work
Hey > [19 окт 2023, 00:10:26] [Debug] Asynchronously initiating USSD session... > error: couldn't initiate USSD session: > 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NotSupported: > Operation not supported' > > ussd do not work for me ... > Very likely that your modem fails to support the USSD related AT commands, there is not much we can do if that's the case. But also, it looks like you're using some out-of-tree support for virtual devices in the MTK plugin: > >System | device: /virtual/1 > | drivers: virtual > | plugin: mtk > | primary port: radio/pttycmd2 > |ports: radio/pttycmd2 (at), radio/pttycmd4 > (at), > | radio/pttynoti (at) Please ask whoever gave you that plugin or MM version for support, not in the upstream mailing list, as we have no idea what that plugin is doing. Thanks! -- Aleksander
Re: EM9191 PCIe with CM4
Hey, > I’m using a Sierra EM9191(sdx55) with PCIe on a raspberry CM4. > Until now I had a firmware based on openWRT21.02, for which Aleksander had > tuned the MM1.18.2 and few drivers. > It worked nicely but we bought a new lot of CM4 and I need to upgrade few > files for it to boot (start4.elf and fixup.dat). > Upgrading the gpu-firmware package of the bcm2711 did the trick but it seems > to have a side effect because the modem can’t connect properly anymore. > For every new attempt (through luci) it attach, register and fail to connect, > leaving the modem in a disabled state. > > My first move was to try the ‘official’ new openwrt, with latest update and > better support to my hardware. > I had the same result with openwrt 23.05/MM1.20.6 and openwrt master/MM1.22 > > If I delete my interface in luci, then recreate it, sometimes it connects but > there is no downlink traffic. > > When I try manually to establish the connection, I have this return: > # mmcli -m 0 -e > successfully enabled the modem. > # mmcli -m 0 --simple-connect="apn=" > error: couldn't connect the modem: > 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsupported: Cannot > disable multiplex support' > > I managed to make the MHI driver handle the modem but I’m struggling with MM, > anyone has a clue of what’s going on? > If you need more information or trace, just let me know. > Could you try adding "multiplex=requested" to your --simple-connect call? That "cannot disable multiplex support" error happens when we detect there is a data aggregation protocol configured in the port. Could you post a full MM debug log to try to understand where that comes from? -- Aleksander
IP (v4/v6) connectivity setup in LTE modems
Hey all, I wrote a doc explaining how IPv4/IPv6 connectivity in LTE networks is setup (a very basic case scenario), including different possible interactions between host, modem and network, and focusing on how all these are exposed by ModemManager. It has been very useful for me to understand different IPv6 SLAAC scenarios that we have seen with different modem types, so I'm sure it will also be useful for others. Please take a look and report errors if any! https://modemmanager.org/docs/modemmanager/ip-connectivity-setup-in-lte-modems/ -- Aleksander
ANN: ModemManager 1.22.0 released
Hey hey, This is a new major release of ModemManager, which will be the base for the new 1.22.x stable series (the new "mm-1-22" branch in git). Overview of changes in ModemManager 1.22.0 --- The following notes are directed to package maintainers: * This version now requires: ** libmbim >= 1.30.0 (for the optional MBIM support) ** libqmi >= 1.34.0 (for the optional QMI support) * The GNU autotools (autoconf/automake/libtool) support has been fully removed, this release requires the use of the meson build system. * Build: ** Flag types are now generated in their own files (e.g. 'mm-flags-types.h'). ** A new 'fuzzer' option is available to build LLVM LibFuzzer based unit testers. ** A new 'builtin_plugins' option is available to integrate all built plugins within the ModemManager daemon binary. This makes the daemon load much quicker as it doesn't dynamically load the plugins on runtime. The most important features and changes in this release are the following: * A new "MSG" (message) log verbosity level is introduced, which is also the new default one if none explicitly defined. This level takes the place of the old "INFO" level, as a level including the most important messages that should be logged without needing to be warnings or errors. The new "INFO" level is more verbose than "MSG" but less verbose than "DBG", and may be useful as default in systems where active debugging of WWAN related issues is required. E.g. all user operations triggered via DBus method calls are logged in "INFO" level. * Introduced the concept of "personal information" which should by default not be included in log messages. Enabling personal information in logs requires to run the daemon with the '--log-personal-info' option. This feature is mostly implemented for QMI and MBIM specific logs, but hasn't yet been included in generic daemon logs or when using the AT protocol. Changes and fixes related to this feature will be cherry-picked and included in the future stable branch updates. * API: ** Added new 'Modem.Physdev' property to unconditionally publish the physical modem device path. ** Updated the 'Modem.GetCellInfo()' method to include serving cell type and bandwidth information in LTE and 5GNR cells. ** New 'Modem3gpp.SetCarrierLock()' method to send the list of carrier network information to the modem. ** The 'SetLogging()' method allows a new "MSG" log level. * Core: ** The codebase has been updated to use GTask in all operations and there are no longer any deprecated methods from GLib being used. ** The port probing logic is now able to guess port type hints during runtime, e.g. based on the kernel driver in use or the wwan subsystem port 'type' attributes. ** Default probing and wait times have been increased, in order to cope with slow kernel events reporting new port additions. * Modem interface: ** Updated the logic loading unlock retries to allow restarting the check count based on the state reported by the device (e.g. if the SIM is detected but not fully ready during the last expected check, a new set of check retries is allowed). * 3GPP interface: ** Added support for packet service state updates via unsolicited indications. ** Added support for ignoring registration and packet service state updates if the interface has already been disabled. ** Updated initialization sequence to allow showing IMEI even if the device is locked. ** Logged available profiles in "INFO" level whenever they are listed. * Simple interface: ** Logged user provided settings during a connect attempt in "INFO" level. ** Added support to abort an ongoing connect operation at any step in the state machine, e.g. if the modem is going to be disabled. ** Added support to explicitly request attaching to packet service during the connection attempt. * Signal interface: ** Added logic to rate-limit printing the extended signal information with "INFO" level, even if the actual refresh rate is higher. * New udev tags: ** The 'ID_MM_REQUIRED' port-specific udev tag allows users to specify that the modem must be able to succesfully probe and use the given control port. ** The 'ID_MM_MAX_MULTIPLEXED_LINKS' udev tag allows user to specify the maximum amount of multiplexed links the modem supports. This tag may be set to 0 to fully disable multiplexing support in the device. * mmcli: ** New '--messaging-create-sms-with-text' action to create a text SMS from the contents of a given file. ** New '--3gpp-set-carrier-lock' action to send the carrier lock data to the device. ** Updated '--modem' to always allow using the modem physdev path for lookup. * SMS: ** Improved the parsing of 3GPP and CDMA SMS parts, fixing multiple different errors that lead to unexpected crashes on SMS reception. * MBIM: ** Updated device model loading logic to use
Re: Quectel RM520N-GL QMI InvalidOperation starting network
Hey Luke > > I'm trying to use a Quectel modem (RM520N-GL) with ModemManager, and I > had it working previously except with occasional dropouts. While > debugging some errant problems where the modem would lose data > connectivity and start reporting no SIM card I flipped it to ECM mode > and messed with it (which, of course, had the same problem). Having > flipped it back to QMI I now can't get it to create a data connection > at all (to EE UK), with the connection attempt eventually terminating > with: > > $ mmcli -m 0 > --- > General |path: /org/freedesktop/ModemManager1/Modem/0 >| device id: 15a72cd830352aaab3[...elided...] > --- > Hardware |manufacturer: Quectel >| model: RM520N-GL >| firmware revision: RM520NGLAAR01A05M4G >| carrier config: Commercial-EE >| carrier config revision: 0A01220B >|h/w revision: 2 >| supported: gsm-umts, lte, 5gnr >| current: gsm-umts, lte, 5gnr >|equipment id: 86837105[...elided...] > --- > System | device: > /sys/devices/platform/cp0/cp0:config-space@f200/f250.usb/usb4/4-1/4-1.4 >| drivers: option, qmi_wwan >| plugin: quectel >|primary port: cdc-wdm0 >| ports: cdc-wdm0 (qmi), ttyUSB2 (at), > ttyUSB3 (at), wwu1u4i4 (net) > --- > Numbers | own: 07904[...elided...] > --- > Status |lock: sim-pin2 >| unlock retries: sim-pin (3), sim-puk (10), > sim-pin2 (3), sim-puk2 (10) >| state: registered >| power state: on >| access tech: lte, 5gnr >| signal quality: 88% (recent) > --- > Modes| supported: allowed: 3g; preferred: none >| allowed: 4g; preferred: none >| allowed: 3g, 4g; preferred: 4g >| allowed: 3g, 4g; preferred: 3g >| allowed: 5g; preferred: none >| allowed: 4g, 5g; preferred: 5g >| allowed: 4g, 5g; preferred: 4g >| allowed: 3g, 5g; preferred: 5g >| allowed: 3g, 5g; preferred: 3g >| allowed: 3g, 4g, 5g; preferred: 5g >| allowed: 3g, 4g, 5g; preferred: 4g >| allowed: 3g, 4g, 5g; preferred: 3g >| current: allowed: 3g, 4g, 5g; preferred: 4g > --- > Bands| supported: utran-1, utran-4, utran-6, > utran-5, utran-8, utran-2, >| eutran-1, eutran-2, eutran-3, > eutran-4, eutran-5, eutran-7, eutran-8, >| eutran-12, eutran-13, eutran-14, > eutran-17, eutran-18, eutran-19, >| eutran-20, eutran-25, eutran-26, > eutran-28, eutran-29, eutran-30, >| eutran-32, eutran-34, eutran-38, > eutran-39, eutran-40, eutran-41, >| eutran-42, eutran-43, eutran-46, > eutran-48, eutran-66, eutran-71, >| utran-19, ngran-1, ngran-2, > ngran-3, ngran-5, ngran-7, ngran-8, >| ngran-12, ngran-13, ngran-14, > ngran-18, ngran-20, ngran-25, ngran-26, >| ngran-28, ngran-29, ngran-30, > ngran-38, ngran-40, ngran-41, ngran-48, >| ngran-66, ngran-70, ngran-71, > ngran-75, ngran-76, ngran-77, ngran-78, >| ngran-79 >| current: utran-1, utran-4, utran-5, > utran-8, utran-2, eutran-1, >| eutran-2, eutran-3, eutran-4, > eutran-5, eutran-7, eutran-8, >| eutran-12, eutran-13, eutran-14, > eutran-17, eutran-18, eutran-19, >| eutran-20, eutran-25, eutran-26, > eutran-28, eutran-29, eutran-30, >| eutran-32, eutran-34, eutran-38, > eutran-39, eutran-40, eutran-41, >| eutran-42, eutran-43, eutran-46, > eutran-48, eutran-66, eutran-71, >| utran-19, ngran-1, ngran-2, >
ANN: ModemManager 1.21.900 (1.22-rc1) released
Hey hey, This is the first release candidate for the next 1.22 release. Please use the signed git tag '1.22-rc1' to refer to the sources of this release. The NEWS file includes the list of all the changes. Additional notes for packagers: * This version now requires: ** libmbim >= 1.29.900 (for the optional MBIM support). Will be 1.30.0 on the final release. ** libqmi >= 1.33.900 (for the optional QMI support). Will be 1.34.0 on the final release. * The GNU autotools (autoconf/automake/libtool) support has been fully removed, this release requires the use of the meson build system. * Build: ** Flag types are now generated in their own files (e.g. 'mm-flags-types.h'). ** A new 'fuzzer' option is available to build LLVM LibFuzzer based unit testers. ** A new 'builtin_plugins' option is available to integrate all built plugins within the ModemManager daemon binary. This makes the daemon load much quicker as it doesn't dynamically load the plugins on runtime. -- About ModemManager: https://www.freedesktop.org/wiki/Software/ModemManager Download and verify: $ git clone --depth 1 --branch 1.22-rc1 https://gitlab.freedesktop.org/mobile-broadband/ModemManager.git $ cd ModemManager $ git tag --verify 1.22-rc1 APIs and manpages here: https://www.freedesktop.org/software/ModemManager/doc/1.22.0/ModemManager https://www.freedesktop.org/software/ModemManager/doc/1.22.0/libmm-glib https://www.freedesktop.org/software/ModemManager/man/1.22.0/ModemManager.8.html https://www.freedesktop.org/software/ModemManager/man/1.22.0/mmcli.1.html Please report bugs either to: modemmanager-devel@lists.freedesktop.org Or to gitlab: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues -- Aleksander OpenPGP_0xAECE0239C6606AD5.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: modem is unusable when removing and putting back sim card
Hey > I am working with ModemManager with qmi-proxy and I have a weird behavior > when I am using ModemManager with the log-level set to DEBUG like this > "ModemManager --log-level=DEBUG &" > everything is working fine but when I use it normally or set the log-level to > anything else except debug I have "modem is unusable" > Here are the logs : > [modem2] cleaning up port 'net/mhi_hwip0'... > [modem2] cleaning up port 'unknown/wwan0qcdm0'... > [modem2] cleaning up port 'tty/ttyUSB2'... > [modem2] cleaning up port 'wwan/wwan0qmi0'... > [modem2] cleaning up port 'unknown/wwan0mbim0'... > [ttyUSB2/at] forced to close port > [modem2] (quectel) check SIM swap completed > [modem2] completely disposed > [device SG520TM] Reprobing modem... > [device SG520TM] creating modem with plugin 'quectel' and '5' ports > [plugin/quectel] (quectel) QMI-powered Quectel modem found... > [wwan0qmi0/qmi] timeout monitoring enabled in QMI port > [modem3] port 'wwan/wwan0qmi0' grabbed > [plugin/quectel] port wwan0qcdm0 is blacklisted > [modem3] port 'wwan/wwan0qcdm0' grabbed > [plugin/quectel] port wwan0mbim0 is blacklisted > [modem3] port 'wwan/wwan0mbim0' grabbed > [modem3] port 'net/mhi_hwip0' grabbed > [ttyUSB2/at] timeout monitoring enabled in AT port > [ttyUSB2/at] AT port flagged as primary > [modem3] port 'tty/ttyUSB2' grabbed > [modem3] tty/ttyUSB2 at (primary) > [modem3] tty/ttyUSB2 at (data primary) > [modem3] net/mhi_hwip0 net (data) > [modem3] wwan/wwan0qmi0 qmi > [modem3] at data ports available but ignored > [wwan0qmi0/qmi] endpoint info updated: type 'pcie', interface number > '0' > [modem3] running QMI port 'wwan0qmi0' reset with data interface > 'mhi_hwip0' > [device SG520TM] modem recreated > [wwan0qmi0/qmi] bringing down data interface 'mhi_hwip0' > [modem3/mhi_hwip0/net] interface index: 2 > [wwan0qmi0/qmi] deleting all links in data interface 'mhi_hwip0' > [wwan0qmi0/qmi] Opening QMI device... > [wwan0qmi0/qmi] Checking if QMI device already opening... > [wwan0qmi0/qmi] Checking if QMI device already open... > [wwan0qmi0/qmi] Creating QMI device... > [wwan0qmi0/qmi] Opening device with flags: version-info, proxy... > [/dev/wwan0qmi0] opening device with flags 'version-info, proxy'... > [/dev/wwan0qmi0] created endpoint > [/dev/wwan0qmi0] sent message... > << RAW: > << length = 29 > << data = 01:1C:00:00:00:00:00:01:00:FF:11:00... > > [/dev/wwan0qmi0] sent generic request (translated)... > << QMUX: > << length = 28 > << flags = 0x00 > << service = "ctl" > << client = 0 > << QMI: > << flags = "none" > << transaction = 1 > << tlv_length = 17 > << message = "Internal Proxy Open" (0xFF00) > << TLV: > << type = "Device Path" (0x01) > << length = 14 > << value = 2F:64:65:76:2F:77:77:61:6E:30:71:6D:69:30 > << translated = /dev/wwan0qmi0 > > [/dev/wwan0qmi0] number of consecutive timeouts: 1 > [/dev/wwan0qmi0] transaction 0xf aborted, but message is not abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 2 > [/dev/wwan0qmi0] transaction 0x10 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 3 > [/dev/wwan0qmi0] transaction 0x11 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 4 > [/dev/wwan0qmi0] transaction 0x12 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 5 > [/dev/wwan0qmi0] transaction 0x13 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 6 > [/dev/wwan0qmi0] transaction 0x14 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 7 > [/dev/wwan0qmi0] transaction 0x15 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 8 > [/dev/wwan0qmi0] transaction 0x16 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 9 > [/dev/wwan0qmi0] transaction 0x17 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 10 > [/dev/wwan0qmi0] transaction 0x18 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 1 > [/dev/wwan0qmi0] transaction 0x1 aborted, but message is not abortable > [wwan0qmi0/qmi] QMI port open operation failed: Transaction timed out > [modem3] couldn't open QMI port with data format update: Transaction > timed out > [wwan0qmi0/qmi] Opening QMI device... > [wwan0qmi0/qmi] Checking if QMI device already opening... > [wwan0qmi0/qmi] Checking if QMI device already open... > [wwan0qmi0/qmi] Creating QMI device... > [wwan0qmi0/qmi] Opening device with flags: version-info, proxy... > [/dev/wwan0qmi0] opening device with flags 'version-info, proxy'... > [/dev/wwan0qmi0] created endpoint > [/dev/wwan0qmi0] sent message... > << RAW: > <<
Re: FM350-GL (installed in ThinkPad P1 Gen 5)
On Wed, Sep 13, 2023 at 12:54 PM Thilo-Alexander Ginkel wrote: > > On Tue, Sep 12, 2023 at 1:31 PM Bjørn Mork wrote: >> >> > Turns out the challenge needs to be requested via --set-fcc-lock=0,0. >> >> Right. Makes sense. >> >> > Still, I can't get a valid unlock. >> >> And those challenge input values are correct? The firware isn't >> expecting something other than 0,0? > > > I patched the Linux kernel's WWAN driver to add logging of the data sent > to/from the modem and as it turns out the MBIM code path isn't even used by > the official tool (although both the firmware and the unlock tool implement > it). Instead AT commands are being used. > > Will this work for ModemManeger's firmware unlock? So far all scripts I have > seen seem to rely on the MBIM device. > We can make this work if needed, yes. The main issue is that we don't have an "AT proxy" as we do with QMI or MBIM, so it would require some sync with MM to ensure we're not touching the AT port at the same time. -- Aleksander
Re: T-Mobile Contributions
> > I'm excited to announce that T-Mobile US is now using > ModemManager/libMBIM/libQMI > for our 5G Fixed Wireless products [https://www.t-mobile.com/home-internet]. > We > are currently the largest FWA ISP in the world with well over 3 Million > subscribers, i.e., lots of ModemManager users! We did this via an > architectural > contribution in partnership with the RDK community, a popular STB/Router Linux > distro running on over 100 Million devices. > > MM is now supported in RDK via a FOSS MM connection manager, CellularManager > [https://code.rdkcentral.com/r/plugins/gitiles/collaboration/rdkb/components/ > opensource/ccsp/RdkCellularManager-MM/+/refs/heads/main] > (need to signup for a free login), and is being worked on by dozens of major > OEMs > & ISPs. If anyone wants to provide feedback or reviews, please let me know. > > We're working hard to realize the full potential of this community by > providing > quality merge requests, via our partners & RDK, and guiding modem makers > towards > standards like QMI/MBIM. Please keep an eye out for us and our partners on the > ML & Gitlab! > Excellent news Matthew! I'm really happy this integration was possible :) -- Aleksander
Re: T-Mobile Contributions
> > I'm excited to announce that T-Mobile US is now using > > ModemManager/libMBIM/libQMI > > for our 5G Fixed Wireless products > > [https://www.t-mobile.com/home-internet]. We > > are currently the largest FWA ISP in the world with well over 3 > > Million > > subscribers, i.e., lots of ModemManager users! We did this via an > > architectural > > contribution in partnership with the RDK community, a popular > > STB/Router Linux > > distro running on over 100 Million devices. > > > > MM is now supported in RDK via a FOSS MM connection manager, > > CellularManager > > [ > > https://code.rdkcentral.com/r/plugins/gitiles/collaboration/rdkb/compo > > nents/ > > opensource/ccsp/RdkCellularManager-MM/+/refs/heads/main] > > (need to signup for a free login), and is being worked on by dozens > > of major OEMs > > & ISPs. If anyone wants to provide feedback or reviews, please let me > > know. > > > > We're working hard to realize the full potential of this community by > > providing > > quality merge requests, via our partners & RDK, and guiding modem > > makers towards > > standards like QMI/MBIM. Please keep an eye out for us and our > > partners on the > > ML & Gitlab! > > That's awesome! Never imagined the kind of reach MM has achieved when > the project got started long long ago... > We're everywhere! Flying drones, airplanes, laptops, cars, phones, and now home routers as well :D -- Aleksander
Re: May I commit binary files into MM project?
Hey > I have a concern about can we commit binary files into > /data/dispatcher-fcc-unlock folder? All the FCC unlock scripts/programs shipped by ModemManager are GPLv2+. If you can distribute your program under the GPLv2+, we could set it up to build from source along with the ModemManager project. If you want to dump a proprietary precompiled binary in the fcc-unlock folder, the answer is "no" :) Cheers! -- Aleksander
Re: ublox SARA does not connect
Hey > So its been a few months, and now when we install the product in US, trying > to connect to Verizon and tmobile, I face problems again. > Modem is ublox sara r5, which works through serial port AT commands only. > The modem seems to be connected, when issuing AT+CGDCONT , but modem manager > +network manager do not go ahead to create a connection > Attached logs > The modem is indeed registered as we can see the initial EPS bearer IP address for the vzwadmin APN, but for some reason MM doesn't know about that. I can see MM trying +CREG? and +CGREG? but they both seem to return the reg state as idle. Could you run +CEREG? manually in the AT port to see what it returns? The modem is detected as a 1-port AT generic modem, and none of the capability queries we do end up telling us it may be 4G capable (which is why we don't try +CEREG to check) ModemManager[573]: [1692200059.641466] [device /sys/devices/platform/soc@0/3080.bus/3086.serial] creating modem with plugin 'generic' and '1' ports ... ModemManager[573]: [1692200059.704189] [modem0/ttymxc0/at] --> 'AT+WS46=?' ModemManager[573]: [1692200059.716311] [modem0/ttymxc0/at] <-- '+CME ERROR: 100' -- Aleksander
Re: Modems disconnecting when signal level is low
Hey Melisa, > I am currently trying to use two SIMCOM SIM8300G-M2 5G modems to test > cellular performance (coverage, latency, throughput) from two different > operators in a rural area. I have been experiencing some stability issues > with the modem connections. It seems that it is related to the low signal > level observed in the area where I am measuring. Whenever the signal level is > low, or there is no coverage, the network interface is deleted, the modem > disappears from mmcli list, and it reattaches automatically after a bit, when > the signal level improves. This causes long (or at least longer than I would > wish) interruptions in my tests. I include some logs below as an example of > what I see whenever this occurs. > This is a clear indication of the modem crashing by itself :/ Maybe the firmware is not stable enough under low signal conditions, or something like that? The only thing you can try to solve this is to contact the manufacturer and go through the support process, e.g. providing them with QXDM log traces to analyze. You could also try to upgrade to the newest firmware they have published. -- Aleksander
Re: Disabling 2G and null-ciphered connections
Hey, On Sun, Aug 13, 2023 at 9:06 PM Tom Isaacson wrote: > > I just came across this article: > https://security.googleblog.com/2023/08/android-14-introduces-first-of-its-kind.html > > When I do "mmcli --modem=0" I can see the modes: > Modes| supported: allowed: 2g; preferred: none >| allowed: 3g; preferred: none >| allowed: 4g; preferred: none >| allowed: 2g, 3g; preferred: 3g >| allowed: 2g, 3g; preferred: 2g >| allowed: 2g, 4g; preferred: 4g >| allowed: 2g, 4g; preferred: 2g >| allowed: 3g, 4g; preferred: 4g >| allowed: 3g, 4g; preferred: 3g >| allowed: 2g, 3g, 4g; preferred: 4g >| allowed: 2g, 3g, 4g; preferred: 3g >| allowed: 2g, 3g, 4g; preferred: 2g >|current: allowed: 2g, 3g, 4g; preferred: 4g > > But I can't figure out how to change them to disable 2G. Can I do this > via a NetworkManager profile? > They cannot be disabled with a NM profile, AFAIK. You can do it with mmcli e.g. mmcli -m a --set-allowed-modes="3g|4g" --set-preferred-mode=4g > What about disabling support for null-ciphered connections? Is that supported? > I don't think there's any generic modem control command that allows doing this, although I may be mistaken. Maybe QMI has something, or vendor-specific AT commands. My impression though is that this setting may be strictly configured in the carrier settings in the modem, if carrier settings are being applied. -- Aleksander
Re: Modem stopped working out of the blue
Hey Martin! On Wed, Jul 19, 2023 at 12:47 AM Martin wrote: > > On 2023-07-18 21:10, Martin wrote: > > my modem Please remind us which one :) > used to work until recently, but suddenly (and without any > > software update, at least intentionally), I get: > > Maybe I've been bitten by an autoupgrade mechanism on that system. > modemmanager, libqmi and other packages *have* been upgraded, e.g.: > > modemmanager from 1.14.12-0.2 to 1.20.0-1~bpo11+1 > libqmi from 1.26.10-0.1 to 1.32.0-1~bpo11+1 > > Downgrading to the older versions solved the problem immediately. > I believe this issue was fixed in https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/6006dd1d6347d7db449f523387b4b5fb96649531 It was cherry picked as 69bc9a67a3b77f4a4b6f4cebf6b4bfb2f614d680 to the mm-1-20 branch, and integrated in MM 1.20.6. If you're up to it, please let me know if 1.20.6 solved the issue. -- Aleksander
Re: ModemManager 1.20.6 crashes when using Quectel EC25
> > I just wanted to confirm that I tested the fix from > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1037, > and that it works as expected. > Thanks for letting us know! -- Aleksander
Re: Add script handling on modem detection
> >> I am using the modemmanager on openwrt (master). > >> While playing around, I noticed that it might be useful to trigger > >> an event after the modemmanager has detected a modem. > >> We already use '/usr/lib/ModemManager/connection.d' one a successful > >> connection. > > > > > > There's already such interface, but it is not one provided by > > ModemManager, but ModemManager re-uses one from Freedesktop. You can > > watch for new modems by using the Freedesktop ObjectManager: > > > > https://www.freedesktop.org/software/ModemManager/api/latest/ref-dbus-standard-interfaces-objectmanager.html > > > > > Thanks for the hint. I'll have a look at it right away. > I believe Florian is asking for a "dispatcher script" to be called once we detect a new modem and before MM probes it, right? similar to e.g. the dispatcher scripts we run when a bearer gets connected. I may be mistaken though -- Aleksander
Re: ModemManager 1.20.6 crashes when using Quectel EC25
Hey > > Thank you very much for your answer and for the fix. Are you intending to > merge this fix in the mm-1-20 branch? > Yes. I should prepare a new set of stable updates soon. -- Aleksander
Re: mbim cli - Telit LN920A connection process take more than 5 minutes
Hey Borja! > > > I am reaching out to discuss a critical situation we are facing with the > LN920A module fw version M0L.010002 and mbimcli tool. > > > > We have encountered connectivity problems with Telit LN920A module when it is > connected to a MNO in Japan. The connection process takes more than 5 > minutes, which is significantly longer than expected. > > Please find enclosed the logs of the tests performed by the customer in their > device using mbimcli (Customer-Testmbimb1.22). > > We have performed tests using a PPP connection in the device of the customer, > and the results have shown that the registration process is fast and > efficient. We have attached the PPP log files (PPP_logs) for your reference. > > > > Additionally, we have conducted tests with Telit Evaluation Kit in different > location using mbimcli version 1.24, and the results have been successful. > The connection process proceeded smoothly without any delays or issues. This > further indicates that the problem may be specific to the customer's network > environment or configuration. (Telit-Test-mbim1.24.24.log) > > > > We appreciate your assistance in helping us identify the root cause of the > prolonged connection time issue and finding a resolution. Please let us know > if you require any further information or if there are any specific tests or > diagnostics that you would like us to perform. > > Looks like the tool is configuring the PDP context #1 explicitly. This setting is taken as the initial EPS bearer settings the modem will use during registration (i.e. attach APN). 0206 000247.019 P27912[Thread3G_0] - SendReceiveATCommand OK [AT+CGDCONT=1,"IP","mmtmobile.jp"] - [OK] 0206 000247.019 P27912[Thread3G_0] - Thread3G: APN:[mmtmobile.jp] successfully configured! And then launching the connection attempt via mbimcli: 0206 000333.774 P27912[Thread3G_0] - CIkusNetApp::ExecExternalProcess: Executing cdc_dev="/dev/$(ls $(realpath /sys/class/net/wwan1)/../../usbmisc/)"; mbimcli -d $cdc_dev --connect=apn='mmtmobile.jp',session-id=0,username='nipponsim@dhacorp',password='dhacorp',auth='CHAP' --no-close --no-open=4... error: operation failed: Failure The settings in the MBIM connection attempt differ from the ones in the attach settings. The APN is the same, but the MBIM attempt has user/pass, which were not configured via AT commands. Given that the settings mismatch, it is very likely that the MBIM connection attempt is launching a new PDP context activation, instead of reusing the one performed during the attach. If this takes a very long time to complete, it could also be because the modem supports only one single active PDN connection, so when you launch the new MBIM connection attempt with different settings, the modem may actually be unregistering from the network and trying to register again with the new settings (modems without the single PDN connection may not be affected by this flow). In order to solve this, you can try several things, the purpose of all of them is to ensure the attach and connect settings are equal. 1) Not only configure the APN with +CGDCONT, but also the user/pass with AT#PDPAUTH=1,2,... This should make the settings match when the MBIM connection is launched. 2) Use MBIM also to configure the lte attach settings, but I've just realized there is no mbimcli support for this yet, only to query (--ms-query-lte-attach-configuration). We would need to update mbimcli to support this. ModemManager does support setting the lte attach settings via MBIM. Trying to use AT for some things and MBIM for others, as in this case, could cause weird things as you're seeing :/ -- Aleksander
Re: ModemManager 1.20.6 crashes when using Quectel EC25
Hey, > I have an intel based platform with a m.2 Quectel EC25. I create images using > a Yocto project. When using ModemManger 1.18.x everything looks good. > However, ModemManager 1.20.6 crashes. If I use a different brand modem, > again, it is working fine. > > Is this a known issue? Or can you suggest a solution? > Should be fixed here https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1037 -- Aleksander
Re: ModemManager - Access Technology vs ModemCapability
Hey, > > The device I am using has a Cinterion® EXS82-W built-in and I am noticing > some weird behavior when it comes to Access Technologies and > ModemCapatibiliy, IMHO it doesn't make sense, but I guess I am wrong > somewhere and would like to know where. > > Reading the AccessTechnologies property > > busctl get-property org.freedesktop.ModemManager1 > /org/freedesktop/ModemManager1/Modem/0 org.freedesktop.ModemManager1.Modem > AccessTechnologies > u 16384 > > The value 16384 should correspond to MM_MODEM_ACCESS_TECHNOLOGY_LTE. > > Reading the SupportedCapabilities property > > busctl get-property org.freedesktop.ModemManager1 > /org/freedesktop/ModemManager1/Modem/0 org.freedesktop.ModemManager1.Modem > SupportedCapabilities > au 1 4 > > The value should correspond to MM_MODEM_CAPABILITY_GSM_UMTS. > > Question > > How can it be that my modem supports only GSM/UMTS from the general access > technology families, but at the same time it is using the LTE technology when > registered with or connected to a network? > This is definitely a bug when reading supported capabilities. Could you open a new bug in gitlab and attach MM debug log to see what's happening? See * https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/new * https://modemmanager.org/docs/modemmanager/debugging/ -- Aleksander
Re: unable to reconnect to "MM_MODEM_STATE_REGISTERED" status modem until it's reset
Hey, > > We are using ModemManager 1.12.12 library in one of our projects and we are > getting MM_MODEM_STATE_REGISTERED status when polling for Modem status with > mm_modem_get_state function. > > > > Then we try to connect again by using mm_modem_simple_connect_sync function > to get the bearer, and then mm_bearer_connect_sync with that bearer, which > gets all bearer parameters, > > > > But modem still in MM_MODEM_STATE_REGISTERED status after that. > > > > Then we try again and finally restart the modem device and finally achieve to > reconnect to modem. > > > > In some other situations, this procedure reconnects at first try, but we > don’t know why exactly modem returns MM_MODEM_STATE_REGISTERED status itself. > > > > Our system in boarded on a vehicle which is in moving around, so we are > thinking it could be a matter of signal loss, but mmcli tool doesn’t show low > signal values. It shows modem in “registered” stated though when this happens. > > > > We are able to reconnect by “simple disconnect” the modem when it gets in > “registered” state and before doing the reconnection procedure described > above, but I seriously doubt this is the correct way to handle it. > > > > Is there any known/solved issue about this “registered” modem state relating > to this version of the library? > > > > If not… any ideas about properly handling it? > This vaguely reminds me to some issue years ago, but my memory is not that good. MM 1.12 is extremely old and we have fixed and improved the whole stack a lot in the next releases. -- Aleksander
Re: segmentation fault when calling mm_object_get_modem
Hey Héctor,
> We are using ModemManager 1.18.8 library and sometimes we got segmentation
> fault when calling mm_object_get_modem function. It happens from time to
> time, no clues about circumstances, as our code is continuously inquiring
> for modem object in this function:
>
>
>
> MMModemPtr ModemManagerFacade::getModemPtr(const std::string )
>
> {
>
> MMObject *object = getObject(imei);
>
> if (object == nullptr) {
>
> return MMModemPtr(nullptr, _object_unref);
>
> }
>
>
>
> return MMModemPtr(mm_object_get_modem(object), _object_unref);
>
> }
>
>
>
> It returns a MMModemPtr type, which is a unique pointer:
>
> using MMModemPtr = std::unique_ptr;///<
> MMModem Unique pointer with custom deleter
>
>
>
> and it’s checked every time that function is called as in:
>
> MMModemPtr modem = getModemPtr(imei);
>
> if (modem == nullptr) {
>
> return DPY_UNAVAILABLE;
>
> }
>
>
>
> MMobject is stored in a map
>
> std::map mImeiToObjectMap;
>
>
>
> and obtained in
>
> MMObject* ModemManagerFacade::getObject(std::string imei)
>
> {
>
> /* Some previous checkings …
>
> …and*/
>
> auto it = mImeiToObjectMap.find(imei);
>
> if (it == mImeiToObjectMap.end()) {
>
> return nullptr;
>
> }
>
> return (it->second);
>
> }
>
>
>
> But I don’t think MMobject pointer is the problem as it’s checked inside
> mm_object_get_modem function:
>
> MMModem *
>
> mm_object_get_modem (MMObject *self)
>
> {
>
> MMModem *modem;
>
>
>
> g_return_val_if_fail (MM_IS_OBJECT (MM_GDBUS_OBJECT (self)), NULL);
>
>
>
> modem = (MMModem *)mm_gdbus_object_get_modem (MM_GDBUS_OBJECT (self));
>
> g_warn_if_fail (MM_IS_MODEM (modem));
>
> return modem;
>
> }
>
>
>
> and the backtrace shows that the program terminates after calling
> mm_gdbus_object_get_modem
>
>
>
> Program terminated with signal SIGSEGV, Segmentation fault.
>
> #0 0xad048ab8 in g_hash_table_lookup () from
> /usr/lib/libglib-2.0.so.0
>
> [Current thread is 1 (LWP 10802)]
>
> (gdb) bt
>
> #0 0xad048ab8 in g_hash_table_lookup () from
> /usr/lib/libglib-2.0.so.0
>
> #1 0xad2f5824 in ?? () from /usr/lib/libgio-2.0.so.0
>
#2 0xad4629dc in mm_gdbus_object_get_modem () from
> /usr/lib/libmm-glib.so.0
>
> #3 0xad422e2c in mm_object_get_modem () from
> /usr/lib/libmm-glib.so.0
>
> #4 0xbff73124 in
> ModemManagerFacade::getModemPtr(std::__cxx11::basic_string std::char_traits, std::allocator > const&) ()
>
> #5 0xbff745f0 in
> ModemManagerFacade::getDominantTechnologySignalQuality(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> dpyModem::SignalQuality&, bool&) ()
>
> #6 0xbff5d97c in ModemManagerDevice::update_signalQuality() ()
>
> #7 0xbffbb050 in ModemSupervisor::updateModemParameters() ()
>
> #8 0xbffbbc44 in
> ModemSupervisor::checkModemStatus(boost::system::error_code const&,
> dpyModem::ModemState) ()
>
> #9 0xbffbcfe8 in
> boost::asio::detail::wait_handler boost::_mfi::mf2 dpyModem::ModemState>,
> boost::_bi::list3, boost::arg<1> (*)(),
> boost::_bi::value > > >::do_complete(void*,
> boost::asio::detail::scheduler_operation*, boost::system::error_code
> const&, unsigned long) ()
>
> #10 0xbff0de38 in
> boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&,
> boost::asio::detail::scheduler_thread_info&, boost::system::error_code
> const&) ()
>
> #11 0xbffe704c in
> ModemService::operator()(boost::application::basic_context&) ()
>
> #12 0xbffd019c in int
> boost::application::launch boost::application::auto_handler,
> boost::application::basic_context>(boost::application::auto_handler&,
> boost::application::basic_context&, boost::system::error_code&) ()
>
> #13 0xbfedc9a0 in main ()
>
>
>
> Any ideas about why this can be happening? Has it ever been seen before?
>
i'd bet this is some memory corruption happening somewhere. Is the issue
easily reproducible? maybe you can prepare a small reproducer program that
triggers this issue for us to analyze? Otherwise, I suggest you try to run
under valgrind to see if you get any memory related issues reported there.
The only thing I can say about this issue is that I don't recall anything
similar to this reported lately in the past years. libmm-glib is used by
multiple other projects, so there's a high chance that the issue is indeed
a memory corruption somewhere in your project. Maybe a double free, or a
use-after-free, or something like that.
Also please note that the g_return_if_fail() calls may be disabled in the
build! you should ensure these are being used in your build before assuming
they're being called.
Sorry I cannot help more :/
--
Aleksander
Re: [Quectel EM160R-GL] Various commands over mbim fail with 'Invalid transition'
> >> After upgrading an EM160R-GL modem via QFireHose from firmware version > >> EM160RGLAUR02A07M4G to version EM160RGLAUR02A07M4G, almost all functions > >> fail with ‘Invalid transition’. The modem power state is listed as "power > >> state: low” via mmcli. On the former firmware version everything was > >> working fine. > >> > >> This is currently happening with modemmanager 1.18.8 using mbim via the > >> qmi_wwan driver on openwrt with linux 4.4.60 and libmbim 1.28.4 > >> > >> I tried manually enabling it (in case it was FCC locked) via mbimcli > >> --device-open-proxy --device="/dev/cdc-wdm0" --quectel-set-radio-state=on, > >> but this also had no effect. > >> > >> What additional steps would I need to take to debug this? > > > > Very likely that they may have changed the FCC unlock algorithm in the > > newer firmware version :/ > > > > -- > > Aleksander > > > The same firmware version has worked on other modems of the same model. This > appears to be a problem with a specific batch of modems(?). Is this something > that is likely to occur? > > Also in my testing the modem is not FCC locked, its stuck in factory-test > mode, as verified by AT+QRFTESTMODE?. Attempting to leave factory-test mode > with AT+QRFTESTMODE=0 doesn’t seem to have any effect Ah, that could also be it, yes. Maybe ask for help in the Quectel forum, they may know what happened or how to solve it. -- Aleksander
Re: [Quectel EM160R-GL] Various commands over mbim fail with 'Invalid transition'
On Tue, Jun 13, 2023 at 1:43 AM Alex Ballmer wrote: > > After upgrading an EM160R-GL modem via QFireHose from firmware version > EM160RGLAUR02A07M4G to version EM160RGLAUR02A07M4G, almost all functions fail > with ‘Invalid transition’. The modem power state is listed as "power state: > low” via mmcli. On the former firmware version everything was working fine. > > This is currently happening with modemmanager 1.18.8 using mbim via the > qmi_wwan driver on openwrt with linux 4.4.60 and libmbim 1.28.4 > > I tried manually enabling it (in case it was FCC locked) via mbimcli > --device-open-proxy --device="/dev/cdc-wdm0" --quectel-set-radio-state=on, > but this also had no effect. > > What additional steps would I need to take to debug this? Very likely that they may have changed the FCC unlock algorithm in the newer firmware version :/ -- Aleksander
Re: Support Sequans LTE module
Hey Oakley, > > I am writing to ask about add new plug-in on Modem Manager to support Sequans > LTE module(https://sequans.com/products/cassiopeia-cb410l/). > > Please let me know your concern to add this new module into Modem Manager. I > would be grateful if you could share your comment for this request. > We're open to add new plugins, sure. Interestingly, I believe some of us already have some very old Sequans modem that was sent to us like in 2013 or 2014 to test MBIM DSS. Mine is broken and doesn't read the SIM card, but I still have it somewhere. I'm sure your new plugin additions would be completely unrelated to that module, though ;) Feel free to add new plugins to the MM codebase and share your changes via gitlab, see https://modemmanager.org/docs/contribution-guidelines/ -- Aleksander
Re: Quactel RM520N firmware preferences
Hey Pradeep, > We are using Quactel RM520N in openwrt using ModemManager(1.16) , > is there any way to select or list firmware on the module using mmcli . > For eg: In EM74xx we can use IMPREF to select image for carrier like AT , > Verizon etc. I believe there is no way to do this in Quectel modules, although I may be mistaken. The support in ModemManager to list and select stored images using QMI uses generic Qualcomm operations introduced back with Gobi 3K modules, but I haven't seen any other manufacturer actively allowing to switch full firmware images via these commands, apart from Sierra. Maybe ask Quectel directly, and report back what you find! -- Aleksander
Re: Is there a version of modemmanager that works with Debian9 stretch for dual sim?
Hey, > > I would like to compile mmcli on arm stretch. Apt package manager has 1.6.4 > however when it comes to reading the sim cards, it only reads one. I know on > Debian 11 1.18.6 does read two sim cards with no issues, but before I go on > this journey of compiling how can I tell which version was the earliest to > support dual sim, and does anyone know if one can be compiled in debian 9? Dual SIM support was introduced in 1.18.0 for MBIM modems and 1.16.0 for QMI modems. MM 1.18.0 requires glib2 >= 2.56.0 and gudev >= 232. MM 1.16.0 requires glib2 >= 2.48.0 and gudev >= 147. Not sure what glib2 and gudev versions you have available in Debian Stretch. Cheers! -- Aleksander
Re: The MBIM protocol and the Microsoft extensions
Hey! > > The modemmanager.org site now includes a document explaining details > > about the MBIM protocol and the new Microsoft extensions (e.g. for 4G > > and 5G specific features): > > > > https://modemmanager.org/docs/libmbim/mbim-protocol/ > > > > cool, thanks for this! > > I've just a doubt about this statement: > > > Quectel defines a QDU service that supports performing the whole device > > firmware upgrade operation (including file download to the module) via MBIM > > requests and responses. > > Maybe is this "Qualcomm" instead of "Quectel"? > That is right, good catch! Will update it. -- Aleksander
The MBIM protocol and the Microsoft extensions
Hey all, The modemmanager.org site now includes a document explaining details about the MBIM protocol and the new Microsoft extensions (e.g. for 4G and 5G specific features): https://modemmanager.org/docs/libmbim/mbim-protocol/ Please be advised that this document is not specific to either libmbim or ModemManager. It is intended to be general in nature. Cheers -- Aleksander
Re: [Telit LE910C1-EU] ModemManager crashes when establishing online connection
Hey, > I was struggling with getting mm built in my cross build environment and > meson, but finally: > With main branch it works: modem is recognized and connection is > established and mm not crashing. > # Nice! > What about the version 1.20? On > https://www.freedesktop.org/software/ModemManager/ there are no packets > with version 1.20.x. are they nor officially released, though there are > tags, or is there a new page to download from? > Releases are done via signed git tags only from now on. E.g. you can do: $ git clone --depth 1 --branch 1.20.6 https://gitlab.freedesktop.org/mobile-broadband/ModemManager.git $ cd ModemManager $ git tag --verify 1.20.6 -- Aleksander
Re: Understanding Default Bearers and PDP Contexts
Hey! > > Should a bearer of type MM_BEARER_TYPE_DEFAULT correspond 1-1 with a > modem PDP context? > > Said another way, if I have a default bearer with APN B, should `mmcli > -m 0 --3gpp-profile-list` and `AT+CGDCONT` show a profile/PDP context > with APN B? > They're related but not fully the same. The bearer objects exposed by MM represent the "independent connections" that have been or may be triggered with MM. The bearer objects contain settings (e.g. user-provided settings) as well as state (once it's connected). The existence of such a bearer object exposed by MM in DBus does NOT mean a corresponding context is configured in the modem, at least not if the bearer object is disconnected. Once the bearer object is connected, there should be a corresponding context configured in the modem. In fact, the bearer connection sequence involves configuring a context first and then connecting that context. > If there isn't a direct correspondence then the rest of this message can > be ignored. Pessimistically dumping more information here in case this > is a bug, and for searchability should another find themselves as > confused as I am. > > Configuration Info: > - Modem: Quectel EG95-NAXD, FW version EG95NAXDGAR07A01M1G > - Location: US > - Carrier: AT > - Platform: Yocto Linux (kirkstone) > - ModemManager version: 1.18.6 > - NetworkManager version: 1.36.2 > > Problem Description: > My goal is verifying that traffic is being sent directly to a private > APN without flowing through the PDN addressed by the initial-attach APN. > Ah, nice one. > My intuition says that this should be possible, and that there would be > a correspondence between default bearers and PDP contexts. A source [1] > for which I have no sense of reputation quotes: > > > According to 3GPP TS 23.401 [82], there is a 1 to 1 mapping between > > active EPS bearer context and active PDP context > > Reading through 3GPP TS 23.401 version 18.1.0 [2] I haven't been able to > verify that claim. > > In NetworkManager, I have a connection config with > `[gsm]\napn="m2m.com.attz"` (well, goal is a different APN, but this > suffices for example). I can see that this creates bearer 1, and > generating traffic will augment stats on `mmcli -b 1`. However, > `AT+CGDCONT` and `AT+CGREG` indicate that there isn't a PDP context > defined with `m2m.com.attz` as APN, and that the active PDP context is > using the APN of the default-attach bearer 0, `broadband`. > > #+begin_quote > # mmcli -m 0 > --- > General |path: /org/freedesktop/ModemManager1/Modem/0 >| device id: > --- > Hardware |manufacturer: QUALCOMM INCORPORATED >| model: QUECTEL Mobile Broadband Module >| firmware revision: EG95NAXDGAR07A01M1G >| carrier config: VoLTE-ATT >| carrier config revision: 0501033C >|h/w revision: 1 >| supported: gsm-umts, lte >| current: gsm-umts, lte >|equipment id: > --- > System | device: > /sys/devices/platform/bus@5b00/5b0e.usb/ci_hdrc.1/usb1/1-1 >| drivers: option, qmi_wwan >| plugin: quectel >|primary port: cdc-wdm0 >| ports: cdc-wdm0 (qmi), ttyUSB0 (qcdm), ttyUSB2 > (at), wwan0 (net) > --- > Status |lock: sim-pin2 >| unlock retries: sim-pin (3), sim-puk (10), sim-pin2 > (3), sim-puk2 (10) >| state: connected >| power state: on >| access tech: lte >| signal quality: 67% (cached) > --- > Modes| supported: allowed: 3g; preferred: none >| allowed: 4g; preferred: none >| allowed: 3g, 4g; preferred: 4g >| allowed: 3g, 4g; preferred: 3g >| current: allowed: 2g, 3g, 4g; preferred: 4g > --- > Bands| supported: utran-4, utran-5, utran-2, eutran-2, > eutran-4, eutran-5, >| eutran-12, eutran-13, eutran-25, > eutran-26 >| current: utran-4, utran-5, utran-2, eutran-2, > eutran-4, eutran-5, >| eutran-12, eutran-13, eutran-25, > eutran-26 > --- > IP | supported: ipv4, ipv6, ipv4v6 > --- > 3GPP |imei: >| enabled locks: fixed-dialing
Re: [Telit LE910C1-EU] ModemManager crashes when establishing online connection
Hey > Explicitly specifying the ip-type helps for me. > Since you mentioned main, I checked the version I'm using (1.18.12) and > noticed it isn't the latest, so I will try a newer version, and see what > happens. Please retry with git main or with MM 1.20 and report back whether this issue is fixed or not. Thanks! -- Aleksander
Re: SIM Application toolkit commands
Hey, > The Twilio Super SIM will send a Proactive Command NAA Initialization and > Full File Change Notification to the terminal on the IMSI change. Some > modems, like the Quectel BG95 or EC25 will send a URC if > +QUSIM: 1 > if it is a USIM and > +QUSIM: 0 > if it's a regular SIM > no idea about other modems however. > You mean the +QUSIM URC is sent to the host whenever the Full File Change Notification is received by the terminal on the IMSI change? i.e. no need to STK supported by the host in this case, right? > I can arrange to get you a SIM for testing if needed as this is an area I'm > interested in as well. I can also provide a SIMtrace2 pcap (or raw APDUs if > preferred) capture of the communications between the terminal and the SIM if > that would be helpful. > How do you instruct the SIM to switch IMSI? -- Aleksander
Re: How to recover from serial device being force closed.
Hey, > > it would be great if you could verify the behavior on the main branch > (at least on the last stable 1.20.6), and give us some logs, so we can > have a better idea of the issue and how proceed, whether in a general > manner, or with some specific fixes. > Yes, especially since several bugfixes were done that could help solve the problem (although not sure if they were done in 1.20 or earlier really) > > > > I have encountered an issue while running ModemManager (version 1.18.4) on > > a Cinterion PLAS8 modem. Sometimes, the serial device used for AT > > communication with the modem is force closed (due to G_IO_HUP) without any > > obvious reason. > > Also, are you using NetworkManager along with ModemManager? Or are you running pppd yourself? You must ensure that MM only touches the port once pppd has exited, otherwise they'll use mismatched CLOCAL flags and MM may get a HUP when the modem got disconnected from the network (as opposed to getting a HUP only when the port goes away from the system) -- Aleksander
Re: modem terminates call when accepted remotely
Hey > > We finally were able to test voice calls with version 1.18 and it seems > that the (un)terminated call issue is not reproducing any more. > > > Nice! > In addition, now the AT serial port is available for other processes, so > our software is using it for other purposes such as querying for SIM slot > or GNSS configuration. > > > Make sure you add the ID_MM_PORT_IGNORE udev tag to that AT port so that MM completely ignores it. Cheers! -- Aleksander
Re: SIM Application toolkit commands
> > Does ModemManager support SIM application tool kit with proactive SIM > > commands? My assumption is most of these SIM application tool kit > > commands should be handled by the modem but I'm unclear what is the > > role of host CPU / ModemManager in these commands? For example, many > > SIMs support multi-IMSI i.e. depending on the location, a particular > > IMSI is used for network connection. When a SIM changes its IMSI, the > > SIM application tool kit applet sends a REFRESH proactive command to > > the host device (or modem). This instructs the device to re-read the > > data on the SIM, including the new IMSI. > > Currently, ModemManager does not support any SIM application tool kit > commands. SIM toolkit apps displaying emergency numbers etc. are > currently not possible with ModemManager. > > > > > So how shall ModemManager know that IMSI has been changed and what it > > is supposed to do? What is the role of ModemManager in handling these > > commands? > > If the modem emits an AT URC / QMI / MBIM Indication, ModemManager > might be able to handle it, but I'm not sure. > This is right. As we don't support generic SIM STK operations in MM. We currently only support the multi-IMSI scenario on QMI modems when they send an explicit notification about the change (e.g. UIM Refresh indication, see 5c0db3743209b78d8c7b7558e337e6df25951bae). I actually need to investigate the IMSI switch procedure while in MBIM, it's in my TODO list for the next weeks. I assume that maybe using the STK service we could be notified of the same. -- Aleksander
Re: NetworkTimeChanged signal doesn't seems to be working for Quectel
Hey Thomas,
> I do get the +CTZU notification, but it worked differently for quectel
> because it doesn't receive the new time we need to check for +CTZE that's the
> URC that we get when we receive notification that the time has been changed.
What is the format of the +CTZE URC? is it similar to +CTZU? how are
they different?
> For my use case, I would like to update my local time automatically on a
> linux environment using modemmanager with quectel modules.
> So right now I manage to change cinterion's function to process +CTZE events
> and I receive the signal like this
> GDBusProxy *proxy = g_dbus_proxy_new_sync(connection,
> G_DBUS_PROXY_FLAGS_NONE,
> NULL,
> "org.freedesktop.ModemManager1",
> modemPath,
> "org.freedesktop.ModemManager1.Modem.Time",
> NULL,
> );
> if (error != NULL) {
> g_printerr("Error creating ModemManager1.Modem proxy: %s\n", error->message);
> g_error_free(error);
> return 1;
> }
>
> g_signal_connect(proxy, "g-properties-changed",
> G_CALLBACK(update_local_time), NULL);
> }
> But I'm not sure it's the best way to process the signal
Wondering, why not use the libmm-glib we ship with ModemManager
instead of manually creating the proxies and parsing the list of
updated properties?
E.g. you could:
* create a new MMManager with mm_manager_new()
* list the MMObjects it handles with g_dbus_object_manager_get_objects()
* get a MMModemTime interface object with mm_object_get_modem_time()
* listen to the "network-time-changed" signal
--
Aleksander
Re: ModemManager and MQTT messages over DBUS
Hey Mohamed, > > I am using a Quectel EC21 modem, connected to an imx6ul soc via usb (UART is > also available), everything works fine and I have connectivity without issues. > > So my usecase is putting both the cpu and the modem, and I am able to do > that, but the wakeup should be from a remote MQTT message coming from my > server which will wakeup the modem first, that in turn wakeup the cpu using > the RI pin. > Ok. > I have played around with this and it is only possible if I use the modem's > MQTT stack, as it will maintain the TCP connection even in sleep mode. I am > configuring the MQTT endpoint using AT commands (through mmcli --commands). > This makes sense. > The problem is that I am not able to receive the messages when subscribing to > a topic, even though I know the message arrived (I can see the raw data when > putting modemmanager in Debug mode). > > So my question is, is it possible to receive the MQTT URCs (+QMTRECV for > example) over DBUS so that my application could handle them after wakeup, and > if not what path should I follow ? So the MQTT notifications are reported via AT URCs to the host. You could extend one ModemManager interface to expose a new signal that would emit the contents of the received URC, and then you would need to modify the quectel plugin to match the +QMTRECV URC with a custom regex. An example of this would be e.g. the processing of the ^MODE URCs in the Huawei plugin, see how the "mode_regex" variable is setup and how the URC contents are processed in the "huawei_mode_changed()" callback. Once the contents are processed, the plugin calls the mm_iface_modem_update_access_technologies() method, that ends up updating a DBus property with mm_gdbus_modem_set_access_technologies(). > > Note: I tried probing the USB AT interface for incoming URCs but I wasn't > able to receive them, probably because modemmanager is concurrently using it > as well ? Yes, you should not use a TTY port that is in use by ModemManager. -- Aleksander
Re: NetworkTimeChanged signal doesn't seems to be working for Quectel
Hey, > > I am trying to get notification from Quectel when there is a time change, I > see that there is a signal NetworkTimeChanged for this but when I looked at > the code, I see that the signal is not being emitted for Quectel modules. > True; we're not emitting those for all modem types. Do you get +CTZU notifications in your modem? Right now I think we're processing these only for cinterion modules. Also, what is your usecase? I assume you're interested on the timezone information exclusively, right? -- Aleksander
Re: Get modem SIM properties for mmcli
Hey Brendan, > Is there a way to get the modem SIM properties via the mmcli command? > > e.g. the ICCID or SimIdentifier > You can do this, yes. You can run "mmcli -m a" to get the list of details for your modem, and that output will report a "primary sim path" field, e.g. - SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 You can then run "mmcli --sim /org/freedesktop/ModemManager1/SIM/0" (or just "mmcli -i 0" shorter), e.g.: --- Properties |active: yes | imsi: 21407 | iccid: 89 | operator id: 21407 | operator name: Movistar | gid1: 01 | type: physical | removability: removable -- Aleksander
Re: ModemManager fails to utilize Modem, when it is not ready yet
On Tue, Apr 11, 2023 at 11:34 AM Christian Schneider wrote: > > Ok, I see. Having a workaround in ModemManager would be great. > I will also try to contact the supplier/manufacturer to see, if this can > be changed. > What would be the proper reponse in such a case? > CME ERROR: 14 SIM busy? > That could be a good compromise I guess; or even a generic ERROR would have been better than lying. -- Aleksander
Re: ModemManager fails to utilize Modem, when it is not ready yet
Hey Christian, > > Hi, I have a SIMCOM_SIM7600E-H modem. > > When the Modem is freshly "activated" (eg. after powering on the whole > device, toggling the MPCIE reset pin, unplugging/plugging the MPCIE > card), ModemManager is not able to utilize the modem, it ends in state >Status | state: failed > | failed reason: sim-missing > | power state: on > > at this point, when I restart ModemManager (I don't do anything with the > modem itself), it works, the modem is usable, calls, sms, internet > connection work. > > I've looked at the debug output of ModemManager and found this: In the > "bad" case, some of the AT commands fail, where the final straw for > ModemManager seems to be "AT+CPIN?" that is answered with "+CME ERROR: > 10" which is interpreted as "SIM not inserted" by ModemManager. > In the "good" case the answer to "AT+CPIN?" is "+CPIN: READY" and > ModemManager is happy. > > Using the AT interface manually, I can notice this behavior: > Directly after starting the modem, the answer to "AT+CPIN?" is "+CME > ERROR: 10", only after some 30 seconds, the answer is "+CPIN: READY" > I don't now the standards good enough, to judge if such behavior is > allowed, but I'm pretty sure, that this behavior is the problem for > ModemManager. When the answer to "AT+CPIN?" is "+CME ERROR: 10" once, it > marks the modem as failed without retrying. > Yeah, that's kind of expected, "+CME ERROR: 10" means "SIM not inserted", and MM trusts what the modem says in this case. It is actually not uncommon to have this kind of behavior, we have also seen it in other modems (e.g. MC7710 in MBIM). For the MBIM case we explicitly treat SIM_NOT_INSERTED as SIM_NOT_INITIALIZED, so that the generic retry mechanism is applied, and eventually it will either report the SIM locked/unlocked or otherwise fail all attempts as SIM_NOT_INSERTED, which is when we really report the modem in "Failed" state. It is true that this issue is a modem firmware error; the modem should not say there is no SIM when the problem is that it hasn't finished initializing it. If you can report that to the manufacturer it would be great. Still, we should probably workaround it in MM as well, as we did for the MBIM case. I've opened a new issue to track it in gitlab: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/725 -- Aleksander
Re: modem terminates call when accepted remotely
Hey Héctor, On Thu, Mar 23, 2023 at 2:03 PM Héctor Jiménez Méndez < hector.jimene...@gmv.com> wrote: > Hi, Alex, thanks for your quick answer. > > Nice to know you worked at Elecnor/Deimos Space > > This is definitely a bug to fix. That transition to "terminated" > shouldn't happen when the callee picks up the call. Can you get MM debug > logs while reproducing the issue? Also, is this using AT or QMI? > > Two logs are attached: one with transition from ringing-out to active and > another with the wrong state transition (ringing-out -> terminated). > > At first sight I couldn’t find any significative trace to explain this > behavior, I hope you can get some related info in them. > > > I think this "CONNECT" URC is getting in the middle of the +CLCC? polling and it's breaking the logic: ModemManager[4908]: [1679560149.943734] [modem0/ttyUSB2/at] --> 'AT+CLCC' ModemManager[4908]: [1679560150.110892] [modem0/ttyUSB2/at] <-- 'CONNECT ' ModemManager[4908]: [1679560150.111267] [modem0] reported 0 ongoing calls Your device is QMI capable and we do see certain Voice events reported in the log via QMI. Full QMI based voice support was introduced in MM 1.18, I definitely suggest you switch to that so that AT-based management is completely skipped. -- Aleksander
Re: ublox SARA does not connect
Hey! On Mon, Mar 27, 2023 at 11:00 AM ron wrote: > > Hi > > Im running a ublox SARA modem in an embedded system on ubuntu. > > It is connecting fine on ubuntu 20.04, but remains in “registered” state when > setup in ubuntu 22.04. > > It seems that NM doesn’t run pppd for some reason, or is it MM issue? > > > > root@ubuntu:~# mmcli -m 0 > > > > General | path: /org/freedesktop/ModemManager1/Modem/0 > >|device id: d4174b3552de7d45f5b0268aec1350664f7273c6 > > > > Hardware | manufacturer: u-blox > >|model: SARA-R510M8S > >|firmware revision: 03.15 > >|supported: gsm-umts > >| current: gsm-umts > >| equipment id: 352709570223149 > > > > System | device: > /sys/devices/platform/soc@0/3080.bus/3086.serial > >| drivers: imx-uart > >| plugin: generic > >| primary port: ttymxc0 > >|ports: ttymxc0 (at) > > > > Status | unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (3), > sim-puk2 (10) > >|state: registered > >| power state: on > >| access tech: lte > >| signal quality: 41% (recent) > > > > Modes|supported: allowed: any; preferred: none > >| current: allowed: any; preferred: none > > > > IP |supported: ipv4, ipv6, ipv4v6 > > > > 3GPP | imei: 352709570223149 > >|operator name: Partner ISR > >| registration: home-sms-only > >| packet service state: detached These two previous lines are a bit suspicious. The home-sms-only could indicate that you are not allowed to setup a data connection, but that would collide with your previous statement that it worked fine in 20.04. Then, the packet service detached thing could indicate that we're not correctly handling that, but a bit unsure without looking at the logs. Could you gather MM debug logs (see https://modemmanager.org/docs/modemmanager/debugging/) with both Ubuntu 20.04 and Ubuntu 22.04 and open a new issue in gitlab? https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues > > > > SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 > > > > NM connection file: > > > > id=ttymxc0 > > uuid=c0a7c307-2657-4cf1-8913-b5a826594338 > > type=gsm > > > > [gsm] > > #apn=uinternet > > auto-config=TRUE > > > > [ppp] > > baud=921600 > > crtscts=true > > lcp-echo-failure=5 > > lcp-echo-interval=30 > > > > [ipv4] > > dns-search= > > method=auto > > > > [ipv6] > > addr-gen-mode=stable-privacy > > dns-search= > > method=ignore -- Aleksander
New ID_MM_REQUIRED tag to avoid unwanted fallbacks to AT-only modem
Hey Peter & all,
The following merge request introduces a new per-port ID_MM_REQUIRED udev tag:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/989
This udev tag can be specified on the control port that MUST be
successfully grabbed when creating a new modem object, or otherwise
the modem object will not be created at all. E.g. if you have a
QMI-capable modem and you want to make sure the modem is always
managed with the QMI protocol, this tag can be configured in the
specific QMI control port that is required (therefore avoiding the
fallback to AT-only and PPP).
E.g. flagging the MBIM port of the Fibocom L850 module:
$ vim /lib/udev/rules.d/78-mm-test.rules
ACTION!="add|change|move|bind", GOTO="mm_test_rules_end"
SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*",
ENV{.MM_USBIFNUM}="$attr{bInterfaceNumber}"
ATTRS{idVendor}=="2cb7", ATTRS{idProduct}=="0007",
ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_REQUIRED}="1"
LABEL="mm_test_rules_end"
$ sudo udevadm control --reload
$ sudo udevadm trigger
$ sudo udevadm info -p /sys/class/usbmisc/cdc-wdm0
...
E: ID_MM_REQUIRED=1
E: ID_MM_CANDIDATE=1
This tag should be used with caution, because when the given tagged
port is not successfully grabbed, the modem object won't be created
and it won't be exposed in DBus. It is assumed that when this tag is
used, some other external process may be monitoring the existence of
the modem in the bus, and if it's not there, it will trigger some
modem recovery mechanism or something to reset the device.
Please note, if the failure probing the port (that could lead to this
tag effectively ignoring the device completely) is due to something we
can fix in the probing phase, we should fix it. Please DO NOT rely on
this tag to recover from issues that could have been prevented by a
probing phase fix. If unsure, ask in the mailing list.
Let me know what you think.
Cheers!
--
Aleksander
Re: Temperature of modem
Hey, On Fri, Mar 3, 2023 at 8:18 PM Tom Isaacson wrote: > > Thanks. Is there any risk in calling qmicli functions when ModemManager is in > charge of the modem? > As long as you're using the qmi-proxy setup when calling qmicli (i.e. using the "-p" option), and you're NOT modifying the state or configuration of the modem, there is no risk. Reading the temperature should definitely be fine. -- Aleksander
Re: EM7565 failing if host reboots whithout power cycling the modem
Hey! On Sun, Mar 19, 2023 at 11:40 AM Bjørn Mork wrote: > > This is not an issue caused by ModemManager or any of the host drivers. > Nut I don't know where else to ask. And this documents the issue for my > next Google search :-) > Hahaha, been there. > I'm using a Sierra Wireless EM7565 connected to the USB3 port of a > Linksys WRT1900ACv1 "Mamba" (Marvell Armada 370/XP SoC), which has an > Etron EJ168 PCIe connected xhci controller. The system runs a recent > OpenWrt build (v5.15 kernel) with ModemManager. > > This works fine after the initial power-on or after physically > reconnecting the modem each time the host is rebooted. But it fails > consistently if I reboot the host without disconnecting the modem. > > The xhci driver will then log these messages while MM is probing the > modem: > > [ 78.014486] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.021419] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.028341] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.035270] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.043035] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.049973] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.056886] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.063808] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.070723] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.077633] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.084552] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.092256] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.099154] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.106082] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.007691] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.014629] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.021554] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.028474] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.035391] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.042306] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.049212] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.056669] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.063590] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.070504] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.077411] xhci_hcd :01:00.0: WARN Successful completion on short TX > > > and probing eventually fails. Likewise with any attempt to use mbimcli > etc. The /dev/cdc-wdm0 device appears dead. So I assume those warnings > are real errors, masked by the XHCI_TRUST_TX_LENGTH quirk applied to > this xhci device a decade ago. Are we sure this is not an issue in the xhci driver itself? Maybe the specific combination of modem and xhci controller triggers some corner case that is not fully implemented correctly in xhci? Last time I found something similar it took me 2 weeks of reading the USB standard to come up with the fix (45ba2154d12fc43b70312198ec47085f10be801a). Did you report this at the LKML already? Maybe they have some hints on how to best handle this. -- Aleksander
Re: modem terminates call when accepted remotely
Hoola Héctor! > > > First of all, I would like to thank you all your effort to develop and > maintain this API as it’s being very useful to us for handling modem > connections in our embedded devices. > > I'm really glad to see GMV is using all this :) I worked at Elecnor/Deimos Space in a past life! > We are facing an issue with ModemManager 1.16.2 (libmm-glib) and RC7620 > SIERRA modem. > > Sometimes, after starting a call to another SIM card device (mobile > phone), the call gets into “terminated” state (seen by ModemManager) in the > moment the call is accepted by the remote device, while it remains active > at this remote point. > > The call state becomes “dialing”, then “ringing-out”, and finally > “terminated” so there is no option to finish the call from ModemManager > side as it’s seen as already terminated. > > > This is definitely a bug to fix. That transition to "terminated" shouldn't happen when the callee picks up the call. Can you get MM debug logs while reproducing the issue? Also, is this using AT or QMI? > We managed to actually finish the call (remote side too) by the use of > ”mm_modem_voice_hangup_all_sync” function (defined in mm-modem-voice.h), > but it’s only available since ModemManager 1.12 Version. > > 1.18 or 1.20 you mean I guess. Either way, the solution is to avoid getting into that wrong terminated state I think. > Some of our devices are using other hardware and older versions of > ModemManager (1.10) and we have never been able to reproduce this issue so > we didn’t need to make use of “mm_modem_voice_hangup_all_sync” function. > > Could be due to some update in recent versions. We did include the call list management logic as well as the waiting call setup logic. Maybe some of that is not working as expected in your Sierra modem. > I would like to know if this issue has been already reported, and if so, > if it has been resolved or if it’s related to the hardware we installed on > our device or, on the other hand, if has something to do with the > ModemManager version being used. > > > Don't recall an issue like this, truth be told. Cheers -- Aleksander
Re: initial bearer apn
> > How is the initial-attach-ip-type decided in the NM MR you shared? I've seen > in a network in New Zealand where initial-attach-iptype has to be IPV4 and > then it can be changed to IPV4V6 during connection establishment. > I assume this could happen if the APN used during connection is different to the one used during initial attach? But this is definitely interesting; do you happen to have debug logs of MM on that setup to confirm your assumption? > Also, modem might have already gone through registration process before > "--3gpp-set-initial-eps-bearer-settings" is called. So when are we supposed > to call "mmcli --3gpp-set-initial-eps-bearer-settings"? > Yes, the modem always boots and attempts to register in the network automatically, that's the default. For initial attach it would use whatever it had configured. If you're using a device that comes with carrier-specific configs, the default config may already be the correct one for you. If you are using a generic firmware, there could be no explicit initial attach APN configured by default, but the network may be fine with providing you the correct one during the initial attach. You will need to use "--3gpp-set-initial-eps-bearer-settings" if e.g. you're not able to automatically register in the network and you know for sure the network you're trying to attach is the expected one. ModemManager dumps some warnings when attach failures happen, and we should definitely try to update the DBus API to expose those there as well (see https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/715) -- Aleksander
Re: initial bearer apn
Hey! > > I'm using ModemManager version 1.18.12. I'm also using Network Manager 1.22.16 > > I'm wondering what part of the system stores or configures the initial > bearer apn, since I'm not explicitly setting this value? > > $ mmcli -m 0 | grep 'bearer apn' >| initial bearer apn: Telstra.internet > > Is this a default value set by MM or NM, or is this something that is > stored in the SIM by the carrier? > In LTE there are always two different APN settings in use: * initial EPS default bearer settings (a.k.a. attach APN) * data connection settings (a.k.a. connection APN). The attach APN is the APN used during *registration* to the LTE network, it is LTE-specific. This APN is stored as a profile configured in the device, and is subject to change via different ways; e.g. it could have been preconfigured in the device via carrier settings, or it could be manually set by the user, or it could even be updated via OTA. In MM we have 2 different sets of attach APN info: the settings requested by the user (these are the ones you see in mmcli -m a output) and the settings agreed with the network (these are the ones you see in the bearer object reported as initial bearer in the mmcli -m a output). Some networks allow you to request any initial APN (even the blank "" APN) and then it will tell you which one to use (so requested and agreed may be different). Other networks are strict and if you don't request the correct one the registration will be rejected (very common in Japan for some reason). Also IP type is important here, if you request a IPv4-only initial attach APN, attempting to get a IPv6 connection later on won't work. The connection APN is the one that you're probably most familiar with. This is the APN that you need to get the modem connected to e.g. the Internet. This may or may not be the same as the initial APN! E.g. I recall some network in Germany where you required an initial APN just to get the service but it wouldn't give you internet connectivity; you then had to connect to a different APN in order to get the bearer to the Internet established correctly. In most cases, though, both initial and connection APNs are the same. In NetworkManager 1.42 the user will have explicit settings to configure the initial attach APN as part of the config profile, see https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1331 if you're using an older version, and you need to specify a custom attach APN, you can do it with mmcli. -- Aleksander
Re: ModemManager AT & QMI
Hey! > > I am a developer working on a board with a Quectel Modem, and I am in charge > of replacing our old abstraction layer with ModemManager to communicate with > this modem. > > I have been playing with ModemManager for a few days to be familiar with it. > I have read the documentation and I have been reading also the source code to > better understand how it works. > > However, a few fundamental questions remain for me, and I hope some people > here may give me some clue. > > First of all, when I list the modems found by MM, it returns not one, but two > modems: > > # mmcli -L > /org/freedesktop/ModemManager1/Modem/1 [Quectel] SG520TM > /org/freedesktop/ModemManager1/Modem/0 [Quectel] SG520TM > > One of them is linked to tty USB port and communicates only with AT commands > (ttyUSBx), the other one is linked to the PCIe port and communicates only > with QMI (wwan0qmi0). > I do not have a wwan0at0 driver. The only way to have AT commands is through > the ttyUSBx port. > > It looks like I have two separate modems, whereas I have only one physical > modem, connected to the board with two physical ports (usb & pcie). > Yep, that is indeed possible, especially in custom boards. Also, some manufacturers may expect you to upgrade firmware only via USB while managing the modem via PCI and things like that. > The diagrams here suggest that MM can have single modems with more than one > protocol, but on the same physical port: > https://modemmanager.org/docs/modemmanager/wwan-device-types/ > > Is it possible to have MM create only one modem using two different physical > ports (ttyUSBx on USB & wwan0qmi0 on PCIe), in order to have AT & QMI > simultaneously? > > If not, does it mean that in order to have one modem with AT & QMI, I would > need to have a working wwan0at0 driver? > You can have one single modem with all the ports in the two different buses by making sure all the ports have the same ID_MM_PHYSDEV_UID tag. See https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/ModemManager-Common-udev-tags.html#ID-MM-PHYSDEV-UID:CAPS And also https://sigquit.wordpress.com/2016/10/06/naming-devices-in-modemmanager/ If you apply that tag to all the ports, e.g. using the DEVPATH of each port for example, and use the same uid in all (e.g. "MyModem") then ModemManager will bind all ports in the same modem object. Plus, you could do "mmcli -m MyModem" as well :) Of course, you need to ensure that the DEVPATH of your rules doesn't change. You can assume the DEVPATH of a port in USB or PCI won't change as long as the hardware layout is the same. A corollary of this would be that the DEVPATH for the ports in different board units with the same hardware layout (same board type) won't change either. > > My second question is about the cache handling. > I could see that MM may use cached AT results, meaning that your plugin can > have the result of an AT command without actually sending it (with the > allow_cached parameter). > This is a great feature, and experience showed us that it improves > dramatically your application latencies. Please note this applies *exclusively* to commands that are known to never change, mostly the "test" commands like e.g. "AT+CGDCONT=?" or "AT+CGACT=?". This caching feature doesn't make sense for commands that include state values in the response like e.g. "AT+CGDCONT?" or "AT+CGACT?". > > Are QMI or Dbus requests cached as well? > No, none of them. There are some commands which could be cached (e.g. those querying static info from the modem like supported services), but it's probably not very useful. -- Aleksander
Re: ModemManager and Quectel RM520N-GL
On Fri, Mar 3, 2023 at 12:45 PM Patrick Kosiol wrote: > > Hi, > > It appears my ModemManager cannot initialize the Quectel RM520N-GL modem with > the messages > [01775.270989] [modem0] couldn't start parent initialization: > Couldn't open ports during modem initialization: Couldn't get primary port > [01775.275716] [modem0] modem couldn't be initialized: Failed to > load current capabilities: Couldn't peek client for service ‘nas' > > Perhaps someone has an idea what the reason might be? That would help me very > much. > >From the debug log: [01775.005392] [/dev/cdc-wdm0] received generic response (translated)... << QMUX: << length = 18 << flags = 0x80 << service = "ctl" << client = 0 << QMI: << flags = "response" << transaction = 6 << tlv_length = 7 << message = "Allocate CID" (0x0022) << TLV: << type = "Result" (0x02) << length = 4 << value = 01:00:05:00 << translated = FAILURE: ClientIdsExhausted [01775.006317] [modem0] couldn't allocate client for service 'nas': Couldn't create client for service 'nas': QMI protocol error (5): 'ClientIdsExhausted' Do you have any other process attempting to use QMI in the system? E.g. are you running some qmicli commands or something at the same time? The error above shows how a NAS client allocation fails with ClientIdsExhausted, which indicates that there are unreleased NAS clients around. ModemManager takes care of allocating clients and releasing them properly when they're no longer used. If no other processes are running QMI operations, could it be that MM is not being cleanly shutdown at some point and then restarted? -- Aleksander
Re: ModemManager and Quectel RM520N-GL
On Wed, Mar 15, 2023 at 12:28 PM Peter Naulls wrote: > > On 3/6/23 02:40, Patrick Kosiol wrote: > > Hi Peter, > > > > Thanks for the info. > > > > Actually, the lsusb output was incomplete. It looks like the one attached > > so the > > device is actually there. Yet, you are right, the /dev/ttyUSB device is not > > present. > > > > I checked the state of the usb device and it appears to be loaded with the > > qmi_wwan driver, which seems correct: > > > 80M > > > > Do you happen to have any other suggestion? > > I did, in the bit you didn't quote - this is why good quoting is always good > practice: > > > "I'm not seeing the USB serial devices for your modem, i.e, /dev/ttyUSBx. It > may be that you need a usb_modeswtich invocation. ModemManager won't pick it > up > until these exist." > There is no need for USB modeswitch in this case though, that's totally unrelated. The TTYs are exposed in the USB layout (interfaces 0-3), but they are not bound to any kernel driver. Likely the option kernel driver in use doesn't have them defined for this specific vid:pid. The missing TTYs are not a real issue though, if the modem has a QMI port, the QMI port should be responsive. -- Aleksander
Re: ModemManager vs NetworkManager (and the overlap of functionality) : Best Practices
On Mon, Mar 13, 2023 at 2:09 PM Peter Naulls wrote: > > On 3/13/23 08:34, Robert Colvin wrote: > > > but this leaves me with more questions than answers (after playing for a > > while) > > > > As I understood it, NM was responsible for managing the modem itself, > > whereas MM would handle tasks like automatically failing over a wireless > > network to a cellular connection - but would rely on NM to manage the > > interface to the modem. But in this "simple" task there is some > > overlap/grey area - for example, a cellular data connection requires things > > like APNs, where should that fall? it seems it has landed in both NM and MM. > > "It's complicated". > Heh, yeah :) > I use MM in OpenWrt, and I have a separate script to monitor connections and > restart the modem when required. It's not an ideal or tightly integrated > solution, but it's pretty robust at this time. There may be other pieces too, > in particular udev rules for invoking usbmodeswitch and such. In OpenWrt, > ModemManager intergrates with netifd, which a lot like NetworkManager, and > there > are scripts that tie them together. > Forgot about USB modeswitch, good point, it's something we always take for granted and there are still cases out there that require it. -- Aleksander
Re: ModemManager vs NetworkManager (and the overlap of functionality) : Best Practices
> > As I understood it, NM was responsible for managing the modem itself, whereas > MM would handle tasks like automatically failing over a wireless network to a > cellular connection - but would rely on NM to manage the interface to the > modem. But in this "simple" task there is some overlap/grey area - for > example, a cellular data connection requires things like APNs, where should > that fall? it seems it has landed in both NM and MM. > We should improve the documentation! NM and MM do not overlap at all, they do completely different things! There is absolutely nothing that MM does that NM could also do, and the other way around. MM talks exclusively with the control port of the modem, and allows the modem to be prepared for a data connection (e.g. activate a bearer/PDP context). NM does not touch the control port for anything. NM is the one asking MM to connect the modem, and will setup the actual IP data path (either PPP or static/DHCP over a net port). NM could use ofono instead of MM for modem management, although not sure how well supported that is nowadays. In the same way, different network manager systems (not NM) could use MM: e.g. netifd in openwrt or shill in ChromeOS both use ModemManager. -- Aleksander
Re: U-Blox SARA R412m : Serial Network Management
Hey! > I have been struggling with a U-Blox SARA R412m over serial. I originally > posted this to the Network Manager list, however I have come to wonder if > this might be a Network Manager issue instead? > > this is then a repost of the original > (https://lists.freedesktop.org/archives/networkmanager/2023-February/26.html) > > > > I have a U-Blox Sara R412m LTE-M Modem which I am attempting to use with > Network Manager. The modem is supplied via an IoT 6 Click from Mikroe > (https://www.mikroe.com/lte-iot-6-click). It is connected to a Raspberry Pi > 3b running the latest version of Raspbian Lite 32-bit. > > to summarise early (more detail will follow) Modem Manager is seeing the > modem, however Network Manager is failing to setup a connection; specifically > the error I am seeing currently is "failed to connect 'r412m_serial': > Connection requested IPv4 but IPv4 is unsupported by the modem." - which is > incorrect. > > more detail: > > Initially I had an issue with the Raspberry Pi recognising the modem on > ttyS0; this ended up being an issue with HW Flow Control, by only connecting > RX, TX, 5V and Ground the modem was found on ttyS0 and through minicom > (minicom -b 115200 -D /dev/ttyS0) I am able to issue AT Commands to the modem. > > currently, Modem Manager is able to see the device > > $ mmcli -L > /org/freedesktop/ModemManager1/Modem/0 [u-blox] SARA-R412M-02B > > it looks as I would expect > > $ mmcli -m 0 > > General |dbus path: /org/freedesktop/ModemManager1/Modem/0 >|device id: 69b7c92de0606d6bbd08dd68bbf7a8ddd0cddd3e > > Hardware | manufacturer: u-blox >|model: SARA-R412M-02B >|firmware revision: M0.12.00 [Dec 04 2020 16:05:31] >|supported: gsm-umts, lte >| current: gsm-umts, lte >| equipment id: 359159977335935 > > System | device: /sys/devices/platform/soc/3f215040.serial >| drivers: bcm2835-aux-uart >| plugin: u-blox >| primary port: ttyS0 >|ports: ttyS0 (at) > > Status |state: registered >| power state: on >| access tech: lte >| signal quality: 100% (recent) > > Modes|supported: allowed: any; preferred: none >| current: allowed: any; preferred: none > > Bands|supported: egsm, dcs, pcs, g850, eutran-1, eutran-2, > eutran-3, >| eutran-4, eutran-5, eutran-8, eutran-12, > eutran-13, eutran-19, >| eutran-20, eutran-28, eutran-39 > > 3GPP | imei: >| operator id: >|operator name: >| registration: home > > 3GPP EPS | ue mode of operation: csps-2 > > SIM |dbus path: /org/freedesktop/ModemManager1/SIM/0 > > I have setup a connection, and that to me looks correct > > === >Connection profile details (r412m_serial) > === > connection.id: r412m_serial > connection.uuid:4da6b696-4540-4764-a942-2b6facda45ca > connection.stable-id: -- > connection.type:gsm > connection.interface-name: ttyS0 > connection.autoconnect: yes > connection.autoconnect-priority:0 > connection.autoconnect-retries: -1 (default) > connection.multi-connect: 0 (default) > connection.auth-retries:-1 > connection.timestamp: 0 > connection.read-only: no > connection.permissions: -- > connection.zone:-- > connection.master: -- > connection.slave-type: -- > connection.autoconnect-slaves: -1 (default) > connection.secondaries: -- > connection.gateway-ping-timeout:0 > connection.metered: unknown > connection.lldp:default > connection.mdns:-1 (default) > connection.llmnr: -1 (default) > connection.wait-device-timeout: -1 > --- > ipv4.method:
Re: ModemManager and modem low power with USB/QMI
Hey, I'm using Quectel EC21EUX modem, connected with USB, and QMI to control it via ModemManager. I have a question about going to sleep with a TCP connection kept so the device can wake up. I have configured the modem to go to low power mode whenever there is no traffic (AT+QSCLK=1, AT+QURCCFG="urcport","usbat", setting DTR and AP_READY pins). With this configuration, LTE modem should wake up when there is an incoming data packet. The easiest way for me put modem to sleep was to stop ModemManager. Now, if I disable ModemManager, and then try to send a network packet from backend to the device, the modem never wakes up. My guess is that when I stop ModemManager, the TCP connection is lost, and this is why modem cannot wake up as it doesn't get the message from backend. The default behavior when you stop ModemManager cleanly is to stop connections and disable modem, so yeah, not ideal for what you're attempting to do. My preferred way to sleep modem is to disable USB_VBUS. Wouldn't that take the modem out of the USB bus as well? On the ModemManager side, what should I do to maintain the TCP connection when putting the modem to sleep, so it can wake up when getting a message over network? It really depends on how you're making the modem sleep, how it is exposed in the system during that time, how you expect it to wake up, and what is the state of the host during all that. E.g. I don't think it's possible maintaining a TCP session alive between the host and a remote server while the host is awake and the modem is no longer exposed in the system, unless it's your modem itself the one making the effort of maintaining that TCP session alive somehow. And as said it also depends on the state of the host; if you're expecting both the host and modem to be awaken by an incoming packet in the TCP session, absolutely no idea how you're supposed to do that if the host (one of the endpoints of the TCP session) is already asleep. I'm also not sure how the modem in sleep mode can still receive packets from the network; I guess it's not a full sleep in the radio stack? Please note, I don't know much about AT+QSCLK or how Quectel does all this :) I was hoping someone else would jump in this thread to reply! Cheers -- Aleksander OpenPGP_0xAECE0239C6606AD5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
ANN: ModemManager 1.20.6 released
Hey hey, This is the third bugfix release in the 1.20.x series, built from the mm-1-20 branch. Overview of changes in ModemManager 1.20.6 --- * build: ** New build option to allow disabling the installation of examples. * core: ** Fix crash when uninhibiting partially removed device. ** Fix crash when attempting to load an invalid shared utils library. * mmcli: ** Allow JSON and key/value output when creating SMS messages. ** Improved JSON output in network scan results. * libmm-glib: ** Avoid using g_time_zone_new_offset() unless glib >= 2.58. ** Fix flags to string conversion utils to allow multiple flags. * MBIM: ** Reset cached SIM info when SIM is unlocked. ** Fix synchronizing the state of the SIM hot swap configured flag. ** Fix bug cleaning up the LTE attach info unsolicited message handler. ** Fallback from QMI UIM service only if unsupported. ** Add missing support for 'emergency' APN type. * QMI: ** Fix processing and exposing PCOs. ** Fix power up on modems that don't support power state change indications. * plugins: ** telit: add additional support for 5G modems. ** telit: added port type hints for FN990 0x1070, 0x1071 compositions. ** telit: increase allowed initial delay in AT ports. ** telit: fallback to AT commands if loading revision via MBIM fails. ** quectel: add support for EC21-EUX usb modules. ** xmm: fix crash parsing XACT? response. About ModemManager: https://www.freedesktop.org/wiki/Software/ModemManager Download and verify: $ git clone --depth 1 --branch 1.20.6 https://gitlab.freedesktop.org/mobile-broadband/ModemManager.git $ cd ModemManager $ git tag --verify 1.20.6 APIs and manpages here: https://www.freedesktop.org/software/ModemManager/doc/1.20.0/ModemManager https://www.freedesktop.org/software/ModemManager/doc/1.20.0/libmm-glib https://www.freedesktop.org/software/ModemManager/man/1.20.0/ModemManager.8.html https://www.freedesktop.org/software/ModemManager/man/1.20.0/mmcli.1.html Please report bugs either to: modemmanager-devel@lists.freedesktop.org Or to gitlab: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues OpenPGP_0xAECE0239C6606AD5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Restrict Operator Selection
Hey,
>
> We have some devices in far away locations, using roaming IoT-focused SIM
> cards.
> In some situations we find that modems will roam to very expensive
> networks, when a cheaper alternative is available in that area.
>
> Is there an interface to set the operator MCC / MNC via `mmcli`?
> The AT command would be `AT+COPS=1,2,${MCCMNC}`, but you can't issue
> AT commands unless debug mode is enabled.
>
> From the documentation, I'm not convinced
> `--3gpp-register-in-operator=MCCMNC` is what I'm after...
> i.e: does it do the equivalent of above? ... is it a "one-time
> request" or even a "try manual, fallback on auto".
> If this is indeed what I'm after, but it needs to be issued
> periodically, then that's fine.
> Equally, if it's persistent, how would we cancel this? (reboot / power
> cycle the modem?)
>
--3gpp-register-in-operator=MCCMNC should be equivalent to
AT+COPS=1,2,${MCCMNC} (i.e. manual registration)
--3gpp-register-in-home should be equivalent to AT+COPS=0 (i.e. auto
registration)
Now, that is not completely true I'm afraid, because when those APIs
were developed, I recall that we introduced a change where we would
say 'if we're in auto and we're asked to register in a specific
MCCMNC, we won't issue a new +COPS command to explicitly restrict to
that MCCMNC as we're already registered'. I think someone tried to fix
that some years ago to make it equivalent to the COPS command without
that extra logic, but I don't think it was ever changed. We should
change that.
--
Aleksander
Re: Temperature of modem
On Tue, Feb 14, 2023 at 2:44 AM Tom Isaacson wrote: > > Using "qmicli --nas-swi-get-status" I can get the temperature of the modem: > > [/dev/cdc-wdm0] Successfully got status: > Common Info: > Temperature: '32' > Modem mode: 'online' > System mode: 'lte' > IMS registration state: 'full-srv' > Packet service state: 'attached' > LTE info: > Band: '(null)' > Bandwidth: '10' > RX channel: '6300' > TX channel: '24300' > EMM state: 'registered' > EMM sub state: '0' > EMM connection state: 'rrc-idle' > > But I can't find this in ModemManager. Is it just not implemented or > is there some limitation that prevents it? > Just not implemented, we don't have any defined API for that. -- Aleksander
