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: Netlink failure when attempting to add multiplexed link in MBIM modem
Aleksander Morgado writes: > 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 Afraid I cant help much with this. I'm really no expert in this area. Looks like vlan_newlink() can fail in a number of ways: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/8021q/vlan_netlink.c#n140 And several of those return paths are silent, making it hard to guess why it failed. I guess that -1 is the result of some translation and not the real errno? If you can reproduce this somewhat reliably then you could try adding extra debugging to all the error paths. Otherwise I really don't know how to figure out exactly where this fails. Not much help there... Bjørn
Re: AT port not attacted with RM520N-GL
Hi Aleksander,
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/
Thanks,
Pradeep G
On Tue, Feb 13, 2024 at 3:44 AM Aleksander Morgado <
aleksande...@chromium.org> wrote:
> 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
>
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
Re: No IP address for a successful connection on LTE modem
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. On 2/13/24 14:43, Aleksander Morgado wrote: 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?
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
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. On 2/13/24 14:00, Aleksander Morgado wrote: 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?
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
