On 7/12/21 4:50 PM, Aleksander Morgado wrote:
The type of IP setup is decided by ModemManager; for some
plugins/protocols DHCP will be used, for some others static IP
addressing. E.g. if you're running with a QMI modem and the network
interface is configured in raw-ip, static IP addressing will be used
(as most DHCP clients don't know how to handle this type of
interfacce);
The raw IP might be why. I'm using a hacked up driver for various
reasons on a 4.14 series kernel. I have a port in progress to 5.10,
and might be able to use something more stock then.
Beware though, the DHCP setup is between the host system and the modem
exclusively, with a DHCP server running inside the modem. For those
modems where there is no DHCP server support, we default to static IP
addressing. So, in both cases, the modem will serve at connection
time, the IP settings required at that specific time, and these
settings may really come from the network itself (e.g. the IP settings
are provided by the network itself and the modem passes them down to
the host, acting as a bridge) or it may even be some settings that are
exclusively used in the host<->modem interface only (e.g. the TOBY-L4
always returns the same IP settings to use, because it acts as a
router).
Yes, it seems that DHCP is insufficient to the job. Although it'll do
the initial setup, and might do some refresh, it eventual fails in my
testing:
Tue Jul 13 06:03:08 2021 daemon.notice netifd: wwan_4 (5995): udhcpc: sending
renew to 10.142.196.140
Tue Jul 13 06:05:00 2021 daemon.notice netifd: wwan_4 (5995): udhcpc: sending
renew to 10.142.196.140
Tue Jul 13 06:05:56 2021 daemon.notice netifd: wwan_4 (5995): udhcpc: sending
renew to 0.0.0.0
Tue Jul 13 06:06:24 2021 daemon.notice netifd: wwan_4 (5995): udhcpc: sending
renew to 0.0.0.0
Tue Jul 13 06:06:39 2021 daemon.notice netifd: wwan_4 (5995): udhcpc: sending
renew to 0.0.0.0
Tue Jul 13 06:06:46 2021 daemon.notice netifd: wwan_4 (5995): udhcpc: sending
renew to 0.0.0.0
Tue Jul 13 06:06:49 2021 daemon.notice netifd: wwan_4 (5995): udhcpc: sending
renew to 0.0.0.0
Tue Jul 13 06:06:50 2021 daemon.notice netifd: wwan_4 (5995): udhcpc: sending
renew to 0.0.0.0
Tue Jul 13 06:06:50 2021 daemon.notice netifd: wwan_4 (5995): udhcpc: lease
lost, entering init state
Also, if DHCP were called manually, later after an initial static
setup, it'll recover (that one time), but that's not really what I want
to do.
Now, I'm not completely sure the network can change the IP settings of
a UE while "keeping" the corresponding bearer connected; if you ask
me, the modem should have reported a network-initiated disconnection
to the host, which ModemManager would receive, and we would have
flagged the modem as disconnected in MM.
If that's what's happening, remember that in openwrt there is no
"autoconnection" logic triggered by netifd :/ That's a big missing
piece of logic that I never got around to implement. In other words,
if the modem gets disconnected by the network, and MM flags the modem
as disconnected, netifd would not attempt to re-connect it, and at
netifd's eyes, the modem would still be connected while it isn't (as
MM would report).
Yes, indeed.
You can debug this easily, just wait for the state
where the connection is halted and see what netifd and MM both say
regarding the state of the connection. If the state reported by both
is different, you should ifdown & ifup the network interface
configured in netifd in order to reconnect.
Looks like I'll need to do this in my monitoring script. I'll retain the
DHCP, but cycle the interface. The problem is that this takes many
hours to happen, so it's tricky to test.
On a related note, I have some modifications to the OpenWrt scripts that
I'll post here, that cause MM to not give up in certain cases.
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
