RUTX50 dhcp mobile problem after firmware upgrade

dstrwpd · March 14, 2025, 2:22pm

Hello, I have two RUTX50 with the same problem after updating to RUTX_R_00.07.13.1.

They were running perfectly fine before the update.

1277 Fri Mar 14 15:00:22 2025 daemon.notice netifd: mob1s1a1_4 (19924): udhcpc: broadcasting renew
1278 Fri Mar 14 15:00:25 2025 daemon.notice netifd: mob1s1a1_4 (19924): udhcpc: broadcasting renew
1279 Fri Mar 14 15:00:28 2025 daemon.notice netifd: mob1s1a1_4 (19924): udhcpc: broadcasting renew
1280 Fri Mar 14 15:00:31 2025 daemon.notice netifd: mob1s1a1_4 (19924): udhcpc: broadcasting renew
1281 Fri Mar 14 15:00:35 2025 daemon.notice netifd: mob1s1a1_4 (19924): udhcpc: lease lost, entering init state
1282 Fri Mar 14 15:00:35 2025 daemon.notice netifd: Interface ‘mob1s1a1_4’ has lost the connection
1283 Fri Mar 14 15:00:35 2025 daemon.warn dnsmasq[2165]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
1284 Fri Mar 14 15:00:35 2025 daemon.notice netifd: mob1s1a1_4 (19924): udhcpc: broadcasting discover

after a modem reboot its magically working again:

1408 Fri Mar 14 15:10:47 2025 daemon.notice netifd: mob1s1a1_4 (29386): udhcpc: started, v1.34.1
1409 Fri Mar 14 15:10:47 2025 daemon.notice netifd: mob1s1a1_4 (29386): udhcpc: broadcasting discover
1410 Fri Mar 14 15:10:47 2025 daemon.notice netifd: mob1s1a1_4 (29386): udhcpc: broadcasting select for 172.20.2.133, server 172.20.2.134
1411 Fri Mar 14 15:10:47 2025 user.notice firewall: Reloading firewall due to ifup of mob1s1a1 (wwan0)
1412 Fri Mar 14 15:10:47 2025 daemon.notice netifd: mob1s1a1_4 (29386): udhcpc: lease of 172.20.2.133 obtained from 172.20.2.134, lease time 7200

everything is pretty much standard:

dstrwpd · March 14, 2025, 2:37pm

tcpdump looks fine, except it is reaching the lan interface too?

15:30:40.795445 qmimux0 Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
10.5.0.201.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:00:00:00:00:00, length 300, xid 0x216da807, Flags [none] (0x0000)
Client-IP 10.5.0.201
Client-Ethernet-Address 00:00:00:00:00:00
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Request
MSZ (57), length 2: 576
Parameter-Request (55), length 8:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
Hostname (12), length 6: “RUTX50”
Vendor-Class (60), length 12: “udhcp 1.34.1”
15:30:40.797421 qmimux0 In IP (tos 0x0, ttl 255, id 22, offset 0, flags [none], proto UDP (17), length 314)
10.5.0.202.67 > 10.5.0.201.68: [udp sum ok] BOOTP/DHCP, Reply, length 286, xid 0x216da807, Flags [none] (0x0000)
Client-IP 10.5.0.201
Your-IP 10.5.0.201
Server-IP 10.5.0.202
Client-Ethernet-Address 00:00:00:00:00:00
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
Subnet-Mask (1), length 4: 255.255.255.252
Default-Gateway (3), length 4: 10.5.0.202
Domain-Name-Server (6), length 8:
Hostname (12), length 6: “RUTX50”
Lease-Time (51), length 4: 7200
Server-ID (54), length 4: 10.5.0.202
15:30:40.797600 br-lan Out IP (tos 0x0, ttl 254, id 22, offset 0, flags [none], proto UDP (17), length 314)
10.5.0.202.67 > 10.2.20.138.68: [udp sum ok] BOOTP/DHCP, Reply, length 286, xid 0x216da807, Flags [none] (0x0000)
Client-IP 10.5.0.201
Your-IP 10.5.0.201
Server-IP 10.5.0.202
Client-Ethernet-Address 00:00:00:00:00:00
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
Subnet-Mask (1), length 4: 255.255.255.252
Default-Gateway (3), length 4: 10.5.0.202
Domain-Name-Server (6), length 8:
Hostname (12), length 6: “RUTX50”
Lease-Time (51), length 4: 7200
Server-ID (54), length 4: 10.5.0.202

OmniTek · March 25, 2025, 1:49pm

Hi,
I have a similar issue with RUT240 and RUT241.
Found anything where it’s coming from ?
Thanks !

dstrwpd · March 25, 2025, 2:35pm

not yet. seems we need to get in contact with direct support.

OmniTek · March 26, 2025, 11:19am

This really looks like it :

github.com/openwrt/openwrt

udhcpc: no MSG_DONTROUTE when sending packet

master ← adiov:udhcpc-no-dontrout

opened 08:04PM - 06 Jun 18 UTC

adiov

+11 -0

