ASUS RT-AC88U forcing to assign a static ip address

[Meffy]

Hello guys. Im facing a little problem of focring rt-ac88u to assing a static adress to my cell phone e.g to "192.168.1.2" but when i connect to wifi i see that it reverts back to 192.168.1.220" instead. How can i force it to stay on "192.168.1.2"? When i check on the DHCP server list it says "192.168.1.2" but in the clients view list it says "192.168.1.220" I even use the "MAC and IP address Binding" and then hit apply, but after it reverts back again. I even rebooted both the router AND the cellphone. Connecting to the WI FI i see the same odd issue. And that goes for both bands 2.4Ghz and 5Ghz.
Can someone tell me wjat to do? I even tried both Merlins firmwares "RT-AC88U_380.57_0" and "RT-AC88U_380.58_alpha1"
Thanks in advanced!
Meffy!

 

[Meffy]

Bump! Anyone?

 

[john9527]

Sounds as if you may have more than one DHCP server on your network?

 

[Meffy]

Sounds as if you may have more than one DHCP server on your network?

No i dont think so, is the same settings as i alway had, mind you right now im running asus firmware. I upload some screenshots to show you how DHCP settings looks like

 

[Martineau]

No i dont think so, is the same settings as i alway had, mind you right now im running asus firmware. I upload some screenshots to show you how DHCP settings looks like

I have had an issue for 18 months where one device simply won't honour the DHCP reserved I/P.

I gave up trying to investigate why my RaspberryPi is correctly assigned the reserved I/P 10.88.8.147, but the second newer RaspberryPiB never gets assigned 10.88.8.148 and always obtains an I/P from the DHCP pool, despite dnsmasq log messages indicating otherwise:

Jan 30 20:20:07 RT-AC68U user.warn (DHCP_LeaseTracker.sh): 3494 Detected.....  /jffs/scripts/DHCP_LeaseTracker.sh old xx:xx:xx:xx:xx:xx 10.88.8.147 RaspberryPi
Jan 30 20:20:07 RT-AC68U user.warn (DHCP_LeaseTracker.sh): 3497 Detected.....  /jffs/scripts/DHCP_LeaseTracker.sh old xx:xx:xx:xx:xx:xx 10.88.8.215 raspberrypiB

Jan 30 20:21:53 dnsmasq-dhcp[3483]: not giving name raspberrypiB.Martineau.lan to the DHCP lease of 10.88.8.215 because the name exists in /etc/hosts.dnsmasq with address 10.88.8.148
Jan 30 20:21:53 dnsmasq-dhcp[3483]: not giving name raspberrypiB to the DHCP lease of 10.88.8.215 because the name exists in /etc/hosts.dnsmasq with address 10.88.8.148

Not much help I'm afraid, but at least take comfort that you are not the only one experiencing this frustrating issue.

 

[john9527]

I gave up trying to investigate why my RaspberryPi is correctly assigned the reserved I/P 10.88.8.147, but the second newer RaspberryPiB never gets assigned 10.88.8.148

What is DHCP_LeaseTracker.sh? It's not part of standard asuswrt-merlin. Could that be writing to or locking /etc/hosts.dnsmasq?

 

[john9527]

No i dont think so, is the same settings as i alway had, mind you right now im running asus firmware. I upload some screenshots to show you how DHCP settings looks like

I'm not sure what OEM Asus shows in the syslog. Can you post the DHCPREQUEST sequence when your phone connects?

 

[Meffy]

I'm not sure what OEM Asus shows in the syslog. Can you post the DHCPREQUEST sequence when your phone connects?

Where do i find DHCPREQUEST? Is it in System Log - DHCP leases? I can take a screenshot. Otherwise if i have to go through SSH or Telnet im not familiar to use it not least the commands. I have never used it. Don't know how.

 

[john9527]

Where do i find DHCPREQUEST? Is it in System Log - DHCP leases?

I got it from the syslog. (you should edit your post and delete both your attachments since they have your MAC addresses in them...for future reference, you should obscure your mac addresses before posting)

But, it's your phone that is messing up.....like it has been assigned a static IP.

