Wrong server-ID after router reboot

[stylish_me]

Hello. I've got a strange problem after latest Merlin update.

My system is: RT-N66U (latest Merlin), RT-N16 (latest Merlin) and RT-N12C1 (latest Asus).
N66 is my main router that connects to Internet. N12 and N16 are connected to N66 via cable and work as AP for wired and wireless clients around the house.
N66 is set to reboot 2 times a week. And every time after night reboot all clients (wired and wireless) connected to N12 get disconnected. N66 log says "wrong server-ID", mac and ip of all devices, that used to be connected to N12. All other (about 20) devices, connected to N66 and N16 - work ok as usual.
After i manually reboot faulty n12 - all devices get correct ip and work ok untill next N66 reboot. Disconnected devices' logs show the get some strange wrong mask and dns (or just mask - i don't actually remember).
Is there any change in Merlin latest firmware that causes such N12 behaviour? N16 works perfect. So either i should do smth with N12 or change some N66 settings?
Both N12 and N16 are binded to fixed ip via mac on N66. Last week fixed ip was set on N12 and N16 instead of mac binding on N66 - problem was the same.
What should i do?

Thanx!

 

[RMerlin]

Please post the whole error message. Just "wrong server-ID" doesn't tell us what is generating such a message.

 

[stylish_me]

Please post the whole error message. Just "wrong server-ID" doesn't tell us what is generating such a message.

Thanx for your reply.

Here's my N66's log (a part of it) from it's reboot till i rebooted N12 (connected to it) to get rid of wrong server id errors. If you need other part of this log - please say which? 1000 limitation deosn't let me paste all the code..

Spoiler: N66 Log

Apr 10 05:57:31 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.155 84:78:8b:90:61:51
Apr 10 05:57:31 dnsmasq-dhcp[248]: DHCPACK(br0) 192.168.1.155 84:78:8b:90:61:51 iPad
Apr 10 06:40:27 dnsmasq-dhcp[248]: DHCPDISCOVER(br0) f0:db:e2:90:45:83
Apr 10 06:40:27 dnsmasq-dhcp[248]: DHCPOFFER(br0) 192.168.1.226 f0:db:e2:90:45:83
Apr 10 06:40:27 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.108 f0:db:e2:90:45:83
Apr 10 06:40:27 dnsmasq-dhcp[248]: DHCPNAK(br0) 192.168.1.108 f0:db:e2:90:45:83 wrong server-ID
Apr 10 06:54:04 dnsmasq-dhcp[248]: DHCPDISCOVER(br0) f0:db:e2:90:45:83
Apr 10 06:54:04 dnsmasq-dhcp[248]: DHCPOFFER(br0) 192.168.1.226 f0:db:e2:90:45:83
Apr 10 06:54:04 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.108 f0:db:e2:90:45:83
Apr 10 06:54:04 dnsmasq-dhcp[248]: DHCPNAK(br0) 192.168.1.108 f0:db:e2:90:45:83 wrong server-ID
Apr 10 07:00:06 dnsmasq-dhcp[248]: DHCPDISCOVER(br0) f0:db:e2:90:45:83
Apr 10 07:00:06 dnsmasq-dhcp[248]: DHCPOFFER(br0) 192.168.1.226 f0:db:e2:90:45:83
Apr 10 07:00:06 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.108 f0:db:e2:90:45:83
Apr 10 07:00:06 dnsmasq-dhcp[248]: DHCPNAK(br0) 192.168.1.108 f0:db:e2:90:45:83 wrong server-ID
Apr 10 07:03:42 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.2 c8:60:00:93:91:04
Apr 10 07:03:42 dnsmasq-dhcp[248]: DHCPACK(br0) 192.168.1.2 c8:60:00:93:91:04 RT-N12
Apr 10 07:09:40 dnsmasq-dhcp[248]: DHCPDISCOVER(br0) f0:db:e2:90:45:83
Apr 10 07:09:40 dnsmasq-dhcp[248]: DHCPOFFER(br0) 192.168.1.226 f0:db:e2:90:45:83
Apr 10 07:09:40 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.108 f0:db:e2:90:45:83
Apr 10 07:09:40 dnsmasq-dhcp[248]: DHCPNAK(br0) 192.168.1.108 f0:db:e2:90:45:83 wrong server-ID
Apr 10 08:00:29 dnsmasq-dhcp[248]: DHCPDISCOVER(br0) 00:22:d3:11:5e:6f
Apr 10 08:00:29 dnsmasq-dhcp[248]: DHCPOFFER(br0) 192.168.1.56 00:22:d3:11:5e:6f
Apr 10 08:00:29 dnsmasq-dhcp[248]: DHCPDISCOVER(br0) 00:22:d3:11:5e:6f
Apr 10 08:00:29 dnsmasq-dhcp[248]: DHCPOFFER(br0) 192.168.1.56 00:22:d3:11:5e:6f
Apr 10 08:00:29 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.101 00:22:d3:11:5e:6f
Apr 10 08:00:29 dnsmasq-dhcp[248]: DHCPNAK(br0) 192.168.1.101 00:22:d3:11:5e:6f wrong server-ID
Apr 10 08:08:25 dnsmasq-dhcp[248]: DHCPDISCOVER(br0) 60:92:17:1c:f4:d7
Apr 10 08:08:25 dnsmasq-dhcp[248]: DHCPOFFER(br0) 192.168.1.116 60:92:17:1c:f4:d7
Apr 10 08:08:25 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.105 60:92:17:1c:f4:d7
Apr 10 08:08:25 dnsmasq-dhcp[248]: DHCPNAK(br0) 192.168.1.105 60:92:17:1c:f4:d7 wrong server-ID
Apr 10 08:13:29 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.155 84:78:8b:90:61:51
Apr 10 08:13:29 dnsmasq-dhcp[248]: DHCPACK(br0) 192.168.1.155 84:78:8b:90:61:51 iPad
Apr 10 08:51:33 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.214 ac:cf:5c:dd:9f:0c
Apr 10 08:51:33 dnsmasq-dhcp[248]: DHCPACK(br0) 192.168.1.214 ac:cf:5c:dd:9f:0c iPhoneAndrewsr
Apr 10 08:51:33 dnsmasq-dhcp[248]: DHCPREQUEST(br0) 192.168.1.214 ac:cf:5c:dd:9f:0c
Apr 10 08:51:33 dnsmasq-dhcp[248]: DHCPACK(br0) 192.168.1.214 ac:cf:5c:dd:9f:0c iPhoneAndrewsr

