Does your computer(old&new) in the same subnet with the EAPs?

For the operation of controller migrating(same subnet migrating), maybe the following steps can help you:

1、backup the old controller in computer A;

2、fresh install new controller in computer B,then do restore operation in new controller, you can see all the EAPs in APs list, but they are all Disconnected;

3、just shutdown computer A or close old controller, the new controller will automatically take over all the EAPs. All done.

Thanks for the reply!

It is on the same network.

I will try the process to stop the old controller and see what happens.  I've done this about 100 times so while thinking I've done this, I will try again just in case.

Couple more checks:

- I don't see anything in Windows Event logs.

- Logs in the Controller directory

MongoDB

***** SERVER RESTARTED *****

Thu Sep 27 18:42:55 [initandlisten] MongoDB starting : pid=6228 port=27017 dbpath=C:\Program Files (x86)\TP-LINK\EAP Controller/data/db 64-bit host=DESKTOP-OBKC0BD
Thu Sep 27 18:42:55 [initandlisten] db version v2.2.2, pdfile version 4.5
Thu Sep 27 18:42:55 [initandlisten] git version: d1b43b61a5308c4ad0679d34b262c5af9d664267
Thu Sep 27 18:42:55 [initandlisten] build info: windows sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1') BOOST_LIB_VERSION=1_49
Thu Sep 27 18:42:55 [initandlisten] options: { bind_ip: "127.0.0.1", dbpath: "C:\Program Files (x86)\TP-LINK\EAP Controller/data/db", logappend: true, logpath: "C:\Program Files (x86)\TP-LINK\EAP Controller/logs/mongod.log", nohttpinterface: true, pidfilepath: "C:\Program Files (x86)\TP-LINK\EAP Controller/data/mongo.pid", port: 27017 }
Thu Sep 27 18:42:56 [initandlisten] journal dir=C:/Program Files (x86)/TP-LINK/EAP Controller/data/db/journal
Thu Sep 27 18:42:56 [initandlisten] recover begin
Thu Sep 27 18:42:56 [initandlisten] recover lsn: 0
Thu Sep 27 18:42:56 [initandlisten] recover C:/Program Files (x86)/TP-LINK/EAP Controller/data/db/journal/j._0
Thu Sep 27 18:42:56 [initandlisten] recover cleaning up
Thu Sep 27 18:42:56 [initandlisten] removeJournalFiles
Thu Sep 27 18:42:56 [initandlisten] recover done
Thu Sep 27 18:42:56 [initandlisten] waiting for connections on port 27017
Thu Sep 27 18:43:02 [initandlisten] connection accepted from 127.0.0.1:58972 #1 (1 connection now open)
Thu Sep 27 18:43:04 [initandlisten] connection accepted from 127.0.0.1:58973 #2 (2 connections now open)
Thu Sep 27 18:43:09 [initandlisten] connection accepted from 127.0.0.1:58975 #3 (3 connections now open)
 

I don't see anything whacky there.

Server

2018-09-27 19:18:59 [main] [INFO]-[SourceFile:34] - success to load configuration : eap.properties
2018-09-27 19:18:59 [main] [INFO]-[SourceFile:34] - success to load configuration : netty.properties
2018-09-27 19:18:59 [main] [INFO]-[SourceFile:34] - success to load configuration : mongodb.properties
2018-09-27 19:18:59 [main] [INFO]-[SourceFile:34] - success to load configuration : jetty.properties
2018-09-27 19:19:03 [Thread-4] [INFO]-[SourceFile:34] - success to load configuration : device.properties
2018-09-27 19:19:05 [main] [INFO]-[ContextHandler.java:2040] - Initializing Spring root WebApplicationContext
2018-09-27 19:19:13 [main] [INFO]-[SourceFile:40] - monitor context initialing...
2018-09-27 19:19:13 [main] [INFO]-[ContextHandler.java:2040] - Initializing Spring FrameworkServlet 'springMVC'
2018-09-27 19:19:14 [main] [INFO]-[SourceFile:102] - no need to compatible db.
2018-09-27 19:19:14 [Thread-17] [INFO]-[SourceFile:40] - Cloud service is forbidden.
2018-09-27 19:19:32 [qtp1022081840-97] [INFO]-[SourceFile:34] - success to load configuration : user.params.properties
 

