RT-AC88U and TP-Link RE355: no IP-Adress assigned to devices

[dokape]

Hardware/configuration:
Asus RT-AC88U, Firmware Merlin 380.68_4 (latest)
Repeater TP-Link RE355, Firmware build 20151117 (latest)

Connection between Router/Repeater on 2.4ghz.
Repeater provides 2.4 and 5 ghz

Issue:
Devices (android, iOS) sometimes don't get IP-adress via Repeater, but via router direct (on any wifi band)
Exists since Router-Update from Asus RT-AC88U_3.0.0.4_380_3341-g25420f5
to Merlin or Asus FW_RT_AC88U_300438215850

Description

Hello there!
Having a problem I can't solve.
I have to use a repeater, I used the TP-Link RE355 since one year without problem in connection with my Asus RT-AC88U. Because of security reasons I upgraded the router first to original actual Asus-Firmware FW_RT_AC88U_300438215850 and later to Merlin 380.68_4.
This solved bugs in performance with by DUAL-WAN (German Telekom DSL and Unitymedia-Cable).
But now I have another problem:
Devices trying to connect via the repeater RE355 sometimes do not get an IP-Adress.
The devices have static IP-Adresses assigned by the router.
The devices get at once an IP-Adress when connected direct to the routers WIFI-Network.
The Repeater-WIFI is named different.
The Repeater connects without problem to the router.
I happens to Repeater-Network on 2.4 and 5 ghz.
Rebooting Devices, Repeater and Router does not work. Issue remains.

If it work (let the device on the table and do nothing for a while e.g. writing this text):
In the Router devices list I don't see the devices connected to the repeater (even if they have an IP-Adress assigned). only the repeater itself.
Manually assigning an IP-Adresse does not solve the problem. Connection will not be established.

What's wrong?
Anybody else with such a problem?

Thanks for reading.

Peter

 

[dokape]

Log looks like this for 10 to 20 Minutes:


.....
Oct 18 22:27:33 dnsmasq-dhcp[6619]: DHCPOFFER(br0) 192.168.200.101 ec:08:6b:33:26:ac
Oct 18 22:27:55 dnsmasq-dhcp[6619]: DHCPDISCOVER(br0) ec:08:6b:33:26:ac
Oct 18 22:27:55 dnsmasq-dhcp[6619]: DHCPOFFER(br0) 192.168.200.101 ec:08:6b:33:26:ac
Oct 18 22:27:58 dnsmasq-dhcp[6619]: DHCPDISCOVER(br0) ec:08:6b:33:26:ac
Oct 18 22:27:58 dnsmasq-dhcp[6619]: DHCPOFFER(br0) 192.168.200.101 ec:08:6b:33:26:ac
Oct 18 22:28:02 dnsmasq-dhcp[6619]: DHCPDISCOVER(br0) ec:08:6b:33:26:ac
Oct 18 22:28:02 dnsmasq-dhcp[6619]: DHCPOFFER(br0) 192.168.200.101 ec:08:6b:33:26:ac
Oct 18 22:28:12 dnsmasq-dhcp[6619]: DHCPREQUEST(br0) 192.168.200.101 ec:08:6b:33:26:ac
Oct 18 22:28:12 dnsmasq-dhcp[6619]: DHCPACK(br0) 192.168.200.101 ec:08:6b:33:26:ac TPLink_Repeater
Oct 18 22:28:14 dnsmasq-dhcp[6619]: DHCPREQUEST(br0) 192.168.200.101 ec:08:6b:33:26:ac
Oct 18 22:28:14 dnsmasq-dhcp[6619]: DHCPACK(br0) 192.168.200.101 ec:08:6b:33:26:ac TPLink_Repeater

After last 4 lines everything works.
It seems, the TP-Link RE355 has a problem getting his IP-Adresse from the RT-AC88U

Any hint?
Timezone Router: +1 (Berlin,...) and Sommertime activated.
In Systemlog: 1 hour behind...
Timezone Repeater: No Summertime available. with +1 (GMT) or +2 (GMST) no change.

 

[dokape]

Device-List: You see the TP-Link Repeater, shown with IP ending .161.
That's wrong. This Repeater has assigned .101 and is reachable on .101
You see, 4 devices are connected through the repeater. Thats correct.
They are not shown in the list with it's own name, they are always only shown with the Repeaters Name.

isn't it possible to list up the devices behind the repeater? (no NAT, no own DHCP)
Is that the problem with devices don't getting an IP-Adress by the router?

 

[dokape]

moved back to original ASUS-Firmware 3.0.0.4.380_3341
And - it works again.

So there is a problem in the dnsmasq-dhcp implementation between the Asus-Firmware 3.0.0.4.380_3341 and the actual Merlin 380.68_4 also as in the actual ASUS-Firmware.

