NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
IoT network not DHCPing anymore
Let me preface this by saying I live in Texas, where our power grid goes down as often as the sun does. With that being said, last night there was a strong gust of wind that knocked out my power for about 10 seconds. My AT&T modem, Orbi router, and network switch are all on UPSs (because the power goes out THAT much) stayed online with no problem. All of my smart switches (mostly Kasa HS200) dropped offline and haven't been able to reconnect yet. All of my echo devices have dropped off line as well. I cannot get them reconnected to the IoT network no matter what I try.
When I try to connect my echo show to the IoT network (VLAN3), it says it cannot get a DHCP address. When I try to connect my phone to that network, I get the same-ish error (error is "cannot get an IP address"). If I switch my phone and echo show to the main network (VLAN1) they both connect with no problems.
I have tried turn of DHCP for that VLAN, as well as turning all DHCP off for all VLANs. I've even unplugged the router, modem, and satellite for 10 minutes with the same error coming up once everything is back online.. I've noticed that in the UI all of my switches are pulling a 192.168.1.80 IP address. All of them. VLAN3 should be 192.168.30.xx range. My two Nest thermostats are pulling 169.254.xxx.xxx IPs as well, so I know DHCP isn't kicking in at all.
Any thoughts of what else I should try, short of resetting to factory defaults?
Router: SXR80
Firmware: V4.2.3.102
Satilite: SXS80
Firmware: V4.2.3.102
3 Replies
Yes, I did try doing that as well. My final fix was to fully shut down everything for an hour. No internet, no router, no anything for a full hour. Once plugging everything back in, DHCP started to work again. This is not a solid fix for the future, but it worked for the time being.
I think you ultimately performed the steps outline in the release notes at the bottom of the Known Issues.
Based on the limited info in the Known Issue, I'm assuming there is some race condition taking place where the DHCP service or iptables rules are set before the vlan interface has been created. Enabling telnet access through the debug page can help you recover if you have some linux knowledge. Personally though, I have up on DNS and DHCP on my SX(R/S)80 and instead have a raspberry pi connected via a trunk port handing out addresses on all the VLANs. The main reason was to be able to have DNS for all DHCP hosts.
I have not experienced this issue though so maybe it's just a buggy DHCP server/config? I attached my dnsmasq config and ubuntu core netplan config incase anyone else wants to try and see if it helps.
dnsmasq.conf
domain-needed expand-hosts localise-queries bogus-priv no-resolv server=/test/ server=/localhost/ server=/invalid/ bind-dynamic cache-size=10000 conf-dir=/etc/dnsmasq.d/,*.conf domain=lan dhcp-authoritative dhcp-leasefile=/etc/dnsmasq.d/dhcp.leases localise-queries dhcp-range=192.168.1.100,192.168.1.199,8h dhcp-option=3,192.168.1.1 dhcp-range=eth0.20,192.168.20.100,192.168.20.199,8h dhcp-option=eth0.20,3,192.168.20.1 dhcp-range=eth0.30,192.168.30.100,192.168.30.199,8h dhcp-option=eth0.30,3,192.168.30.1 dhcp-range=eth0.40,192.168.40.100,192.168.40.199,8h dhcp-option=eth0.40,3,192.168.40.1
netplan.yaml
network: ethernets: eth0: addresses: - 192.168.1.2/24 gateway4: 192.168.1.1 nameservers: addresses: - 127.0.0.1 version: 2 vlans: eth0.20: addresses: - 192.168.20.2/24 id: 20 link: eth0 eth0.30: addresses: - 192.168.30.2/24 id: 30 link: eth0 eth0.40: addresses: - 192.168.40.2/24 id: 40 link: eth0
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
