Extending OpenWRt ModemManager protocol handler

[Enrico Mioso]

With this architecture it will be netifd itself that retries?

Is already there a way that provides an indication for netifd to wait some time before retrying? Trying to bring a bearer back up immediately might not be so much productive.



On Tue, 11 Jan 2022, Aleksander Morgado wrote:

> Date: Tue, 11 Jan 2022 11:17:11
> From: Aleksander Morgado <aleksander at aleksander.es>
> To: Enrico Mioso <mrkiko.rs at gmail.com>
> Cc: Peter Naulls <peter at chocky.org>,
>     "ModemManager (development)" <modemmanager-devel at lists.freedesktop.org>
> Subject: Re: Extending OpenWRt ModemManager protocol handler
> 
> Hey,
>
>>> In other words, I think the current situation isn't going to change so soon.
>>> So I was wondering if we can provide a kind of short-cut, so the protocol handler examines all bearers it finds, skipping all the modem device management.
>>> This would allow the code to be re-usable.
>>>
>>> What do you think?
>>> Would this solution be acceptable to you?
>>>
>>
>> I don't think the protocol handler should be implemented in a way that
>> touches all bearers it finds; the handler has very specific entry
>> points (setup, teardown) that receive as input argument the name of
>> the interface it applies to. Then, we match one by one that name of
>> the interface to one very specific modem based on the sysfs path
>> configured in the interface, and then we know which are the bearer
>> objects we need to look at (the ones in that specific modem). Another
>> limitation of the protocol handler is that it assumes there's only one
>> bearer connected, but that's a different story.
>>
>> If the protocol handler were a process that is running forever, we
>> could attempt to do that monitoring in all bearers, but given that we
>> have the very explicit per interface setup/teardown entry points,
>> we're a bit limited. Ideally, MM and netifd would be in sync without
>> any other additional process. If we had a way to tell netifd the
>> underlying network device is really disconnected (is there any way to
>> do that?), then we could even setup some hotplug scripts in MM itself
>> or something like that.
>>
>
> Talked to jow in #openwrt-devel about this, and I think I have a clean
> way to solve this issue. Any process can notify netifd that the
> underlying network is really disconnected, basically like this:
>  . /lib/netifd/netifd-proto.sh
>  proto_init_update $ifname 0; proto_send_update
>
> ifname there is the name of the netifd interface.
>
> What we could do is setup event scripts in ModemManager to be executed
> upon some specific events; e.g. on bearer connection and on bearer
> disconnection. ModemManager would call those scripts as appropriate,
> e.g. providing additional info as input arguments to the script. So,
> when a bearer gets disconnected, MM could call every script in
> /etc/ModemManager/bearer-disconnect.d/ passing as arguments the modem
> dbus path and the bearer dbus path.
>
> The openwrt package could provide a custom script in
> bearer-disconnect.d that would:
> * find the ifname applicable to the modem object
> * run the proto update sequence as above
>
> What do you think of having something like that?
>
> We already support custom scripts for when FCC unlock is needed,
> having event scripts for bearer connection/disconnection events would
> probably be fine also. They could also be used e.g. to setup/cleanup
> iptables rules on the specific connected interface and such, something
> that is currently not really possible because the user may not know
> which is the exact net interface of the modem being connected (even
> less when using multiplexing as net interfaces are created on the
> fly).
>
> -- 
> Aleksander
> https://aleksander.es
>