LTE Interface: UQMI and WAN interface DHCP renewal issue

Installing and Using OpenWrt
1

Hello,

I opened a bug on the OpenWRT bugtracking system but I'm quickly asking here if someone is also having this problem. The bug reference is here

I’m facing a problem on two routers WG3526 (Modem EC-25) and D-Link DWR921 (Model Broadmobi BM806). My 4G provider is Free Mobile a French mobile provider.

Every 12 hours my ISP change the IP of the interface and the DHCP-Client still get the old IP Address even if “uqmi -d /dev/cdc-wdm0 –get-current-settings” display the new valid ip address.

  • “uqmi -d /dev/cdc-wdm0 –get-current-settings” give IP “B”.

  • “udhcpc” still attribute IP “A” to the wwan0 interface resulting in an nonoperational interface until I restart it (ubus call network.interface.wwan down / ubus call network.interface.wwan up).

  • After an interface restart “udhcpc” attribute IP “B” to the wwan0 interface.

This problem happen exactly every 12 hours the duration of the dhcp lease time on the interface wwan0.

I don’t know if it’s a bug in the firmware of both modems or a problem within OpenWRT.

I used MWAN3 to monitor the interface the past few days and the script try to restart the interface when it went down. Sometime it stay blocked on the "pin-verify" but it's another story.

Below the log showing the timing of the problem (exactly every 12 hours the dhcp lease time)
Fri Aug 28 22:23:32 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0
Fri Aug 28 22:23:34 CEST 2020 - Action:ifdown - Interface:wwan - Device:
Fri Aug 28 22:23:40 CEST 2020 - Action:disconnected - Interface:wwan - Device:wwan0
Fri Aug 28 22:23:42 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0
Fri Aug 28 22:23:43 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0

Sat Aug 29 10:23:28 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0
Sat Aug 29 10:23:30 CEST 2020 - Action:ifdown - Interface:wwan - Device:
Sat Aug 29 10:23:37 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0
Sat Aug 29 10:23:38 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0

Sat Aug 29 22:23:31 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0
Sat Aug 29 22:23:34 CEST 2020 - Action:ifdown - Interface:wwan - Device:
Sat Aug 29 22:23:40 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0
Sat Aug 29 22:23:41 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0

Sun Aug 30 10:23:32 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0
Sun Aug 30 10:23:34 CEST 2020 - Action:ifdown - Interface:wwan - Device:
Sun Aug 30 10:23:42 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0
Sun Aug 30 10:23:43 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0

Sun Aug 30 22:23:30 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0
Sun Aug 30 22:23:32 CEST 2020 - Action:ifdown - Interface:wwan - Device:
Sun Aug 30 22:23:39 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0
Sun Aug 30 22:23:40 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0

Below another view more detailed showing the result of the bug.
My script (see below) log stats of interface before and after interface restart. It also compare the DHCP lease obtained and the UQMI parameters.
There is one thing missing in this log it's the DHCP state of the interface begore going down. The DHCP lease is properly renewed with the old IP address even if " uqmi -d /dev/cdc-wdm0 –get-current-settings" display properly the new IP address given by the ISP.

Sun Aug 30 22:23:30 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0
calling: ubus call network.interface.wwan down
{
        "pdp-type": "ipv4",
        "ip-family": "ipv4",
        "mtu": 1500,
        "ipv4": {
                "ip": "10.92.174.236",
                "dns1": "212.27.40.240",
                "dns2": "212.27.40.241",
                "gateway": "10.92.174.237",
                "subnet": "255.255.255.248"
        },
        "ipv6": {

        },
        "domain-names": {

        }
}
wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.41.208.219  P-t-P:10.41.208.219  Mask:255.255.255.248
          inet6 addr: fe80::b6a7:6397:3697:50fa/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:69814179 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28061149 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:87843195331 (81.8 GiB)  TX bytes:5812847812 (5.4 GiB)

Sun Aug 30 22:23:32 CEST 2020 - Action:ifdown - Interface:wwan - Device:
calling: ubus call network.interface.wwan down
"Out of call"
wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:69814179 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28061150 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:87843195331 (81.8 GiB)  TX bytes:5812847876 (5.4 GiB)