**TL;DR** Don't set `MSG_DONTROUTE` when sending packets, otherwise it forces th…e client into non-compliant behaviour that is rejected by properly configured servers, thus creating unnecessary interruptions and connection breakages. This patch reverts a [change made in Sep 2017 which introduced `MSG_DONTROUTE` flag](http://lists.busybox.net/pipermail/busybox-cvs/2017-September/037402.html) to prevent udhcpc from reaching out to servers on a different subnet. That change violates [RFC2131 ](https://tools.ietf.org/html/rfc2131)by forcing fully configured clients, who got their configurations through an offer relayed by a DHCP relay, from renewing through a unicast request directly to the DHCP server, resulting in the client resorting to boradcasting lease extension requests instead of unicasting them, further breaking [RFC2131](https://tools.ietf.org/html/rfc2131). The problem with `MSG_DONTROUTE` appears when talking to a properly configured DHCP server that rejects non-compliant requests. Such server will reject lease extension attempts sent via broadcast rather than unicast, as is the case with Finnish ISPs Telia and DNA as well as Estonian ISP Starman. Once the lease expires without renewal, udhcpc enters init mode, taking down the interfaces with it, and thus causing interruption on every lease expiry. On some ISPs (such as the ones mentioned above) that can be once every 10-20 minutes. The interruptions appear in the logs as such: ``` udhcpc: sending renew to x.x.x.x udhcpc: send: Network unreachable udhcpc: sending renew to 0.0.0.0 udhcpc: sending renew to 0.0.0.0 ... udhcpc: lease lost, entering init state Interface 'wan' has lost the connection Interface 'wan' is now down Network alias 'eth0' link is down udhcpc: sending select for y.y.y.y udhcpc: lease of y.y.y.y obtained, lease time 1200 Network alias 'eth0' link is up Interface 'wan' is now up ``` This keeps repeating every lease period, breaking VPN connections, SSH sessions, etc. During lease extension, a fully configured client should be able to [reach out to the server from which it received the lease for extension](https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents), regardless in which network it is; that's up to the gateway to find. This patch ensures that. It's worth noting that this correct behaviour exists in every mainstream DHCP client I checked, including the [Internet System Consortium's](https://fossies.org/linux/dhcp/client/dhclient.c). **P.S.** I've made the change locally, built it, and have been testing it on my Archer C7 v2 for quite a while. This part of the logs from half an hour ago shows it's working as expected without interruption: ``` Wed Jun 6 22:39:07 2018 daemon.notice netifd: wan (1299): udhcpc: sending renew to x.x.x.x Wed Jun 6 22:39:07 2018 daemon.notice netifd: wan (1299): udhcpc: lease of y.y.y.y obtained, lease time 1200 Wed Jun 6 22:49:07 2018 daemon.notice netifd: wan (1299): udhcpc: sending renew to x.x.x.x Wed Jun 6 22:49:07 2018 daemon.notice netifd: wan (1299): udhcpc: lease of y.y.y.y obtained, lease time 1200 Wed Jun 6 22:59:07 2018 daemon.notice netifd: wan (1299): udhcpc: sending renew to x.x.x.x Wed Jun 6 22:59:07 2018 daemon.notice netifd: wan (1299): udhcpc: lease of y.y.y.y obtained, lease time 1200 ```

Unfortunately, I don’t know how to implement this solution into my RUT240 and 241.
If someone knows a way to do it, I’d be glad to give it a try.

dstrwpd · March 26, 2025, 11:33am

Today I did a third upgrade, and it started to have same problem. Would be good to have a official answer here.

dstrwpd · March 26, 2025, 11:36am

yes looks pretty much like this problem. I wonder why it is not working anymore. Maybe it broke after a change from Teltonika to the code.

OmniTek · March 26, 2025, 4:12pm

It seems this solution may work, depending on your provider I suppose :

Log in to your router via CLI (more details here: Command Line Interfaces)
Run the command vi /etc/config/network
Locate config interface 'mob1s1a1' and press “i” to enter edit mode
Add the line option dhcp '0' under the mobile configuration section
Press “Esc”, then type :wq and hit Enter to save and close the file

Marija · April 4, 2025, 9:24am

Hello @dstrwpd @OmniTek,

Could you please confirm if the provided solution helped resolve your issue, or if you still require any assistance with it?

Best regards,

dstrwpd · April 4, 2025, 10:02am

It helps, as long as you do not change interface settings afterwards, because its not a static configuration. It was only helping for those 3 devices I have upgraded, and as long as you do not change any configuration.
But we have 60 other routers line up for a firmware upgrade, and im not willing to take this temporary solution.
So please add this setting to GUI to make it a static configuration.

Marija · April 4, 2025, 10:33am

@dstrwpd,

Thank you for the information. Our developers have been informed about this issue, and they should implement a fix in future firmware releases. Unfortunately, I don’t have an exact date for when this will happen.

We appreciate your understanding and patience.

Best regards,

Marija · April 4, 2025, 12:23pm

@dstrwpd, I’ve sent you a form to fill out. Once completed, I will reach out to you privately regarding the 60 other routers. For the ticket ID, please use “12803”.
Thank you!

Best regards,

OmniTek · April 7, 2025, 10:04am

Hello,
It’s a working workaround, but it’s only a temporary solution.
My technicians colleagues won’t work with SSH and CLI, it’s not their job, and I can’t reconfigure every router we install.
Also, it works with our current provider, but if we change maybe it won’t work with another.
Lastly, it’s a 3G feature that our provider is planning to stop.
Best would be to fix the issue by sending DHCP renew using unicast, as it should be.
Thanks for fixing it as soon as you can.
Best regards