Udhcpc chokes on full load on wan

1 Like

The dhcp renew is sent to the wrong interface.

dhcp packets should only be sent to eth1, never to tun0.
If you cannot add a static route or exception of the dhcp server IP to not be sent over the tunnel, then drop the default route via the vpn and use policy routing to regulate what will be tunneled.

2 Likes
verbage

this bit of info was/is really standing out of place now... wonder if there is/was any relevance to it...

and/or

if the op runs anything special (mwan/scripts/pbr or whatnot)... (sorry did not bother to read the whole thread)...

fairly sure this is a recent behavior introduction otherwise... and potentially bugworthy... that said... surely would have surfaced by now?

OP? whats special about your install? are you HUPPING or hotplugging OPENVPN/UDHCPC or something?

Nothing special about my install, pretty much out-of-the box OpenVPN setup. I posted my network and firewall configs few posts above. The problem is if LAN clients are using full download bandwidth then DHCP (broadcast) renew fails.

Thanks,

So to summarize all DHCP renew unicast are send to wrong interface and never succeeds to get a reply so this will never work without static route.

But this does not explain broadcast case sent to eth1 which seems to get replies always but renew still fails if full bandwith in use.

we need to see a proper tcpdump... capturing ALL packets bi-directionally...

and can you put something fake instead a.a.a.a my brain doesnt handle those too well... especially when trying to differentiate broadcast

1 Like

perhaps then it is something special to the ISP install(access-network)... and you should be looking at '-B' etc. options...

we would definately have seen other cases by now were this the case...

So I have added static route to DHCP server via eth1 which now seems to work, I can see unicast request and reply with tcpdump eth1 (a.a.a.a = actual DHCP server IP):

Wed Apr 7 15:46:44 2021 daemon.notice netifd: wan (6443): udhcpc: sending renew to a.a.a.a
Wed Apr 7 15:46:44 2021 daemon.notice netifd: wan (6443): udhcpc: lease of x.x.x.x obtained, lease time 7200

I think I will be testing how this behaves when download bandwidth fully used.

The question is is there some way to get DHCP server address programmatically for adding a route? I can already get gateway address to use programmatically. I'm not sure where udhcpc gets it, I can't see it in "ifstatus wan" for example.

https://openwrt.org/docs/guide-user/network/protocol.dhcp#dhcp_client_route

2 Likes

First thanks everyone helping me with this issue.

At this point I'm trying to avoid going VPR to keep things simple so I created script /etc/udhcpc.user which is called by /usr/share/udhcpc/default.script

In this script I can use udhcpc variable serverid to add route to DHCP server for by passing VPN, like

WAN_GW=$(ip route show 0.0.0.0/0 dev eth1 | cut -d\  -f3)
ip route add $serverid via $WAN_GW

After this I have not seen DHCP renew failures / wan disconnect even if full download bandwidth is in use: unicast DHCP renew request and reply always succeeds

Also broadcast DHCP renew requests are no longer seen because unicast succeeds. It remains unknown what causes broadcast renew failures if full download bandwith is in use

Ive just got the same problem with disconnected DHCP on full load. I have tried with your script but does not seem to work for me.

Are you using VPN? Can you post your logs showing udhcpc renew and lease lines?

I see vgaetera has also added script example here

https://openwrt.org/docs/guide-user/network/protocol.dhcp#dhcp_client_route "DHCP client route" maybe you can try that?

Yes, Im using VPN on my router. Thanks for helping!

