Also happens when using Windows "ping" command line tool:

c:\>ping -l 62500 192.168.0.1

Pinging 192.168.0.1 with 62500 bytes of data:
Reply from 192.168.0.1: bytes=62500 time=2ms TTL=64
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms

TP-Link router has some bug with number of ip fragements (fragment reassembly)

This seems to work (33 fragments):

fastping -l:48832 -n:1000 192.168.0.1

This is the point at which things start to fail (34 fragments):

fastping -l:48833 -n:1000 192.168.0.1

TP-Link support, thanks for the private reply, but you don't understand the problem.  "Large" ping means large sized ping, not large RTT response times as your reply incorrectly assumes.

I also have an AX80, and it has the same problem, only much worse, as seen below:

c:\>fastping -l:50000 192.168.0.1
2024/01/06 05:18:37
fastping.exe -n:10 -l:50000 -ms:0 -w:1000 -i:64 192.168.0.1

nSeq    nHost   tSent   ms      Mbps    info
0       0       0.000   *       0.0     IP_REQ_TIMED_OUT
1       0       1.004   *       0.0     IP_REQ_TIMED_OUT
2       0       2.005   *       0.0     IP_REQ_TIMED_OUT
3       0       3.008   *       0.0     IP_REQ_TIMED_OUT
4       0       4.010   *       0.0     IP_REQ_TIMED_OUT
5       0       5.012   *       0.0     IP_REQ_TIMED_OUT
6       0       6.014   *       0.0     IP_REQ_TIMED_OUT
7       0       7.017   *       0.0     IP_REQ_TIMED_OUT
8       0       8.019   *       0.0     IP_REQ_TIMED_OUT
9       0       9.021   *       0.0     IP_REQ_TIMED_OUT
----------

c:\>fastping -l:40000 192.168.0.1
2024/01/06 05:18:57
fastping.exe -n:10 -l:40000 -ms:0 -w:1000 -i:64 192.168.0.1

nSeq    nHost   tSent   ms      Mbps    info
0       0       0.000   2.514   254.5
1       0       0.012   2.026   315.8
2       0       0.015   2.073   308.7
3       0       0.018   2.008   318.7
4       0       0.020   1.959   326.6
5       0       0.023   1.941   329.7
6       0       0.025   3.055   209.4
7       0       0.029   1.943   329.3
8       0       0.032   2.089   306.3
9       0       0.034   1.974   324.2
----------
800000+840 bytes in 21 ms (296.8 Mbps)
Errors: 0  Hung: 0

--> The TP-Link bug is that TP-Link routers can not handle ICMP packets composed of too many fragments.  Please forward that to FW teams to fix.  Netgear (and other brands) do not have this bug.

TP-Link support,  Since you are having so much trouble understanding the problem (the last email from support ignored what I wrote above), let's greatly simplify the test setup so that there is only a single TP-Link device:

• Plug in TP-Link router (I am testing AX80 and AXE75, both have problems), set it up and unplug the Ethernet cable.  So now there is only the TP-Link router and NO other equipment.
• Now ping the TP-Link router with an ICMP ping of size 48,000 -- notice that ping works
• Now ping the TP-Link router with an ICMP ping of size 50,000 -- notice that ping breaks
• repeat test with any modern Netgear router and note that ping never breaks

Additional info:

• This bug is only with Wi-Fi interfaces.  The bug does not happen when LAN ports are used.
• I do not see the bug when using a BE550

Can anyone else replicate this issue with the TP-Link AX80 and a Windows computer Wi-Fi?  If not, that is important info as well.

ping -l 62500 192.168.0.1

where 192.168.0.1 is the ip address of the TP-link router (AX80).