@Njd4 It looks like the v2.1 models of the WPA8630P(UK) uses the UK version of the firmware, and the v2.0 models use the EU firmware. I managed to install the EU firmware. @njd4 I assume you have v2.1 models?

@Solla-topee 

I've not been able to test the beta firmware yet, since I have not been at my neighbors yet since.

Tomorrow morning I'll be there once again. But I'm hessitant of flashing this beta firmware that doesn't resolve the issue completly just yet.

Since there is no way back to the option of custom firmware since the partition layout has changed in newer firmwares according to the support pages of OpenWRT.

The custom firmware will most definitely resolve this particular issue, but I assume that would cause trouble if they were to need any warranty in the future. So this is a last resort option I would like to keep open.

Any sight on when a new (beta) firmware will be available that resolves this issue fully? Or maybe even one that gives the user direct control over the DCHP server itself, instead of 'smart' DHCP..

@dunxd Sorry, Assumed i'd get an email when someone comments or replies.. Yes I believe mine is the 2.1 version. First one died completely and so was replaced under warranty a year or so ago so probably a bit newer.

@Solla-topee 

The DHCP issue seems better (if only it didn't start it at boot shortly, and the setting would survive reboots/powercycles)

We did, however, notice (frequent) connectivity problems from time to time after the upgrades:

- Wifi connection stays strong and stable

- Network connectivity fails, both DNS and page reloads fail

the connectivity restores itself automatically after <1 minute. No other setings in the network were changed except the FW update.

IP adresses were already fixed.

I wonder if anybody else has seen something like this....

We also came to a conclusion with the owners of this network:

It will be a few months until I visit this location again, if there is no stable firmware without DHCP by the end of the year I will buy another brand of gear and all TP-Link devices will be thown in the thrash.

PLEASE solve this simple issue by making a FW build that DOES NOT CONTAIN DHCPS. Simple.

You can offer both versions in case you insiste on this (WRONG) claim that DHCPS is needed in your product.

EDIT: editing post to clarify that when connectivity is lost, this is both LAN and WAN, so I cannot even reach the LAN side of the router!

thanks

@Solla-topee When will the final firmware be available for the TL-WPA8631P V3?

I have installed the beta firmware for my TL-WPA4220 V5 which is 1.0.1 Build 210209 Rel.62933n (6985)

A) Is older than my previous one downloaded from the official download page: 1.0.1 Build 210305 Ref 64377n 

B) It doesn't solve the DHCP issue.

What's going on?

@Solla-topee 

I cannot believe after years this issue is still not solved. Just implement an option DISABLING THE DHCP SERVER COMPLETELY. 

I have a WPA7510 KIT EU V2, and it's crippling. My typical failure use case:

1. general power outage

2. power comes up again

3. all network devices start to boot AT THE SAME TIME

4. TP-Link starts acting as a DHCP Server <- THIS IS A BIG NO NO!

5. Other embedded devices get a dynamic IP from the TP-Link

6. TP-Link cannot connect to the internet (of course!), the main router is still not operational

7. All embedded devices fail

8. Router comes up

9. Network is totally messed up, most embedded devices do NOT recover

Imagine a network with  multiple network segments, VLANs, Wireless APs, etc, each segment with its own allocated DHCP server in a router (!), and you can see TP-Link wreaking havoc.

The only way to "fix" this for me is to power everything down, remove TP-Link physically from the sockets, power everything up, plug in the TP-Link physically in their sockets.

This is extremely annoying and time consuming, and usually involves connecting a laptop with a fixed network cable to multiple device in turn to try and fix the issue.

A NIGHTMARE FOR SYSTEM MANAGEMENT!

And all because TP-Link engineers think they have found a "smart" DHCP solution. Well, it's the most stupid network design decision ever made! You can tell that to your engineers. And that's coming from someone who has experience designing (embedded) network solutions. You should relabel and sell it as "Stupid DHCP", because that's what it is". Then at least customers know what to expect, that would be fair.

@pipi I copy you. 

I think they created a DHCP solution by default, to help in the configuration process, which makes a lot of sense.

But what I cannot utterly understand is why they don't do a worthy effect, to put in their interface a simple button with a DISABLE DHCP label. 

Probably the DHCP is hardcoded in their embedded system, so it cannot be "dynamically" removed. So basically what they are doing with this pseudo-patch is "rewriting" the uplink information with static data, so, by default, the DHCP is not configured when the system boots. 

This is a 101 on laziness, after years of having this issue.