Questions should be: What did Asus? Changed at dnsmasq-dhcp between that firmware?

 

[dokape]

Still no suggestion what the problem could be?

 

[Nemni]

I was looking into this exact problem yesterday. The problem is that TP-Link repeater firmware uses a udhcp client that was last updated in April 2012. Shortly after that release, there was another release fixing a few compatibility bugs that were introduced in the version that TP-Link uses. It causes the router to fail to renew DHCP leases and won’t accept IP assignments until the lease has expired on your DHCP server and on the client. There have been several updates to udhcp since.

Work-arounds: set short DHCP leases.

Remember to contact TP-Link support and complain about udhcp not being up-to-date in their firmware!

 

[dokape]

So the problem is on the Client (TP-Link) side? hmm. worst.
The question is, if this problem exists with newer TP-Link-repeaters at all.

 

[Nemni]

So the problem is on the Client (TP-Link) side? hmm. worst.

There isn’t much you can do about the client other than investigate replacing the firmware with LEDE. Works on many TP-Link Repeaters, but take care to backup the original firmware – and read up very carefully on how to restore the original firmware before replacing it. Replacing TP-Link flaw-ware with LEDE also sorts out the TP-Link–NTP-absue issue.

The question is, if this problem exists with newer TP-Link-repeaters at all.

All the 2017 models, at least. They use the same firmware.

 

[sproutworks]

There isn’t much you can do about the client other than investigate replacing the firmware with LEDE. Works on many TP-Link Repeaters, but take care to backup the original firmware – and read up very carefully on how to restore the original firmware before replacing it. Replacing TP-Link flaw-ware with LEDE also sorts out the TP-Link–NTP-absue issue.


All the 2017 models, at least. They use the same firmware.

I have a TP-Link RE355 and am having similar issues since I upgraded my router from a Linksys e4200 to an ASUS RT-AC86u. I started a dialogue with TP-Link tech support and have pointed them to this thread. I don't have much faith they will ever issue a firmware update to correct these issues.

 

[sproutworks]

There isn’t much you can do about the client other than investigate replacing the firmware with LEDE. Works on many TP-Link Repeaters, but take care to backup the original firmware – and read up very carefully on how to restore the original firmware before replacing it. Replacing TP-Link flaw-ware with LEDE also sorts out the TP-Link–NTP-absue issue.


All the 2017 models, at least. They use the same firmware.

Nemni, would you mind posting more information about the udhcp client that TP-Link is using? Do you have any more information on other libraries that are outdated as well?

I noticed the default gateway field on my RT-AC86u has been empty, so I set it to the router's ip. This seems resolve the dhcp issues I've been having with my RE355. I have over 20 other devices that didn't seem to be affected by the empty field.

 

[Nemni]

Nemni, would you mind posting more information about the udhcp client that TP-Link is using?

Intercept a single DHCP package, and it will identify the software and version. TP-Link uses udhcp from BusyBox 1.19.4, released on 2012-02-04. I found this in TP-Link RE650 which was released just a couple of months ago. Release notes on Busybox.net. Fixes for udhcp releases after 1.19.4 include compatibility fixes and even security fixes. You’d expect TP-Link to keep this up to date, but they appear to give very little care to their firmware after the device has been sold.

Do you have any more information on other libraries that are outdated as well?

Everything. For all intents and purposes, it appears to be a unmaintained and abandoned Linux distribution that is being included in products released as recently as six months ago.

 

[sproutworks]

Thanks for the additional info, I forwarded that to Tp-link support. They had me limit the ip range of the dhcp pool in my main router, and set the RE355 to use the remaining set of ips in that subnet. It seemed to work for a while, then when I checked on it later, I had the same problems I had before.

 

[hamson001]

I have a RE355(EU)_V1_151117, and purchased an Asus RT-AC88U last month with latest FW, but didn't have this problem.
Is there any possible that the problem is relative to specific end-client?

 

[hamson001]

Thanks for the additional info, I forwarded that to Tp-link support. They had me limit the ip range of the dhcp pool in my main router, and set the RE355 to use the remaining set of ips in that subnet. It seemed to work for a while, then when I checked on it later, I had the same problems I had before.

In case of have the same problem of yours, I decide make a test now... Can you tell me how do you work-around about your problem?

 

[dokape]

My Workaround: Using a RE500 with newer Firmware instead of the Re355.
The problem does not appear. DHCP is accepted. It does a fast connect, even clients on Re500 are much faster connected (WLAN-Login)
Router: Merlin 382.1.2
RE500: Firmware 1.0.1 Build 20170210 Rel. 59671
Hardware: RE500 v1.0

But well, with Merlin 382.1.2 I have other issues. :-(