Static vs DHCP setups from ModemManager in OpenWrt

[Peter Naulls]

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.