Jan 31 03:18:18 dnsmasq-dhcp[17275]: DHCPREQUEST(br0) 192.168.1.222 78:f8:xx:xx:xx:xx
Jan 31 03:18:18 dnsmasq-dhcp[17275]: DHCPNAK(br0) 192.168.1.222 78:f8:xx:xx:xx:xx wrong server-ID
Jan 31 03:18:20 dnsmasq-dhcp[17275]: DHCPDISCOVER(br0) 78:f8:xx:xx:xx:xx
Jan 31 03:18:20 dnsmasq-dhcp[17275]: DHCPOFFER(br0) 192.168.1.2 78:f8:xx:xx:xx:xx
Jan 31 03:18:20 dnsmasq-dhcp[17275]: DHCPREQUEST(br0) 192.168.1.2 78:f8:xx:xx:xx:xx
Jan 31 03:18:20 dnsmasq-dhcp[17275]: DHCPACK(br0) 192.168.1.2 78:f8:xx:xx:xx:xx android-617904948e9b3a5d
Jan 31 03:18:21 dnsmasq-dhcp[17275]: DHCPREQUEST(br0) 192.168.1.222 78:f8:xx:xx:xx:xx
Jan 31 03:18:21 dnsmasq-dhcp[17275]: DHCPNAK(br0) 192.168.1.222 78:f8:xx:xx:xx:xx wrong address
Jan 31 03:18:22 dnsmasq-dhcp[17275]: DHCPDISCOVER(br0) 78:f8:xx:xx:xx:xx
Jan 31 03:18:22 dnsmasq-dhcp[17275]: DHCPOFFER(br0) 192.168.1.2 78:f8:xx:xx:xx:xx
Jan 31 03:18:22 dnsmasq-dhcp[17275]: DHCPREQUEST(br0) 192.168.1.222 78:f8:xx:xx:xx:xx
Jan 31 03:18:22 dnsmasq-dhcp[17275]: DHCPNAK(br0) 192.168.1.222 78:f8:xx:xx:xx:xx wrong server-ID

Your phone is asking for address .222, and the router is responding "I'm not who you think I am, I can't give you that address" . Finally, the router says "I'll give you the .2 address (DHCPOFFER)" and the phone says "I WANT .222". Wash, rinse, repeat.

Try 'forgetting' the connection on the phone and setting it up again from scratch.

 

[Martineau]

What is DHCP_LeaseTracker.sh? It's not part of standard asuswrt-merlin.

Indeed it is not...

I may be often accused (quite rightly) of writing manky shell scripts, but I definitely think this one falls into the trivial category, so I doubt it locks anything or inteferes with dnsmasq's abilty to correctly forcibly allocate a reserved I/P to a device!

#!/bin/sh
logger -s -t "($(basename $0))" $$ Detected.....  " $0${*:+ $*}"

 

[Meffy]

I got it from the syslog. (you should edit your post and delete both your attachments since they have your MAC addresses in them...for future reference, you should obscure your mac addresses before posting)

But, it's your phone that is messing up.....like it has been assigned a static IP.

Jan 31 03:18:18 dnsmasq-dhcp[17275]: DHCPREQUEST(br0) 192.168.1.222 78:f8:xx:xx:xx:xx
Jan 31 03:18:18 dnsmasq-dhcp[17275]: DHCPNAK(br0) 192.168.1.222 78:f8:xx:xx:xx:xx wrong server-ID
Jan 31 03:18:20 dnsmasq-dhcp[17275]: DHCPDISCOVER(br0) 78:f8:xx:xx:xx:xx
Jan 31 03:18:20 dnsmasq-dhcp[17275]: DHCPOFFER(br0) 192.168.1.2 78:f8:xx:xx:xx:xx
Jan 31 03:18:20 dnsmasq-dhcp[17275]: DHCPREQUEST(br0) 192.168.1.2 78:f8:xx:xx:xx:xx
Jan 31 03:18:20 dnsmasq-dhcp[17275]: DHCPACK(br0) 192.168.1.2 78:f8:xx:xx:xx:xx android-617904948e9b3a5d
Jan 31 03:18:21 dnsmasq-dhcp[17275]: DHCPREQUEST(br0) 192.168.1.222 78:f8:xx:xx:xx:xx
Jan 31 03:18:21 dnsmasq-dhcp[17275]: DHCPNAK(br0) 192.168.1.222 78:f8:xx:xx:xx:xx wrong address
Jan 31 03:18:22 dnsmasq-dhcp[17275]: DHCPDISCOVER(br0) 78:f8:xx:xx:xx:xx
Jan 31 03:18:22 dnsmasq-dhcp[17275]: DHCPOFFER(br0) 192.168.1.2 78:f8:xx:xx:xx:xx
Jan 31 03:18:22 dnsmasq-dhcp[17275]: DHCPREQUEST(br0) 192.168.1.222 78:f8:xx:xx:xx:xx
Jan 31 03:18:22 dnsmasq-dhcp[17275]: DHCPNAK(br0) 192.168.1.222 78:f8:xx:xx:xx:xx wrong server-ID

