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 <
aleksandermj at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20240327/523912e9/attachment.htm>