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 <aleksan...@aleksander.es>
To: Enrico Mioso <mrkiko...@gmail.com>
Cc: Peter Naulls <pe...@chocky.org>,
"ModemManager (development)" <modemmanager-devel@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
