Hello, guys!
I have read alot on this topic(here on the forum, and other sources), even read the RFC specs and the problem is still there. Tryed many, many things (adding different options in the DHCP request headers).
The problem is that my ISP is using a DHCP server on another subnet than where gateway is on. Obtaining a lease on IFUP succeeds every time, but when it's time for renewal - it never happens.
I'm getting
udhcpc: sending renew to xx.xx.xx.xx
udhcpc: sending renew to xx.xx.xx.xx
udhcpc: sending renew to xx.xx.xx.xx
udhcpc: sending renew to 0.0.0.0
udhcpc: sending renew to 0.0.0.0
udhcpc: sending renew to 0.0.0.0
udhcpc: lease lost, entering init state
To my understanding, the problem seems to be solved here - udhcpc: no MSG_DONTROUTE when sending packet but I can't find these lines of code in the current build. Can someone point me in the right direction? How to solve my problem?
Any additional info will be provided on demand!
In a near default configuration, you shouldn't see this happening unless there is an issue with the ISP side of the equation.
What version of OpenWrt are you running? What packages have you installed/upgraded (if any)? What have you changed in your configuration relative to the defaults?
Please run the following commands (copy-paste the whole block) and paste the output here, using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have
ubus call system board
cat /etc/config/network
cat /etc/config/dhcp
cat /etc/config/firewall
This is the config I'm currently using. Some thing may seem inconsistent(as VLAN id's) as I edited them for forum purposes. Packages are up to date, both ship versions and updated versions do the same.
You've got a bunch of stuff going on with the WAN that is far from default.
Are all of these things required for your service (such as the send opts, client and vendor id, etc.). And you have the wan in a bridge (br-wan) with yet other parameters set. Are these things configured per your ISPs specifications?
Normally, the wan is rather simple -- just eth0.x and DHCP client. Is this an option for your ISP? If so, that is the first thing I would try -- basically just setting your WAN back to a near default state.
This part in the dhcp server config looks strange. Almost like you are trying to configure your router to be the only DHCP server in wan, where the ISP should provide DHCP. ????
(typically the wan side has "option ignore 1" , as the local dnsmasq should not try to override the ISP's DHCP server (without knowledge what addresses the ISP wants to give toyou)
Okay, to be 100% sure, I have done a reset on my device and did the config from scratch, without reusing anything and adding only the required options.
To your question - yes sendopts, client and vendor ID are required (some of them are used to hide my device, because I don't want my provider to know what I'm using). BUT, believe me - I have tried without them - same thing. Only broadcast flag is required to get IP address.
Subnet? or VLAN?
another subnet, FOR EXAMPLE my Internet Gateway is 10.0.214.133 and the DHCP server is hosted on 192.168.55.32.
I'd recommend not complicating the situation by adding any options that are not mandatory for the router to get online with the ISP. You can do whatever you want in terms of trying to hide what you're using (I'm not sure why you are concerned about this or what benefit it has for your use, but to each their own). By changing only the absolute minimum items in your configuration, you will reduce the variables to a more manageable number.
It would make sense to post updated config files.
Are you running double NAT? Or DHCP relay? Often, the DHCP server is on the same network as the gateway. Can you draw a picture of your network topology and indicate where the DHCP server is, where this gateway is, and where the ISP network ends and yours begins?
Just chiming it, but I am using TP-LINK Archer C6 and am not sure when exactly, but I started getting the same issue at more or less at the same time every night - at 1-2AM.
What I see in the logs precisely:
Tue Feb 15 23:17:08 2022 daemon.notice netifd: wan (3815): udhcpc: lease of <WANIP> obtained, lease time 600
Tue Feb 15 23:22:08 2022 daemon.notice netifd: wan (3815): udhcpc: sending renew to <GATEWAY>
Tue Feb 15 23:24:38 2022 daemon.notice netifd: wan (3815): udhcpc: sending renew to <GATEWAY>
Tue Feb 15 23:25:53 2022 daemon.notice netifd: wan (3815): udhcpc: sending renew to <GATEWAY>
Tue Feb 15 23:26:30 2022 daemon.notice netifd: wan (3815): udhcpc: sending renew to 0.0.0.0
Tue Feb 15 23:26:48 2022 daemon.notice netifd: wan (3815): udhcpc: sending renew to 0.0.0.0
Tue Feb 15 23:26:57 2022 daemon.notice netifd: wan (3815): udhcpc: sending renew to 0.0.0.0
Tue Feb 15 23:27:01 2022 daemon.notice netifd: wan (3815): udhcpc: sending renew to 0.0.0.0
Tue Feb 15 23:27:03 2022 daemon.notice netifd: wan (3815): udhcpc: sending renew to 0.0.0.0
Tue Feb 15 23:27:04 2022 daemon.notice netifd: wan (3815): udhcpc: sending renew to 0.0.0.0
Tue Feb 15 23:27:04 2022 daemon.notice netifd: wan (3815): udhcpc: lease lost, entering init state
Tue Feb 15 23:27:04 2022 daemon.notice netifd: Interface 'wan' has lost the connection
After that, there is pretty much nothing happening, even if I try to restart the router or certain services, it doesn't really help.
At some point, I receive this:
Tue Feb 15 23:41:55 2022 daemon.notice netifd: wan (3815): udhcpc: sending select for <WANIP>
Tue Feb 15 23:41:56 2022 daemon.notice netifd: wan (3815): udhcpc: lease of <WANIP> obtained, lease time 600
Tue Feb 15 23:41:56 2022 daemon.notice netifd: Interface 'wan' is now up
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: reading /tmp/resolv.conf.auto
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using local addresses only for domain test
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using local addresses only for domain onion
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using local addresses only for domain localhost
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using local addresses only for domain local
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using local addresses only for domain invalid
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using local addresses only for domain bind
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using local addresses only for domain lan
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using nameserver <NSIP>#53
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using nameserver <NSIP>#53
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using nameserver <NSIP>#53
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using nameserver <ISPNS>#53
Tue Feb 15 23:41:56 2022 daemon.info dnsmasq[5517]: using nameserver <ISPNS>#53
Tue Feb 15 23:41:56 2022 user.notice firewall: Reloading firewall due to ifup of wan (eth0.2)
After that, the internet is back up and I am able to access everything. Prior to these issues, my configuration was not changed. I have also contacted my ISP regarding the issue and they are not even replying anything yet besides having sent me different DNS IPs to try when the internet is down, which doesn't really help anything at all.
Your ISP (or whatever is upstream of your router) is issuing 10 minute leases. This seems like it is likely an ISP issue -- only a few ISPs actually use such short lease times, possibly indicating that they are having problems with their IP allocations.
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config rule
option name 'Support-UDP-Traceroute'
option src 'wan'
option dest_port '33434:33689'
option proto 'udp'
option family 'ipv4'
option target 'REJECT'
option enabled 'false'
config include
option path '/etc/firewall.user'
Are you running double NAT? Or DHCP relay?
I personally don't run anything, my ISP does, but I can't figure exactly how it works. There are many IP ranges, owned by the ISP, they all have different default GW (DHCP server gives them depending on client's MAC addr.). By running traceroute, my exit point is the DHCP server IP(I can't see my gateway, although I can ping it). One more thing to say - there is proprietary router that I'm trying to replace, so it's impossible to ask my provider this and that(also, that's why I'm using sendopts and so on..).
The way you've defined the wan interface and device doesn't look right to me. If you need eth0.44 to be tagged, you should have that tagged in the switch config. You should leave VLAN 2 alone, and then add vlan44.
Hm, this is strange, I didn't noticed that. In the web UI, VLAN 1 is dedicated for ports 2,3,4,5 and VLAN 44 is tagged on CPU port and untagged on 1st port. But, this is "physical" layer, not really my problem. Traffic is flowing and I do have Internet connection. Please read the first post.
Take a look at my LuCI config:
If the WAN port is working with untagged ethernet, that means you can stick with VLAN ID 2... there is no need to use VLAN 44 in that circumstance since the ISP clearly doesn't require it.
This was also tried - in the moment I change VLAN id from 44 to something else - traffic stops to flow and there's no Internet connection. In the original router, there is a setting for VLAN.
I'm starting to get very disappointed and I may try another router OS (maybe on x86 platform). OpenWRT forum is the third place where I ask my question and nothing.
You have the VLAN untagged on the port, which means that, by definition, there is no VLAN tag requirement and therefore no specific requirement about a VLAN ID.
OpenWrt generally works best with VLANs 1 and 2 intact (you can always add additional ones). But it is critical that your VLAN definitions are consistent throughout your OpenWrt config. I would suspect that the reason it fails to work is that things are not consistent.
Resetting the router to defaults and leaving the VLANs as they are would be the best option.
Did this VLAN config indicate that the WAN port actually required the use of tagged frames with VLAN ID 44?
Did this VLAN config indicate that the WAN port actually required the use of tagged frames with VLAN ID 44?
No! I will try with another VLAN id and report back.
My problem is DHCP renewal and I do believe that it is far from configuring VLAN id's and interfaces. Tcpdump shows that request is being made to the server when it's trying to renew(maybe the server can't see it?).
@psherman Yes, you were right. VLAN 2 is working the same as VLAN 44. Taking my words back, maybe I've messed the config when trying. But, even with VLANs fixed, the same problem still exists!