calling: ubus call network.interface.wwan up
"Out of call"
wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:69814179 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28061150 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:87843195331 (81.8 GiB)  TX bytes:5812847876 (5.4 GiB)

calling: ubus call network.interface.wwan up
{
        "pdp-type": "ipv4",
        "ip-family": "ipv4",
        "mtu": 1500,
        "ipv4": {
                "ip": "10.92.174.236",
                "dns1": "212.27.40.240",
                "dns2": "212.27.40.241",
                "gateway": "10.92.174.237",
                "subnet": "255.255.255.248"
        },
        "ipv6": {

        },
        "domain-names": {

        }
}
wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.92.174.236  P-t-P:10.92.174.236  Mask:255.255.255.248
          inet6 addr: fe80::b6a7:6397:3697:50fa/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:69814181 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28061156 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:87843195969 (81.8 GiB)  TX bytes:5812848916 (5.4 GiB)

Sun Aug 30 22:23:39 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0
Sun Aug 30 22:23:40 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0

Below the script used to monitor the interface in MWAN3.

#!/bin/sh
#
# This file is interpreted as shell script.
# Put your custom mwan3 action here, they will
# be executed with each netifd hotplug interface event
# on interfaces for which mwan3 is enabled.
#
# There are three main environment variables that are passed to this script.


#
# $ACTION
#      <ifup>         Is called by netifd and mwan3track
#      <ifdown>       Is called by netifd and mwan3track
#      <connected>    Is only called by mwan3track if tracking was successful
#      <disconnected> Is only called by mwan3track if tracking has failed
# $INTERFACE	Name of the interface which went up or down (e.g. "wan" or "wwan")
# $DEVICE	Physical device name which interface went up or down (e.g. "eth0" or "wwan0")

Date=`date`
echo "$Date - Action:$ACTION - Interface:$INTERFACE - Device:$DEVICE" >> /tmp/interface.log
if [ $ACTION = "ifdown" ]
then
     if [ $INTERFACE = "wwan" ]
     then
          echo "calling: ubus call network.interface.wwan down"  >> /tmp/interface.log
          uqmi -d /dev/cdc-wdm0 --get-current-settings >> /tmp/interface.log
          ifconfig wwan0 >> /tmp/interface.log
          ubus call network.interface.wwan down
          sleep 3
          echo "calling: ubus call network.interface.wwan up"  >> /tmp/interface.log
          uqmi -d /dev/cdc-wdm0 --get-current-settings >> /tmp/interface.log
          ubus call network.interface.wwan up
          ifconfig wwan0 >> /tmp/interface.log
     fi
fi
2

LTE modems are meant to be managed by QMI, MBIM or AT commands. The DHCP server is a modem firmware feature which is bound to be imperfect. It forwards an address with a lifetime bound to the point-to-point tunnel it is assigned to. This is unpredictable. It will fail every time the tunnel goes down and is re-established. You can obiously try to work around that failure by detecting it faster, like you are trying to do. But the simple and real fix is to drop DHCP and instead use the native management protoocol, which will send a notification whenever the tunnel is re-established and the address changes. The managing application will have to subscribe to these notifications.

AFAIK, ModemManager is the only implementation currently supporting such notifications in OpenWrt.

Another reason not to use DHCP with LTE modems is that it's not used by Windows. This means that the feature, if it exists, hardly is tested at all. IMHO Linux systems should try to behave as closely to Windows as possible for this reason. All modem firmwares are buggy. Real world testing is essential. Vendor lab testing appears to be non-existant.

2 Likes
3

Thanks for your reply.

Tested modemmanager and for now I also have the same instabilities.
I need to trace a bit the source of the problem to understand.

Do you have a reference somewhere with a detailed documentation on all parameters ? There is very basic exemples on the documentation of OpenWrt for now.

4

found a solution to the problem?

5

I'm using "modemmanager" and mwan3 to reload the interface when it goes down after 12h.
It's not perfect and super stable but it do the job.

6

could you share your mwan3 configuration and related scripts that you had to prepare.

Thank you