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
