Upgraded to 376.49_4, now all DHCP gives 192.168.0.x

[joecooper84]

I was on 376.48_3 and upgraded to 376.49_4 (without doing a factory reset). My router IP is 192.168.1.1, but now DHCP always hands out 192.168.0.x addresses unless set statically via MAC address. I reset to factory settings via the Reset button in the GUI and still have the same issues. I have to locally set my IP to 192.168.1.2 in order to get to the router webpage.
I just reverted back to 376.48_3 without importing any settings and I still have the same issue.

I've confirmed my starting address for my DHCP pool is 192.168.1.2.
Does anyone have any suggestions on what I can do? I also tried setting my starting IP for the DHCP pool to 192.168.1.20 to see if that would help (it has not).

I even shut down my modem, router, and all computers on the network, then powered on the modem, waited till it was connected for a minute, powered on the router, waited till it was set to go, then powered on two or so computers. Same result.

Below is my system log (external IPs modified), not sure if it helps though. Any suggestions?

Had to post my system log at http://pastebin.com/1gYfT932

 

[ScottW]

What's specified for your subnet mask under Lan, Lan IP?

 

[joecooper84]

What's specified for your subnet mask under Lan, Lan IP?

255.255.255.0

Also, I don't know if this matters, but under LAN > DHCP Server> the Default Gateway is blank.

 

[ScottW]