And here's what n12 log says all the time after i rebooted it:

Spoiler: N12 log

Apr 10 10:08:10 kernel: eth1: received packet with own address as source address

More then 50 same errors within 24 hours

 

[stylish_me]

So as far as i understand all the users connected to n12 ask for different ip from the ones n66 wants to give them after n66 reboots. Why is this happening? How can users with dinamic ips ask for smth from dhcp server? Why doesn't n66 make them change their ips (being dhcp server)? Why all other users connected to n66 (my main router) and to n16 (my third asus, connected the same way as n12) easily reconnect to network and get proper ips?

 

[ColinTaylor]

It looks like there is another DHCP server somewhere on your network. What "mode" are the N12 and N16 in? Router, Access point, media bridge?

 

[stylish_me]

It looks like there is another DHCP server somewhere on your network. What "mode" are the N12 and N16 in? Router, Access point, media bridge?

All are in Ap mode, so no dhcp server running..

 

[stylish_me]

I think i found a problem.
I came down to my n12 that is in AP mode.
I noteced that wan led stays on even when i take wan cable away. But when i take lan4 cable away - wan led goes down.
So router thinks that wan is always connected when there is connection on lan4 port. Even when there is no lan cable.
And router thinks that there is nothing on wan port when lan 4 cable is disconnected even when wan cable is connected.
It's not only led behaviour - i made factory reset and took all lan cables away - only wan was connected. Connection wizard said please check wan cable. When i connected lan 4 cable - router went on with connection wizard.
BUT. Internet works even when wan led is down and router thinks there is no wan cable (but wan is connected).

So i think the problem is that when all 4 lan ports are connected - router doesn't see when main router reboots and disconnects wan. And when lan4 is not connected - router thinks there is no wan at all. Internet works but router makes mistakes.

What can i do in this situation?

 

[john9527]

Not withstanding your LAN cable observations, I might guess a different scenario.
I'm assuming that since you are running things in AP mode, the N12 and N16 are in different locations.

When the N66 goes down for a reboot, the N12 clients see the loss of access and go searching for another access point, which they find and connect to. It just so happens this new connection is handing out addresses in the same DHCP subnet. Now when things come back up, the clients see the stronger signal and try and connect back to the N12. But the N12 is telling them they can't connect because the 'servier id is wrong' since the client is still registered to the other access point.

So the question is, is there another access point in range in the 'N12 clients' they can connect to?

 

[ColinTaylor]

Interesting theory, but I wouldn't expect clients associated with the N12 to become disassociated just because the N66 went down.

How about this:

The N66 goes down so all of its Wi-Fi clients jump to either the N16 or N12, assuming they're in range. They shouldn't be able to get a DHCP address (because the N66 is down) but that doesn't matter, they'll just keep retrying.

Because the MAC addresses of the N66 clients are now appearing on the N16 and N12 you will get the "eth1: received packet with own address as source address" message in their logs. Which we do, so that seems to confirm that.

Clients previously associated with the N12 and N16 should be unaffected in terms of their connection and IP address. As far as they are concerned they are still connected to the network, it's just that the internet isn't responding.

This is where it gets weird; When the N66U comes back up 2 things should happen.

1) Clients previously associated with the N66 will either stick with their new access point and retry their DHCP request, or jump back to the N66 and get their IP address from that.
2) Clients that have always been associated with the N12 or N16 should suddenly have internet access again. No need to query DHCP because they should never have lost their connection to the access point.

The strange bit is that 2) doesn't seem to be happening. It's almost as if when the N12 looses connection to the N66 it resets itself into router mode, with it's own DHCP server. Then when the N66 comes back up, it switches back to access point mode.

@stylish_me Can you show us the complete logs from the N12 covering the period from before the N66 went down to after it came back up?