OK, this is getting serious.  The EAP670 crashed again during an important online presentation.  Device status went to "Heartbeat missed" and then to "Disconnected".  I had to power-cycle it twice to get it to come back up.

THIS IS UNACCEPTABLE

  @jhg6308 

I suspect a switch problem, check that the switch is 802.3at (POE+) compatible.
try to connect access points with the included poweret. if you have the same problem with the power as follows, check the network cables.

  @MR.S 

MR.S wrote

  @jhg6308 

 

I suspect a switch problem, check that the switch is 802.3at (POE+) compatible.
try to connect access points with the included poweret. if you have the same problem with the power as follows, check the network cables.

 

Based on a Google search I see many other people with similiar issues.  The switch is a brand new 802.3at capable TrendNET TPE-TG350. 

An IR thermometer measures 107F on the outer case surface (at the logo), so overheating is a possibility.  The device is not mounted in a particularly warm location

I'm used to troubleshooting network issues, but am encountering roadblocks at every turn

• Can't enable ssh on the device while it's being managed by the SDN controller
• Enabled ssh after removing it from the controller, but the UI provides no way to upload an ssh public key
• Lack of detailed troubleshooting capability
• Limited tech support hours
• Enabled email alerts in the controller, test email works, but actual alerts not being sent
• Poor or incomplete documentation
• Updated SDN controller to latest version; now unable to connect (spinning icon on blank page in browser)

Additional info

The following was in dmesg this morning

[25132.529899] wlan: [0:I:ANY] ieee80211_complete_wbuf: ieee80211_complete_wbuf: Reo queue update failed
[26267.046955] wlan: [356:I:ANY]  ieee80211_ioctl_kickmac[8421]
[26267.046955]
[26950.326148] wlan: [356:I:ANY]  ieee80211_ioctl_kickmac[8421]
[26950.326148]
[36621.939841] wlan: [0:I:ANY] ieee80211_complete_wbuf: ieee80211_complete_wbuf: Reo queue update failed

This may be related to a driver bug. See https://community.ui.com/questions/Connectivity-issue/250a2f14-352c-4a5b-92ec-a49bebfc69c9

I disassociated the device from the controller, uninstalled the controller, and configured the device via its builtin web server.

So far, after 2-1/2 days, it has not crashed once.  I am going to run this way for a week, to confirm that the device itself is stable. Then I will re-install the controller and adopt the device again. 

If it crashes after that it will confirm that the controller is doing something to make the device unstable. 

Stay tuned until next week.

So far so good, no device instability.  I will reinstall the controller and adopt the device on Sunday to see if it starts crashing again.

@MR.S 

I reinstalled the SDN controller (latest version) and adopted the device.  Within 6 hours the EAP670 disconnected and crashed, requiring a power-cycle to recover.

I think this proves the device has a problem with being managed by the controller.  There's a support ticket as well TKID240727652.

There doesn't seem to be a way to attach files here, so I've put 3 files on Google Drive, containing the DeviceInfo dumps taken at three points:

74-FE-CE-FC-9F-24_deviceInfo_2024-07-22-08-02.zip - After adopting
74-FE-CE-FC-9F-24_deviceInfo_2024-07-22-16-59.zip - During crash
74-FE-CE-FC-9F-24_deviceInfo_2024-07-22-17-03.zip - After recovery

 I have detached the device from the controller as it seems to be stable when running standalone.  I'm giving up on the SDN controller until TP-Link can provide a version that doesn't crash the EAP670.

A comment: Having ssh enabled is pretty much useless since the OS is locked down to the point that I can't access any troubleshooting tools or information.  This is strange for a supposedly commercial-level product. 
 

  @jhg6308 

I have said before what I think is wrong, but it seems to me that you are very fixated on the controller problem or EAP670 being the problem and are not willing to look at other sources of error. I am almost 100% sure that the fault is not the controller software or the EAP670, the fault is between the controller and the Access point. as I have said check the switch, network cable, also check the network cable connected to the controller. set fixed ip on controller PC do not use WiFi on controller PC. try connecting to the power that came with the EAP670 to rule out power problems.

if the access point works in stand-alone mode, there may still be problems with the switch or network cable, but you just don't notice it. when you are connected to the controller, we get provisioning and re-provisioning which configures the access point and in that process the network can fail if bad switch or bad network cable.

it could also be that the PC running the controller itself is the problem, try another PC to see if that helps. make sure you install the correct java.

  @MR.S OK, I reduced the topology to the following:

Internet----pfSense----TrendNet TEG-S380
                       2.5g non-POE
                        |         |
                        |         |
  Win11Pro64-----Netgear MS305    |
                 2.5g non-POE     |
                                  |
      TP-Link Power~ ~ ~ ~ ~TP-Link EAP670
            Adapter

In this configuration, the EAP670 no longer crashes completely, but a number of devices on 2.4GHz lose their connection to the AP after a few hours.  The devices that lose their connection are at various distances from the AP, the nearest being about 8 ft and the farthest about 50ft, with several in between.

The Omada SDN controller shows the devices as "Connected" but with no IP address. They are not actually connected, so the controller is confused.  They were all working last night but were in limbo as of this morning.  This also happened during the day yesterday, and I had to reboot the EAP to restore connectivity... "Reconnect" in the controller did nothing.

What bothers me most is the lack of diagnostic information.  There's a concept of "Serviceability", which says that your equipment needs to provide enough information to diagnose issues.  The TP-Link ecosystem seems to be lacking in that regard.  ssh access is window-dressing only. As an experienced Linux admin I can't actually do any troubleshooting because the ssh session is so tightly sandboxed and restricted.  Remote syslog seems to have 2 settings, one of which logs (AFAICT) nothing and the other produces a huge volume of noise.

This is a link to the latest deviceinfo dump taken while several 2.4GHz devices are in their weird "Connected" but offline state.

Let me stress: Everything worked flawlessly when the EAP was in standalone mode, with PoE, not adopted to the controller.

I'm almost ready to admit defeat and return the EAP for a refund.