Poor Client to Client network - GL-MT300N-V2

GL.iNet GL-MT300N-V2 Mango running v4.3.25.
Internet is Ethernet. Internet Gateway is 192.168.50.1.
Network LAN is 192.168.8.1 (default).

Two clients connected.
Both clients connect to Mango. Both clients can connect to Internet.

But clients cannot reliably communicate with each other. If Client1 pings Client2,
the first ping time is very long, like 400ms. Before dropping back down to 3ms.

Often one client will get a No Route To Host error before eventually succeeding
with the connection.

Does anyone have an idea why the client to client network is so unstable?
So unreliable?

If I replace the Mango with an Asus router, the client to client communication
is perfect. Everything works well. So I do not think this is a client issue.

Only when clients are connected to the GL-MT300N-V2 do problems come up.

I'm at a loss for possible next steps to debug.
Thank you!

WireGuard does not proactively establish a connection by default, and triggers key exchange (including Initiation and Response messages) on the first data transfer.

In addition, the performance of MT300Nv2 is low, and the WG client to client session may not be able to actively keep the WG client session alive.
But if the session between clients can be activated and handshake, like through ping, and the link will be relatively stable after the handshake.

In addition, if there is NAT on the upper layer of MT300Nv2 (means MT300Nv2 is not the main route), the handshake may need to be re-established once the NAT session table expires.

Thank you for the response. My inter-client traffic is very low. Just a few MQTT messages between the clients. I do not think I need a high performance device. I think I can craft a small cronjob/script that just pings other clients periodically. I hope that keeps the connection alive.

My use case is to just use the Mango as a low-power-consumption repeater between a handful of clients exchanging occasional JSON messages over MQTT.

Quick follow-up - is WireGuard easily disabled from the UI?

Thank you!

If the interval between MQTT messages is sent for a long time (the message interval time is greater than the alive of the VPN session), you can write a ping in crontab to keep the session alive.

I don’t understand this question much.
If you need to enable or disable WG server/client, that can operate in the GL GUI, but it is not so easily, since you need to login to the GL GUI by password.

The Wi-Fi repeater of the Mango GL-MT300N-V2 is unstable, it bugs a lot. Please, I need help even though I did the latest update, but it persists and it's annoying."
:pray::pray::pray::pray::pray::pray::pray::pray::pray::pray::pray:

Hello,

Is the MT300Nv2 repeater disconnected the primary WiFi? or it connected but no internet?

Please share the issue syslog with us through PM.

I have had good results with the WiFi repeater part of the MT300NV2. Once connected, it seems to stay connected.

I've "fixed" the client-to-client problems by having the clients ping each other excessively. Each client pings each other for 290 times every five minutes. That's kept the client-to-client connections alive.

I did notice one other problem: disconnecting the Ethernet connection did not automatically cause the Repeater to connect to the WiFi. I had to use the GUI to reconnect the WiFi Repeater.