Mon Apr 12 19:08:49 2021 daemon.notice netifd: wan (2880): udhcpc: sending renew to WAN-IP
Mon Apr 12 19:11:14 2021 daemon.notice netifd: wan (2880): udhcpc: sending renew to WAN-IP
Mon Apr 12 19:12:26 2021 daemon.notice netifd: wan (2880): udhcpc: sending renew to WAN-IP
Mon Apr 12 19:13:02 2021 daemon.notice netifd: wan (2880): udhcpc: sending renew to 0.0.0.0
Mon Apr 12 19:13:24 2021 daemon.notice netifd: wan (2880): udhcpc: sending renew to 0.0.0.0
Mon Apr 12 19:13:36 2021 daemon.notice netifd: wan (2880): udhcpc: sending renew to 0.0.0.0
Mon Apr 12 19:13:40 2021 daemon.notice netifd: wan (2880): udhcpc: sending renew to 0.0.0.0
Mon Apr 12 19:13:42 2021 daemon.notice netifd: wan (2880): udhcpc: sending renew to 0.0.0.0
Mon Apr 12 19:13:43 2021 daemon.notice netifd: wan (2880): udhcpc: sending renew to 0.0.0.0
Mon Apr 12 19:13:43 2021 daemon.notice netifd: wan (2880): udhcpc: lease lost, entering init state
Mon Apr 12 19:13:43 2021 daemon.notice netifd: Interface 'wan' has lost the connection
Mon Apr 12 19:13:43 2021 daemon.notice netifd: Interface 'WGINTERFACE' has lost the connection
Mon Apr 12 19:13:43 2021 daemon.warn dnsmasq[2966]: no servers found in /tmp/resolv.conf.auto, will retry
Mon Apr 12 19:13:43 2021 daemon.notice netifd: Network device 'WGINTERFACE' link is down
Mon Apr 12 19:13:43 2021 daemon.notice netifd: wan (2880): udhcpc: sending discover
Mon Apr 12 19:13:43 2021 daemon.notice netifd: Interface 'WGINTERFACE' is now down
Mon Apr 12 19:13:43 2021 daemon.notice netifd: Interface 'WGINTERFACE' is setting up now
Mon Apr 12 19:13:44 2021 daemon.notice netifd: Interface 'WGINTERFACE' is now down
Mon Apr 12 19:13:46 2021 daemon.notice netifd: wan (2880): udhcpc: sending discover
Mon Apr 12 19:13:46 2021 daemon.notice netifd: wan (2880): udhcpc: sending select for "MY ISP-IP"
Mon Apr 12 19:13:47 2021 daemon.notice netifd: wan (2880): udhcpc: lease of "MY ISP-IP obtained, lease time 1200
Mon Apr 12 19:13:47 2021 daemon.notice netifd: Interface 'WGINTERFACE' is setting up now
Mon Apr 12 19:13:47 2021 daemon.notice netifd: Interface 'wan' is now up
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: reading /tmp/resolv.conf.auto
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using local addresses only for domain test
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using local addresses only for domain onion
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using local addresses only for domain localhost
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using local addresses only for domain local
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using local addresses only for domain invalid
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using local addresses only for domain bind
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using nameserver 10.64.0.1#53 **VPN**
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using local addresses only for domain lan
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using nameserver 2.248.248.2#53 **ISP**
Mon Apr 12 19:13:47 2021 daemon.info dnsmasq[2966]: using nameserver 2.248.248.248#53 **ISP**
Mon Apr 12 19:13:47 2021 user.notice firewall: Reloading firewall due to ifup of wan (eth0)
Mon Apr 12 19:13:47 2021 daemon.notice netifd: Interface 'WGINTERFACE' is now up
Mon Apr 12 19:13:47 2021 daemon.notice netifd: Network device 'WGINTERFACE' link is up
Mon Apr 12 19:13:47 2021 user.notice firewall: Reloading firewall due to ifup of WGINTERFACE (WGINTERFACE)
Mon Apr 12 19:13:48 2021 daemon.warn odhcpd[2078]: A default route is present but there is no public prefix on lan thus we don't announce a default route!

Yeah pretty much looks like a same problem as mine.

So maybe try creating a script as described in documentation "DHCP client route" in link above.
Also make sure that script has execute permission chmod u+x /etc/udhcpc.user

Then you need one successful renew so the script is run (you can force renew https://gergap.wordpress.com/2008/08/13/howto-renew-a-dhcp-lease/). After script has run, command ip route should list a route to WAN-IP via eth0 (eth0 = your wan interface I believe)

In my custom /etc/udhcpc.user script I also have line

logger -t udhcpc.user "Some logging message here"

so I can see in logread that script has run

1 Like

Thank you for helping.

I have now added the script from above. Im gonna stress test my network for a couple of days now and see if it works. I will update you.

Best Regards,

I have now an uptime on 2 days now and that is world record for me :slight_smile:

Thank you so much for the help!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.