Your phone is asking for address .222, and the router is responding "I'm not who you think I am, I can't give you that address" . Finally, the router says "I'll give you the .2 address (DHCPOFFER)" and the phone says "I WANT .222". Wash, rinse, repeat.

Try 'forgetting' the connection on the phone and setting it up again from scratch.

Hello john9527 and thanks for your quick reply, anyway i have reinstalled the firmware "RT-AC88U_380.57_0" and did factory reset and went through the settings and then i managed to asign my cellphone to the ip i want which is 192.168.1.2 but.... when i connect on wifi 5ghz band i get the 192.168.1.2 and then when i disconnect and connect again, this time from 2.4Ghz band then it gives me this ip 192.168.1.222 (default) instead.Reconnecting with 5ghz band goes back to the one i asigned (192.168.1.2) Very weired, i wonder what am i doing wrong? Mind you my cellphone is LG G4 and i had lollipop 5.1 on it but i flashed it to marshmallow 6.0. Do you think that this could be the case that i get theese weird ip addresses?
Thanks! Meffy! Hope to hear from you!

 

[Kwan]

I've been having the same issue, and it seems to be most prevalent with Android 5.1.1 devices (that and a thermostat, that I have no idea as to system) - anyway, I'd say definitely Android related, though haven't seen it with Android 6.01 devices.

I find that I can force things to work if I go to the DHCP server and assign the a static IP that correlates to the IP they were using when I check the system log. That fixes it, and I don't even need (at least so far) to set a static IP on the device side. Not pretty, but not sure what else to do.

I'm running into this on an Asus 68ACU running both Merlin 380.61 alpha 2 and 380.59. Not sure why this is happening, but I've tried forgetting networks, resetting etc. all to no avail, and the strange thing is that up until recently this hadn't been an issue?

This might be the answer - http://appslova.com/how-to-fix-obtaining-ip-address-error-in-android/

Set static IP in the DHCP on Merlin, and then after connected, remove them. So far, so good - fingers crossed!

 

[Kwan]

No, I was wrong. My phone Android 6.01 has the same issue, and I have been forced to set static IPs for almost every Android device? What is going on here - this wasn't the case before, and it wasn't due to an upgrade on Merlin (as I had been using 380.59 for a while)

 

[Kwan]

Here is my log: Android tv box works because I set up static IP, but other android device ... gets "wrong server-ID" (device connects, but with no internet) as tv box used to. Anyone have any idea what I've done wrong?

Posted a screen shot of my DHCP settings, below. I don't know why Android devices are having such an issue?



Aug 1 09:14:27 dnsmasq-dhcp[444]: DHCPNAK(br0) 192.168.0.26 8c:3a:e3:73:2e:e7 wrong server-ID
Aug 1 09:15:58 dnsmasq-dhcp[444]: DHCPDISCOVER(br0) 8c:3a:e3:73:2e:e7
Aug 1 09:15:58 dnsmasq-dhcp[444]: DHCPOFFER(br0) 192.168.1.95 8c:3a:e3:73:2e:e7
Aug 1 09:15:58 dnsmasq-dhcp[444]: DHCPREQUEST(br0) 192.168.0.26 8c:3a:e3:73:2e:e7
Aug 1 09:15:58 dnsmasq-dhcp[444]: DHCPNAK(br0) 192.168.0.26 8c:3a:e3:73:2e:e7 wrong server-ID
Aug 1 09:18:09 kernel: nvram: consolidating space!
Aug 1 09:25:45 dnsmasq-dhcp[444]: DHCPDISCOVER(br0) 34:af:2c:ff:68:5a
Aug 1 09:25:45 dnsmasq-dhcp[444]: DHCPOFFER(br0) 192.168.1.20 34:af:2c:ff:68:5a
Aug 1 09:25:45 dnsmasq-dhcp[444]: DHCPREQUEST(br0) 192.168.1.20 34:af:2c:ff:68:5a
Aug 1 09:25:45 dnsmasq-dhcp[444]: DHCPACK(br0) 192.168.1.20 34:af:2c:ff:68:5a Androidtv
Aug 1 09:26:14 dnsmasq-dhcp[444]: DHCPDISCOVER(br0) 8c:3a:e3:73:2e:e7
Aug 1 09:26:14 dnsmasq-dhcp[444]: DHCPOFFER(br0) 192.168.1.95 8c:3a:e3:73:2e:e7
Aug 1 09:26:14 dnsmasq-dhcp[444]: DHCPREQUEST(br0) 192.168.0.26 8c:3a:e3:73:2e:e7
Aug 1 09:26:14 dnsmasq-dhcp[444]: DHCPNAK(br0) 192.168.0.26 8c:3a:e3:73:2e:e7 wrong server-ID

 