Default gateway blank is normal (if left blank, the router's address is used).

I have no other ideas, sorry. Sounds like a problem with nvram for which I would suggest resetting to factory defaults -- but you have already done that.

Hopefully someone else will pop in with an idea.

 

[john9527]

Were you traveling for the holidays with the clients and changed some settings?

The clients are all requesting 192.168.0.x addresses (last address it had), being offered a 192.168.1.x address by the router, re-requesting the 192.168.0.x address, then being told by the router it can't give them that address. All except one client, WN2000RPTv3, which is successfully getting an address in the 192.168.1.x subnet.

It looks like the clients are configured with a static address.

Also, as a side note, you shouldn't include 192.1681.254 in your pool. That address has a special purpose for broadcasts (I think).

 

[joecooper84]

Nope, no traveling. All hosts just started doing it within the past two days. This started after I upgraded (to the best of my knowledge). I would think it would be caused by a Windows update, but even my Ubuntu NAS is doing the same thing.
As for 192.168.1.254, that is how it was set by default. Isn't .255 used for broadcasts? I have no problem changing it, but I do not think that is the cause. I'll try it and let you know the results.

 

[john9527]

The 254 address was just an aside, and won't change the dhcp problem.

but it's very clear the clients aren't accepting the address offered by the router

Here's an example from your syslog

Jan 5 17:17:18 dnsmasq-dhcp[419]: DHCPREQUEST(br0) 192.168.0.25 fc:c2:de:5c:12:71
Jan 5 17:17:18 dnsmasq-dhcp[419]: DHCPNAK(br0) 192.168.0.25 fc:c2:de:5c:12:71 wrong network
Jan 5 17:17:22 dnsmasq-dhcp[419]: DHCPDISCOVER(br0) fc:c2:de:5c:12:71
Jan 5 17:17:22 dnsmasq-dhcp[419]: DHCPOFFER(br0) 192.168.1.242 fc:c2:de:5c:12:71
Jan 5 17:17:22 dnsmasq-dhcp[419]: DHCPREQUEST(br0) 192.168.0.25 fc:c2:de:5c:12:71
Jan 5 17:17:22 dnsmasq-dhcp[419]: DHCPNAK(br0) 192.168.0.25 fc:c2:de:5c:12:71 wrong server-ID

 

[joecooper84]

Tried changing pool to end with 253 and rebooting, same result.
I noticed that in the log too. I don't know why all these devices would suddenly want an IP address in a range they have never been in before...

Thanks for your help, by the way.

Even then, on the fourth line down, you can see the DHCPOFFER for an IP address in 192.168.1.x, yet DHCPNAK gives wrong server-ID. Time for some more Googling.

 

[john9527]

longshot, but the .49 code enabled some dnsmasq features for IPv6 (shouldn't effect this....but?). You may want to try falling back to the last .48 build as a test.

 

[joecooper84]

I was thinking that was it too, after reading the changelogs, but I already went back to 376.48_3 and that is what I have been using to troubleshoot since I started this post.
I'm going to fire up wireshark to make sure there isn't some other device on the network acting as a DHCP server.

 

[ColinTaylor]

Do you have any other devices on your network that can act as a DHCP server?

http://forums.smallnetbuilder.com/showthread.php?t=18874

 

[cofetym]

I'm sure Merlin is very busy but I noticed on our site here 376.49_2 is marked stable.
While 49_3 & 49_4 are on the official site for download

No problems for me on my RT-N66U in AP mode running Merlin 376.49_4

No problems running John's Merlin Fork 6 on my RT-AC66U in default mode.

 

[john9527]

I'm going to fire up wireshark to make sure there isn't some other device on the network acting as a DHCP server.

Good thought.....the link that @CollinTaylor provided in his post also shows a very similar signature.

 

[RMerlin]

Jan 5 17:17:18 dnsmasq-dhcp[419]: DHCPREQUEST(br0) 192.168.0.25 fc:c2:de:5c:12:71
Jan 5 17:17:18 dnsmasq-dhcp[419]: DHCPNAK(br0) 192.168.0.25 fc:c2:de:5c:12:71 wrong network

Your client is the one requesting an IP in the 192.168.0.xxx subnet, it's not the router's fault. You will have to figure out why your client previously had an IP in that subnet. Most likely reasons are either you have a second DHCP server on your network, or that client was previously connected to a different network which gave it an IP in that subnet.

Your router is doing the correct thing here, rejecting the IP (that's the DHCPNAK reply that it sends on the line below), stating that it's in the wrong network.

 

[RMerlin]

I'm sure Merlin is very busy but I noticed on our site here 376.49_2 is marked stable.
While 49_3 & 49_4 are on the official site for download

No problems for me on my RT-N66U in AP mode running Merlin 376.49_4

No problems running John's Merlin Fork 6 on my RT-AC66U in default mode.

That's odd, the post even said had my last edit comment saying "updated for 376.49_4". I probably updated the SHA256 signatures but forgot to update the top content of the post.

I will probably simplify this post now that there's a dedicated website. That content is redundant, and I'm trying to reduce the number of different locations I have to edit whenever I issue a new release.

 

[cofetym]

Thanks,Merlin!

 

[elorimer]

I had something similar happen to me with Windows 8.1. I took my laptop from a N66 router with a 0.x subnet to a N16 router with a 2.x subnet. When I returned, I couldn't connect to the original router. Somehow my adapter setting had changed to set a static 2.x IP address. In 8.1 you have to work at it to do that.

Both routers are running Merlin and both had DHCP reservations for the laptop. I don't see that having anything to do with it, as another 8.1 laptop going back and forth at the same time didn't exhibit this behavior.

 

[joecooper84]

I sniffed my network, found the MAC address of the host acting as a DHCP server, and just happened to notice it is an AP of some neighbor down the road! (Saw the MAC in Wireless > WDS > Remote/AP List) How is is that possible when I have my router set in AP mode only?

 

[joecooper84]

I'm 99% sure I just figured it out, and it's a doozie!
Because of the crappy signal of Foscam webcams, I use PowerLine adapters to run my network through the power lines in my house. (From what I've read) SOMETIMES, depending on how they route through the breaker box, people who share the same electrical line? can see the same traffic. I left the router on, unplugged the one CAT5 which was connecting the PowerLine, and everything started magically working. I'll post back later if that theory changes at all.

 

[cofetym]

What brand Powerline are you using? I'm using Trendnet and have checked my settings, no issues.