Nothing seems odd here.

Could it be something in the properties files?

#firewall
eap.firewall.rule.name="Omada Controller"
eap.delete.firewall.command=netsh advfirewall firewall delete rule name=${eap.firewall.rule.name}
eap.add.firewall.command=netsh advfirewall firewall add rule name=${eap.firewall.rule.name} dir=in action=allow program="${eap.home}\\jre\\bin\\java.exe" enable=yes

discover.firewall.rule.name="Omada Discovery Utility"
discover.delete.firewall.command=netsh advfirewall firewall delete rule name=${discover.firewall.rule.name}
discover.add.firewall.command=netsh advfirewall firewall add rule name=${discover.firewall.rule.name} dir=in action=allow program="${eap.home}\\jre\\bin\\javaw.exe" enable=yes
 

This runs as Administrator.  Is there a way to turn on debug mode when I run it?

Thanks again for any help!

You said you have reset all the EAPs, after reset EAPs, the new controller should find all the EAPs in the pending status, so it's not?

Trying to follow your advice.

1) Start controller (v3.0.2), verify all APs are still Disconnected.

2) Stop controller.

3) Reset AP - hit reset button with paperclip for about 5 secs and the LED goes red/orange/green.  The AP SSID has changed back to TP-Link...

4) Start controller.  All APs are still Disconnected.  Hit manual refresh on the AP screen many times to see if the status changes in case it takes time to boot.  Still Disconnected.

5) Stop controller.

6) Start EAP Discover tool.  Select the newly reset AP to manage.  Enter the IP addr of the controller system, default admin/admin creds, and it is successfully managed.

7) Start controller again.  All APs, including the newly reset AP, are still in Disconnected status.

At this point, I guess I'm going to have to install Wireshark and see what is happening at the packet level.

Could it be a SSL Certificate issue or a TLS versioning issue?  What protocol does the controller speak to the AP?

Thanks for the help!

Tried to use Chrome instead of Edge.  No difference.

Checking the packet flow.

The AP that was just managed is sending UDP packets to the controller on port 29810 and it appears to be a UDP broadcast.  Looks like a config file.

When I start the EAP Discovey Utility v1.0.3, it looks like the packet flow is:

Hear the UDP broadcast, populate the list of talking APs.

When I select Manage in the app, it starts a TCP conversation on controller port 29812 and then transfers over to a new conversation on TCP port 29811.

While the controller is running, UDP port 29810 is listening.  Also, both TCP 29811 and 29812 are listening.

Watching the packets for 5 minutes while the controller is running, it's just the AP broadcasting outward to UDP 29810.  No response from the controller.  Clicking buttons in the controller doesn't initiate any packetflow to the AP.

I didn't see any SSL/TLS traffic so not likely to be a Cert issue.

I know I've installed the controller about 25 times, both the 2.7 and 3.0.2 versions.  Asking me to re-install the controller software probably won't help. 

Can't figure out why the EAP Discovery tool works, but not the controller software.  It's going to take some noodleing to figure out where to go next.  Maybe Windows Firewall?!?!  But then why would the EAP Discovery Utility work?  Guess that doesn't make sense.

@Jonas_TP-Link  Please check this.

One thing I did notice - controller that works is on 32-bit Win10 and the one that fails is on 64-bit Win10.

I copied the entire 32-bit app over, and it worked with the APs getting connected.

OK, not the system.

That leaves Windows Firewall.  I went in a changed all the Java entries in the Windows Firewall to allow both Public and Private access and, voila, the 64-bit v3.0.2 controller app worked.

Windows (Freaking) Firewall.  I installed that app so many times, I'm hoping the default didn't have the correct necessary Windows Firewall permissions and it wasn't always me misconfiguring it each of the 25 times I installed it.

Thanks for the help and allowing me to walk through the process.

Steve