@Kevin_Z 

"If I understand your description correctly, is the network layout as below?

Router (running OPNsense, wifi is disabled) --- Switch (Archer C7 v4, running OpenWrt, wifi is disabled) --- AX21 (AP mode)"

Yes, that is correct (that would be the condition it will be working in once/if I can get it reliable)

"How did you configure the AX21 as an Access Point? Case 1 or Case 2 as per this guide?"

I configured the AX21 as an Access Point via Case 1, switching the operation mode

"Is it possible to connect the AX21 to the main router directly bypassing the Switch? Will it behave the same?"

I will attempt that.

"What are the IP addresses of these three devices, the Router, Switch, and AX21? Are the Switch and AX21 both using static IP addresses? If not, please try to assign static IP addresses for both of them and ensure they are in the same IP subnet of the main router, then monitor the connectivity again."

The router is using 192.168.1.1, the Switch is using 192.168.1.2 and the AX21 is using 192.168.1.3, all static ips (and are out of the range of the DHCP pool, the pool starts at 192.168.1.100 to 192.168.1.200)

I don't want to Jynx it but it has been 24 hours (probably won't feel safe until 48 hours) and no crash. If it is indeed fixed (and I hope it is), do you know any reason why connecting it through the Switch would cause a crash but connecting it directly to the router would not? I ruled the switch out as a possibility as every other device connected to it works perfectly fine but perhaps there might be something wrong with the switch or the firmware on the AX21?

Edit: it has now been 48 hours and it has not crashed (a good sign), I have now enabled WiFi 2.4G + WiFi 5G (it was only routing packets for the 48 hours so adding more load as I plan to use it in this scenerio and it is no doubt more intensive than routing packets)

Edit 2: it has been ~72 hours (24 hours after WiFi 2.4G and 5G activated) and still stable, I think it is fixed but that is still baffling to why that change would change anything?

  @Kevin_Z This may be unrelated but sad to say, after 8 days of uptime, it crashed, although rebooting the AP every 8 days I guess is acceptable (if it is consistent) but definitely not desirable.

Edit: it is not consistent, after rebooting after the crash after 8 days, it took 1 hour to crash again, this time interestingly it might've noticed it was in a failed state as it rebooted entirely on its own but after this automated reboot, the AP only survived for a staggering minute so it is not viable even after bypassing the switch.

  @Kevin_Z I have now removed the Switch and the pfSense router from my setup and have the router running in the normal operating mode (router mode, not ap mode) but there still seems to be an issue, it locks up. Unfortunately even with UART connected to the router, there is no error, no stacktrace in the output and after reviewing the firmware from the website for my router with `binwalk`, I see that there is no valid password set for any of them and for those without a password `guest` the shell is not valid, so I have no way of getting a shell inside the device to get more information and possible confirmation for my theories, one of which is a thermal theory, it overheats but it doesn't make sense that the device wouldn't just restart or shut down linux properly. Here is the log from UART of the startup to the crash and the subsequent restart (in case the device can detect a failed state from last boot but that doesn't appear to be the case)

htt ps://pastebin. com/N7yHugaB (I needed to split up the link as it is impractical to paste it all in (I did try but "illegal links filter") and links filter)

  @Kevin_Z I am not sure whether you guys are still producing the AX21 (Also known as the AX1800 from the Web UI and AX20 from the UART log) but I found the issue, it is indeed an issue with the thermals specifically the BCM53134, the ethernet switch chip. In order to remedy this issue, I just put a heatsink on the chip that is a bit larger than the surface area of the chip itself (I can attach a picture later if needed). If this is not already fixed in later hardware revisions, I would recommend you pass this on to the team that designs the routers. If you want to know how to reproduce this consistently, I have found running 2 speedtests via speedtest-cli on 2 seperate machines on different lan ports heats the chip up fairly quickly, after around 10-20 minutes, the router will shut itself off (likely to save the chip from getting damaged) and after adding the heatsink (and puttting the top cover on), the router seems to manage fine without crashing. Just to be safe though, I will be slamming the router for 7 days (via the above method) to see if it needs a fan (it likely wouldn't, maybe just a bigger heatsink (I'm sure for this router and maybe all of your routers, you prefer a passive cooling design) but I don't have a bigger one and I do have a 120mm fan so that will be my remedy) or if there are any other issues.

Edit: The heatsink seemed to prolong the locking so not sure if that was the issue, maybe just one of many or it wasn't the issue or needed a bigger heatsink.

Edit 2: unfortunately with such an experience, I am going to get a router that is not Broadcom based (and probably not TP-Link either) as that limits and in some cases completely shuts down custom firmware ability (in case this crash was related to firmware and not hardware)