Update: 

The TP-Link support said that they cannot recreate the problem. Perhaps all of you can also email TP-Link support to let them know that you also have problem with the AX12 in AP mode.

  @HappySmile 

So if they cannot reproduce it, it means they are not trying, if anybody can return it I suggest to do so and buy an already tested device.

Sad since the device has good specs and a good price

Tschabha wrote

Now I switched back to the original setup, but paralelly I am operating the AX12 with different SSID than the others on different WIFI RF bands. I am testing it with one tablet and smartphone. This way the problem disappeared: these two endpoint can use the AP without problems, there is no dropping off. 

 

@cimonroyb

This worked for me. If I use the same SSID as other Access Points then the problem occurs.

@terziyski

Here you go

  @terziyski 

Thank you for the suggestions. After following it, unfortunately I still experience connection drops and clients unable to obtain IP addresses. My archer a8 in the network works properly. Do you think this is the problem of AX12 firmware?

Yes the connection is to lan port to AX12 wan port.

Regarding the system log messages of my main router (ER-605), I don't see any errors that may be relevant to the problem.
Regarding the system log messages of the AX12, I see logs that the router is requesting an IP address from the server.

  @terziyski 
Unfortunately, it is still the same. 

  @Kevin_Z 

Thanks for the reply! See my comments below...

First to clarify the model, make, type, SW, etc...:

About the model: both model numbers are present on the box: AX1500 and Archer AX12. On te administration webpage, on the top left part it says "tp-link AX1500 Gigabit Wi-Fi 6 Router", while on the Firmware Update menu it reports "Hardware Version: Archer AX12 v1.0". Also the firmware version reported is: "1.0.20 Build 20230616 Rel. 40941(4555)"

Q1:

There were originally 3 AP-s in the building I have to cover with WiFI infrastructure, to obtain a reasonable signal strength everywhere. One of them is the Internet router (LINKSYS WRT1200AC) the other one is a TP-Link Wireless N Access Point WA801N, and the third one was a TP-Link Archer C20 AC750 Dual Band router used as an AP. The plan was to replace the latter with an AP with GbEthernet LAN port (the AX1500) as the internal LAN infrastructure is now pure GbE and the Internet bandwith was also upgraded to 300Mbps/300Mbps. Originally all the AP-s were set to use the same SSID and password, and were operating on different 2.4/5GHz bands, configured and controlled manually. Everything worked fine, as the WIFI endpoints would roam automatically between these AP-s. After I switched the Archer C20 to Archer AX1500, the problems began to appear: the clients connecting to the AX1500 periodically dropped connection for seome strange reason, which I began to investigate further. I switched back to the original setup, but paralelly I was operating the AX12 with different SSID than the other APs on different WIFI RF bands, connected to the same LAN (I triedLAN poert and WAN port as well but it made nodifference). So now i have 3 AP with [SSID1] and the AX1500 with [SSID2] on the same LAN, with one working DHCP server (a LINUX machine). I began testing it with one tablet and smartphone set to automatically connect only to the AX1500 AP. The problem still remained. So I have noticed that endpoints can assiciate with the AP but they can not get IP address from the DHCP server.

Q2:

I have double checked that I have only one DHCP server working on the LAN and the DHCP server on AX1500 is swithed off.

I can confirm, that although the DHCP server is switched off in the AX1500 it somehow interferes with the DHCP protocol. The DHCP server gets the DHCPDISCOVER requests from the wireless clients on the AX1500 - so the clients can associate with the AP (!) - but the DHCPOFFER packets seem to disappear somewhere along the route... So the clients can not negotiate IP address.

There are some other wierd log entries in the system log which I do not understand, but it might have nothing to do with this issue....

2023-08-04 00:07:13 Led Controller INFO [1859] Start to run WAN1_OFF

2023-08-04 00:07:13 Led Controller INFO [1859] Start to run WAN0_OFF

2023-08-04 00:07:13 Led Controller ERROR [1859] Config importing failed

2023-08-04 00:07:13 Led Controller DEBUG [1859] Failed to read LAN_ON

2023-08-04 00:07:11 Led Controller INFO [1859] Start to run WAN1_OFF

2023-08-04 00:07:11 Led Controller INFO [1859] Start to run WAN0_ON

2023-08-04 00:07:11 Led Controller ERROR [1859] Config importing failed

2023-08-04 00:07:11 Led Controller DEBUG [1859] Failed to read LAN_ON