@Hank21 

1. Is there any VLAN settings on your EAP and the switch?
There are no VLAN settings on the EAP or the switch.

2. How you connect the whole network (including the EAP/switch/router)?
It's a fiber ONU in bridge mode (500/500) connected to a mikrotik router to unmanaged switches.  A TP-Link AX1500 is connected to the switch, configured in AP mode with only 5ghz enabled.  The TP-Link EAP110 is also connected to the switch to provide 2.4ghz.

3. If you reset this EAP and only leave it as default settings, will you see the same high RX dropped packets?
I did a factory reset, and still see the same high RX dropped packets.

My configuration is simple, anyway, to set the Wireless Mode to 802.11N only, channel width to 20MHz, channel to 6.  Also enable system log server to log to my rsyslog server, enable SSH server and change the port, and set NTP servers.  I don't see anything unusual in the system logs, just the usual message when it gets it's IP address when it boots.

I notice the LAN RX Dropped Packets increase the most when I run a speed test, while it's doing the Upload test.

I have similar problem.

Two EAP-110 running with IP cameras with high IP traffic. Both have incredibly high numbers of dropped RX LAN packets. 

One is mostly receiving data (EAP-110 Outdoor) and one mostly sending traffic (EAP-110EU v4 indoor), so it's not correlated with direction of load. Outdoor EAP-110 even occasionally resets it's network configuration and requires manual adoption.

Both have latest firmware and are managed by latest Omada Software Controller. No VLANs, they are connected to different switches. Each has one or two wireless clients with strong signal (above -59 dBm).

My other EAP110 and EAP225 APs with lower traffic are not experiencing any problems.

Any suggestions? The problem probably results in periodic disconnection of EAP from the network and necessity to re-adopt it.

  @JackShepard Hopefully tp-link will respond.  For myself, I haven't noticed any problems with the actual connections.  I'm not using it with a controller, though.  I suspect it may be a display issue, probably due to incompatible numeric data types being used.  That would mean the high number of dropped packets aren't being reported accurately.

  @david3 

The same problem here, i noticed such eap's behavior 2 years ago. With every new fw update I hope something gonna be changed, but no.

  @Ppzio There seems to be a disparity between the ifconfig dropped packets and what's reported on the web page.

The web page shows 44,904% dropped packets (that's a comma, not a decimal point, fourty-four-thousand percent), whereas ifconfig shows 0.44% dropped packets.  I suspect it's a bug in the way it's being recorded or reported, and not an actual performance problem.