[RMerlin]

Make sure you don't run multiple DHCP servers on your LAN.

 

[Kwan]

I didn't think I was, but now I am wondering if the Minix Neo U1 I bought for Android TV, had a dhcp server running on it somewhere?

I don't think so, but that is the only thing that makes sense.

It's there any easy way to track a rogue dhcp server?

Have to dig into it and see what I can find. Thank you.

Make sure you don't run multiple DHCP servers on your LAN.

 

[RMerlin]

I didn't think I was, but now I am wondering if the Minix Neo U1 I bought for Android TV, had a dhcp server running on it somewhere?

I don't think so, but that is the only thing that makes sense.

It's there any easy way to track a rogue dhcp server?

Have to dig into it and see what I can find. Thank you.

Simplest way is to turn off your router, then try to renew your DHCP lease on a Windows computer. It will confirm if it's really the case, and might also help you track down the source.

Otherwise, if you are technically enclined toward it, you could run a traffic sniffer like Wireshark on your LAN, and see the MAC address of any device sending DHCP replies on your LAN.

 

[PolarBear]

When i check on the DHCP server list it says "192.168.1.2" but in the clients view list it says "192.168.1.220"

I saw something similar about a month ago. (RT-AC66U running 378.56_2). Although I reserved a specific IP address for a new client, the client did not seem to get this address, even when the lease was renewed.

So I deleted the reservation and then recreated it, this time using CAPITAL letters instead of small letters in the MAC address.

Afterwards it worked as expected.

I was pressed for time and just happy that it worked, so did not investigate whether the capital letters indeed solved the problem, or if it was just a coincidence.

PolarBear

 

[Kwan]

Simplest way is to turn off your router, then try to renew your DHCP lease on a Windows computer. It will confirm if it's really the case, and might also help you track down the source.

Otherwise, if you are technically enclined toward it, you could run a traffic sniffer like Wireshark on your LAN, and see the MAC address of any device sending DHCP replies on your LAN.

Thank you Merlin.

I wouldn't say I'm technically inclined but I ran Wireshark (anyone else trying to track down a rogue DHCP, there is a video on youtube) and got offers from the router (192.168.1.1) and from 192.168.0.1 which I determined from the MAC address, is the Windows 10 computer I was running the release/renew commands on, at IP 192.168.1.79

I don't know if the offer from .0.1 is expected behaviour ( going from router to DHCP client on Windows, to Windows?) I can't imagine why there would be a DHCP server on this Windows 10 computer?

Is this expected behaviour?

Full detail (realease - Discover/Offer/Request/ACKnowledge) not filtered down to Offers:

 

[Kwan]

Thank you Merlin.

I wouldn't say I'm technically inclined but I ran Wireshark (anyone else trying to track down a rogue DHCP, there is a video on youtube) and got offers from the router (192.168.1.1) and from 192.168.0.1 which I determined from the MAC address, is the Windows 10 computer I was running the release/renew commands on, at IP 192.168.1.79

I don't know if the offer from .0.1 is expected behaviour ( going from router to DHCP client on Windows, to Windows?) I can't imagine why there would be a DHCP server on this Windows 10 computer?

Is this expected behaviour?

View attachment 6941

Full detail (realease - Discover/Offer/Request/ACKnowledge) not filtered down to Offers: