Re: How to recover from serial device being force closed.

[Jessy Exum]

Sorry for the late reply,

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.

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.

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!

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.

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.

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 the move handler was incorrect).

The *online* and *offline* events are supposedly for things like a network
interface coming up or going down, so I do not think these events will be
relevant to ModemManager at all. The *bind* and *unbind* events are for
when drivers are attached or detached from the device, which I also believe
is useless to ModemManager and could not affect anything with the Modem
lifecycle.

But the *change* event is interesting. I am getting contradicting
descriptions from different sources about *change* vs *move*. Perhaps you
are right that this could cause similar issues. I will probably need to
rework this to properly handle both in case *change* can be triggered in a
rename, but either way, more research is required.

I may also be double handling *move*, which could be handled more
gracefully.

I will try to fix these up in the coming weeks or months as time allows. I
welcome feedback and ideas even before I finish the patch.

Thanks as usual to the ModemManager team for building such a useful tool,
Jessy Diamond Exum

On Tue, Jan 30, 2024 at 2:44 AM Aleksander Morgado <
aleksande...@chromium.org> wrote:

> 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
>

Deprecating 3GPP2 (CDMA/EVDO) and POTS

[Aleksander Morgado]

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

[Aleksander Morgado]

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 
> 
> 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 
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
>


-- 
Aleksander