@Noorthbynorth 

Salve , anche noi abbiamo lo stesso problema, potreste risolvere? grazie mille

  @Clive_A 

in fact, it looks like the problem has fixed itself. am now on windows contoller 5.12.6
same firmware on ER707

  @Virgo 

I came to this thread because I installed an ER707-M2 router on Sunday and by Wednesday it had this bug, showing disconnected with the controller but still working.

I just upgraded the OC200 to the release 5.12.9 and the router is still disconnected.  THIS WILL NOW REQUIRE A SITE VISIT TO REBOOT THE ROUTER. THIS IS UNACCEPTABLE.  If you cause a site visit unnecessarily, it means your QA is terrible and you don't know who your customers are. You've lost value proposition vs going with something stable (Ubiquiti and opnsense routers never caused a single site visit in 7 years of use, and TP-Link caused one in less than 72 hours!!!).

How could a site visit be avoided? Well, the router still reports being managed by the controller, so there is no reboot functionality in the webGUI of the router (FAIL!).  So then I SSH'd into the router to reboot it from there. ALSO NOT POSSIBLE.  This is epic fail, IMO.

Please add some experienced people to your QA team so they better understand what is not acceptable for business use.  This isn't home junk you can tell people to just randomly power cycle whenever bugs occur. Your whole value proposition is the monitoring, configuring and alerting of issues. You can't be the ones introducing bugs and removing monitoring, configuration and alerting.

How do I give my customer a bill for new TP-Link hardware that I promised all kinds of functionality, and then 3 days later I need to bill them for TP-Link bugs?

p.s. the symptoms point to this being a router issue, not a controller issue since the switches and EAP's never disconnected at the same time. So you're probably wanting logs from the router since it disconnected and failing to reconnect... BUT HOW DOES THAT HAPPEN WHEN THE WEBSERVER DOESN'T FUNCTION?

  @Noorthbynorth 

Given that this bug has existed for more than 3 months and looking at the beta/release firmware cycles, it won't be another 3 months before they even look at fixing this bug.

I'll be returning 3 switches and a router due to the lack of QA for bugs like this. Unacceptable in a production/business environment.

  @Tedd404 

What kind of silly response is this? Why bother responding at all if your setup isn't serious and can handle truck rolls/site visits to fix TP-Link bugs? Your response clearly indicates you have no clue about this bug and the effect, or else you'd know how much of a waste of time it would be making a phone call on this issue. This isn't a setup issue where a quick call to a technician would resolve it ("go to site, power cycle it". Waste of my time). It would simply be a call to complain about the issue, just as I am doing now, just not taking it out on the person on the call.

I've worked in QA for over a decade with wireless equipment. Preventing loss of management and causing a site visit ($$$/time) was a top priority. So I'm embarrassed for TP-Link that I ran into a showstopper level bug in less than 72 hours, while doing nothing out of the ordinary. No risky firmware updates, no change in VLAN's, no reboot to backup FW images, etc. Just plain 'ol normal operation for a small business.

There is nothing complex or extravagant in this setup. No VLAN's, no high device count, it was in operation for DAYS and failed. But that isn't the worst part, it's the lack of recoverability (no ability to reboot from webGUI or SSH), leading to a potential purchase of a remote power device to reboot the router and have it functioning properly again.

These are problems that usually occur when developers/QA do not actually use the equipment (aka "dog fooding it"). The lack of reboot recoverability clearly proves this.

  @Noorthbynorth Same here, also running ER707-M2 with fw 1.1.0. It just started happening a few days ago after it has been in this fw version for quite some while now, and now the issue is becoming more frequent. Traffic seems to be moving just fine (else would not be able to access my OC300 from outside the prem). Is there are solution to this? I don't see any in this thread.