I have a Netgear R7900 router and just flashed with latest operWrt firmware (version 19.07.7). The process went well and I can set up my router with new firmware, However, I cannot get an IP on the wan interface in order to connect to the internet. I tried many methods and none of them worked so far.
I am using fiber broadband from an ISP. my router is connected to a GPON terminal provided ISP. I am not aware of any specific requirement from ISP for routers. Over the time, I changed various routers (with stock firmware), such like ASUS, Linksys, Netgear. All of them worked immediately out of box. Usually, the default setting for internet connection on these routers is 'Automatic IP'. I never had to setup ISP specific instructions on the routers.
Unfortunately, this is not the case for openWrt firmware. After initially messed around the settings, I did a factory rest and changed the default router IP address to 192.167.10.1. After I connected the WAN port to my current local home network, it quickly obtain an private IP address 192.168.1.63/24, seem working correctly, but when I connected the WAN port to my GPON terminal, it simply couldn't obtain a public IP address to access the internet!
I removed all IPv6 settings and tried to restart the wan interface, and examine the system log. below is what I found:
when connect to GPON terminal, the log is:
Sat Mar 6 14:58:23 2021 daemon.notice netifd: wan (3371): udhcpc: received SIGTERM
Sat Mar 6 14:58:23 2021 daemon.notice netifd: Interface 'wan' is now down
Sat Mar 6 14:58:23 2021 daemon.notice netifd: Interface 'wan' is disabled
Sat Mar 6 14:58:23 2021 daemon.notice netifd: Interface 'wan' is enabled
Sat Mar 6 14:58:23 2021 daemon.notice netifd: Interface 'wan' is setting up now
Sat Mar 6 14:58:23 2021 daemon.notice netifd: wan (5531): udhcpc: started, v1.30.1
Sat Mar 6 14:58:23 2021 daemon.notice netifd: wan (5531): udhcpc: sending discover
Sat Mar 6 14:58:27 2021 daemon.notice netifd: wan (5531): udhcpc: sending discover
Sat Mar 6 14:58:30 2021 daemon.notice netifd: wan (5531): udhcpc: sending discover
when connected to my existing home network, with an private IP address:
Sat Mar 6 15:44:45 2021 daemon.notice netifd: wan (6766): udhcpc: received SIGTERM
Sat Mar 6 15:44:45 2021 daemon.notice netifd: Interface 'wan' is now down
Sat Mar 6 15:44:45 2021 daemon.notice netifd: Interface 'wan' is disabled
Sat Mar 6 15:44:45 2021 daemon.notice netifd: Interface 'wan' is enabled
Sat Mar 6 15:44:45 2021 daemon.notice netifd: Interface 'wan' is setting up now
Sat Mar 6 15:44:45 2021 daemon.warn dnsmasq[2211]: no servers found in /tmp/resolv.conf.auto, will retry
Sat Mar 6 15:44:45 2021 daemon.notice netifd: wan (7396): udhcpc: started, v1.30.1
Sat Mar 6 15:44:45 2021 daemon.notice netifd: wan (7396): udhcpc: sending discover
Sat Mar 6 15:44:45 2021 daemon.notice netifd: wan (7396): udhcpc: sending select for 192.168.1.63
Sat Mar 6 15:44:45 2021 daemon.notice netifd: wan (7396): udhcpc: lease of 192.168.1.63 obtained, lease time 86400
Sat Mar 6 15:44:45 2021 daemon.notice netifd: Interface 'wan' is now up
Sat Mar 6 15:44:45 2021 daemon.info dnsmasq[2211]: reading /tmp/resolv.conf.auto
Sat Mar 6 15:44:45 2021 daemon.info dnsmasq[2211]: using local addresses only for domain test
Sat Mar 6 15:44:45 2021 daemon.info dnsmasq[2211]: using local addresses only for domain onion
Sat Mar 6 15:44:45 2021 daemon.info dnsmasq[2211]: using local addresses only for domain localhost
Sat Mar 6 15:44:45 2021 daemon.info dnsmasq[2211]: using local addresses only for domain local
Sat Mar 6 15:44:45 2021 daemon.info dnsmasq[2211]: using local addresses only for domain invalid
Sat Mar 6 15:44:45 2021 daemon.info dnsmasq[2211]: using local addresses only for domain bind
Sat Mar 6 15:44:45 2021 daemon.info dnsmasq[2211]: using local addresses only for domain lan
Sat Mar 6 15:44:45 2021 daemon.info dnsmasq[2211]: using nameserver 192.168.1.1#53
Sat Mar 6 15:44:45 2021 user.notice firewall: Reloading firewall due to ifup of wan (eth0.2)
Sat Mar 6 15:44:51 2021 daemon.info dnsmasq-dhcp[2211]: DHCPINFORM(br-lan) 192.167.10.217 b4:99:ba:e9:50:3d
Can someone advice how to resolve this issue? I really appreciate any help on this topic. let me know if further information is needed.
Looks like you have a routing problem.
Based on that WAN address assignment, your router's WAN has also 192.168.1.x subnet, which is the default for OpenWrt LAN.
You can't have the same 192.168.1.x on both sides.
Either
configure ISP terminal to assign something elese for its LAN (= your OpenWrt router's WAN). E.g. to use 192.168.2.x there.
configure OpenWrt LAN to be something else than 192.168.1.x. Assign 192.168.2.1 for the router, so that then the whole LAN will be something 192.168.2.x
I get actually a bit lost there. What is serving DHCP addresses in your "current local home network" ???
The ISP terminal? Some other router?
My guess is still that you have somehow too many routers / terminals / whatever trying to claim the 192.168.1.x address space, leading to routing problems.
Thank you for quick response and sorry for the confusion.
I might change my OpenWrt IP address too much. I can certainly change to such like 192.168.2.1. But do you think this is the root cause of the issue here?
My current home network is on a 192.168.1.x subnet, with an ASUS RT-AX55 router. Netgear R7900 is just a spare router laying around my home and I flashed with openWrt firmware. Unfortunately, I changed its IP address from original 192.168.1.1 to 192.167.10.1, in order to test the wan interface by connecting to my existing home network, which is a 192.168.1.x subnet. I read the documentation of wan interface troubleshooting process, it suggested to connect openWrt router to a existing local network, to see whether wan interface is correctly setup.
I am wondering whether it is an issue with process udhcpc, which couldn't obtain IP from certain devices, such like my GPON terminal.
Sounds far-fetched. DHCP is a standardised protocol. If there is line connectivity, the dhcp client program udhcpc (part of busybox) should be able to get the address.
More likely that your ISP terminal could somehow be locked to serve certain MAC addresses. Also that is not quite that likely as you say that you have tried various routers during the years. But you might still test rebooting the ISP terminal and after the reboot connecting the OpenWrt router to it.
You might show us more of the booting kernel log. There might be clues about line connectivity.
Ps. And it sounds always suspicious that your have already messed with the IPv6 settings etc.
I disconnected the WAN cable from my functioning ASUS RT-AX55 router and plug it into the Netgear R7900 router's WAN port with openWrt. then I rebooted the R7900 router, after that, I rebooted by GPON terminal, but the issue remains. I checked the both system log and kernel log, there is no new entries since the GPON terminal rebooted. then I tried to restart the wan interface, found the same log as above, basically udhcpc is sending discover, but getting nothing in return. and nothing happened in the kernel log.
When I finally unplugged the WAN cable from R7900 and plug back to RT-AX55, The RT-AX55 immediately worked and connected to the internet.
I will try vgaetera's suggestion on DHCP messages.
A DHCP client comes online and screams out, "I want an IP address and some related information. This is my MAC address." - DISCOVER
A DHCP server replies and says, "I can offer the information you requested." - OFFER
The client says, "Yes please." - REQUEST
The server says, "Here you go." - ACKNOWLEDGE
Your posts mention that you've successfully used other routers with this ISP. One key element for DHCP to work is the MAC address. If your ISP requires you to present the same MAC address each time, that might be one possible reason why OpenWRT isn't picking up an IP address immediately.
If that's the case, one possible workaround is to use MAC address spoofing: configure OpenWRT so that its WAN MAC address is the same as the one used by the working router.
Another possible reason for the failure is that the lease time hasn't yet expired. Your ISP might not care which MAC address you present, but if the existing lease hasn't run out then the ISP's equipment might not issue the same IP address to the new MAC address as quickly as you might want.
If that's the case, one possible workaround might be to disconnect all routers from the GPON terminal and find something else to do until the DHCP Lease is up, then connect OpenWRT. If that's impractical/undesirable, then it might be possible to release the lease from the previous router. If that's possible it tells the remote equipment, "I don't need this IP address; you can return it to the pool of available addresses for the next piece of equipment to request."
From your description - RT-AX55 works immediately, but OpenWRT doesn't - my gut instinct is that there might be some sort of MAC address lock going on. Try some MAC address spoofing and see how you get on.