Setting DHCP client options for modem / wan

Hi,
I am having issues with ip addresses sometimes not renewing on WAN (Quectel Modem) and was going to try and shorten the lease time to see if it would improve it. For the ethernet wan this is straightforward as you can do

uci set network.WAN.proto='dhcp'
uci set network.WAN.sendopts='lease:300' # (or whatever you want)

But for the modem wan, it doesn't have a UCI interface since it is a " Virtual dynamic interface (DHCP client)" (according to the web interface).
Screenshot from 2021-11-08 15-16-42

What is the best way around this? I know I could add the option manually by editing /lib/netifd/proto/dhcp.sh, by adding
append dhcpopts "-x lease:120"
To proto_dhcp_setup() just before proto_export
This doesn't seem like an ideal method of doing it though.

Would be great to solve this as it seems like failing to renew ip address is the cause of some connection dropouts I'm experiencing, since running udhcpc manually always resolves it again.

Josh

By design, the dhcp client doesn’t get to specify things like lease time. That is the responsibility of the dhcp server.

There are very few parameters that the dhcp client can send to the server - basically just the client ID.

What is it that you are trying to achieve?

Edit: to be clear, when I said by design, that refers to the dhcp specification. Openwrt implements against the dhcp spec.

I was trying to find a way to modify the parameter passed to udhcpc - specifically the -x option

  -x OPT:VAL      Include option OPT in sent packets (cumulative)
                        Examples of string, numeric, and hex byte opts:
                        -x hostname:bbox - option 12
                        -x lease:3600 - option 51 (lease time)
                        -x 0x3d:0100BEEFC0FFEE - option 61 (client id)
                        -x 14:'"dumpfile"' - option 14 (shell-quoted)

It looks like clients are able to request a lease time for it's ip address (which may be ignored, but it can at least request the lease time) as per rfc2132. To my understanding this is what the -x option is trying to achieve. I was trying to see if reducing the lease time would help work around an apparent bug with the modem / qmi stack where sometimes a request to renew it's ip address it not made until a few hours after it should've been.

I would imagine that your ISP will simply ignore the parameter.

I'd contact the ISP tech support to find out if there are any issues with the DHCP renewal process. You can actually monitor it by looking at the logs from your router;

logread | grep dhcpc

Thanks for your response. In our case it does seem to have some effect, shown by the following logs:

Mon Nov  8 14:58:34 2021 daemon.notice netifd: modem_4 (4685): udhcpc: started, v1.33.1
Mon Nov  8 14:58:34 2021 user.notice firewall: Reloading firewall due to ifup of modem (wwan0)
Mon Nov  8 14:58:34 2021 daemon.notice netifd: modem_4 (4685): udhcpc: sending discover
Mon Nov  8 14:58:34 2021 daemon.notice netifd: modem_4 (4685): udhcpc: sending select for 10.146.161.188
Mon Nov  8 14:58:34 2021 daemon.notice netifd: modem_4 (4685): udhcpc: lease of 10.146.161.188 obtained, lease time 122
...
Mon Nov  8 16:34:20 2021 daemon.notice netifd: modem_4 (4685): udhcpc: sending renew to 10.146.161.189
Mon Nov  8 16:34:20 2021 daemon.notice netifd: modem_4 (4685): udhcpc: lease of 10.146.161.188 obtained, lease time 122
Mon Nov  8 16:35:22 2021 daemon.notice netifd: modem_4 (4685): udhcpc: sending renew to 10.146.161.189
Mon Nov  8 16:35:22 2021 daemon.notice netifd: modem_4 (4685): udhcpc: lease of 10.146.161.188 obtained, lease time 122
Mon Nov  8 16:36:23 2021 daemon.notice netifd: modem_4 (4685): udhcpc: sending renew to 10.146.161.189
Mon Nov  8 16:36:23 2021 daemon.notice netifd: modem_4 (4685): udhcpc: lease of 10.146.161.188 obtained, lease time 122

The "sending renew..." outputs approx every 120s, which was the lease time specified (obviously this is a bit of a silly value to use but was just using it as a test). Ideally this wouldn't be necessary though - we can try to contact ISP to see what they say (though they are a phone company rather than traditional ISP).

Part of me is also wondering whether it is related to the following unresolved bugs:
[1], [2]

This IP address (10.146.161.188) is an RFC1918 address and potentially suggests that your modem is actually a modem+router combo and that you are not renewing from the ISP but rather from the modem device itself. That is unless the ISP is actually providing RFC1918 private IP addresses or CGNAT rather than a public IP address.

Yes it is a modem+router (generic MT7628-based, with a Quectel EC-25 modem). Is there any way for me to tell who is issuing the IP - whether it is the modem or the mobile network giving me a private IP (which I think is normal practice for mobile networks)?

See if the modem has information about its own wan/uplink ip. And also look to see if the modem has a bridge mode feature which will make the device purely a modem and not do any routing - it will then pass the isp provided ip directly to your router.

Hi

You can run uqmi -d /dev/cdc-wdm0 --get-current-settings, then you can see what IP-address your cellular provider has assign to you.

I think the DHCP lease is just between OpenWrt and the modem. As long as you have your cellular connection up you will keep the same IP-address. If your modem will re-connect it will get a new IP-address.

Hi,
It seems to get the same result for both:

root@OpenWrt:/mnt/mp_log2# ifconfig wwan0
wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.149.255.95  P-t-P:10.149.255.95  Mask:255.255.255.192
          inet6 addr: fe80::6956:c7b0:5a86:d155/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:9088 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25516 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:702862 (686.3 KiB)  TX bytes:1619898 (1.5 MiB)

root@OpenWrt:/mnt/mp_log2# uqmi -d /dev/cdc-wdm0 --get-current-settings
{
        "pdp-type": "ipv4",
        "ip-family": "ipv4",
        "mtu": 1500,
        "ipv4": {
                "ip": "10.149.255.95",
                "dns1": "82.132.254.2",
                "dns2": "82.132.254.3",
                "gateway": "10.149.255.96",
                "subnet": "255.255.255.192"
        },
        "ipv6": {

        },
        "domain-names": {

        }
}

What I cannot tell is whether the modem firmware is somehow translating this address to another one given by the ISP at a lower level.