Solved Aimesh high packet loss

[Plompie]

Hi All, I have a setup with 2 mesh nodes (ac68u) connected to a ac86u router, all connected wired.

When the nodes are connected via manual setup (access point mode), the wired connections to the nodes are super stable (0% packet loss, 2ms ping). When I switch the setup to aimesh I get 70% package loss and obviously the connection becomes unusable. Tried to reset to factory several times, tried all combinations of stock and Merlin firmware and switched the mesh system to wired back haul only. But the package loss persist.

Anyone with the same issue, ideas or solutions?

 

[thiggins]

Where is the "to" connection of your ping? The router? An internet host?

When you are pinging via AiMesh, how is the mesh configured and where is the device connected?

When you use Ethernet backhaul, there is only one wireless connection. If the signal level between AP and device is strong, you should have the low packet loss you see.

When backhaul is wireless, there are multiple wireless retransmissions. If any of those connections have low signal levels, you can have packet loss.

This could be an indication that your mesh nodes need to be repositioned.

 

[Plompie]

Thanks for your reply:

Where is the "to" connection of your ping? The router? An internet host?
-> I tried the router on 192.168.1.1 and google.com (which translates in my area to 172.217.17.46). Both have the same high loss. When they do reply it's in abt 2ms
-> When I ping the AiMesh node from the workstation that is directly connected I get 0% loss and <0ms reply.
Also see below

When you are pinging via AiMesh, how is the mesh configured and where is the device connected?
-> Is wired (both workstation to Mesh node and Mesh node to router). Node <-> router WAN(on node) <-> LAN (on router)

When you use Ethernet backhaul, there is only one wireless connection. If the signal level between AP and device is strong, you should have the low packet loss you see.
-> I use a wired connection all the way. Wireless is even worse so I'm now focusing on the wired connections so I don't have to worry about WiFi signals for time being.

Ping on google.com

Reply from 172.217.17.46: bytes=32 time=2ms TTL=118
Request timed out.
Reply from 172.217.17.46: bytes=32 time=2ms TTL=118
Request timed out.
Reply from 172.217.17.46: bytes=32 time=2ms TTL=118
Request timed out.
Reply from 172.217.17.46: bytes=32 time=2ms TTL=118
Request timed out.
Reply from 172.217.17.46: bytes=32 time=2ms TTL=118
Request timed out.
Reply from 172.217.17.46: bytes=32 time=2ms TTL=118
Request timed out.
Reply from 172.217.17.46: bytes=32 time=2ms TTL=118
Request timed out.
Reply from 172.217.17.46: bytes=32 time=2ms TTL=118
Request timed out.
Reply from 172.217.17.46: bytes=32 time=2ms TTL=118
Request timed out.
Reply from 172.217.17.46: bytes=32 time=2ms TTL=118

Ping statistics for 172.217.17.46:
    Packets: Sent = 137, Received = 69, Lost = 68 (49% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 23ms, Average = 2ms

Ping on the router

Pinging 192.168.1.1 with 32 bytes of data:
Request timed out.
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Request timed out.

Ping statistics for 192.168.1.1:
    Packets: Sent = 9, Received = 4, Lost = 5 (55% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Ping on the AiMesh Node

Pinging 192.168.1.204 with 32 bytes of data:
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64
Reply from 192.168.1.204: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.204:
    Packets: Sent = 14, Received = 14, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

 

[ColinTaylor]

It seems rather suspicious that your ping is loosing every other packet rather than random packets. What happens if you completely disconnect one of the nodes so that you only have one?

 

[Plompie]

Indeed it seems to become better when only one node is connected but still 28% loss. It so strange that with the exact same hardware configuration but the nodes manually as Access Point this issues doesn't seem to appear. Then only the WiFi shows packet loss.

Pinging google.com [172.217.20.78] with 32 bytes of data:
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Request timed out.
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Request timed out.
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Request timed out.
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Request timed out.
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Request timed out.
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119
Request timed out.
Reply from 172.217.20.78: bytes=32 time=2ms TTL=119

Ping statistics for 172.217.20.78:
    Packets: Sent = 21, Received = 15, Lost = 6 (28% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms

 

[thiggins]

So in both cases, the "mesh" modes are connected to the root node router via Ethernet.

If that's the case, forget what I said. I don't know what AiMesh does when it has an Ethernet backhaul.

I don't know why you'd mess with AiMesh anyway, if you have Ethernet backhaul.

 

[thiggins]

Sorry, I'm still confused. What do you mean "only the WiFi shows packet loss"?

In both cases are you pinging from a Wi-Fi connected device?

 

[Plompie]

Sorry, I'm still confused. What do you mean "only the WiFi shows packet loss"?

In both cases are you pinging from a Wi-Fi connected device?

I tried AiMesh because of easy maintenance and ability to set guest network from the Nodes since the AiMesh 2.0 update.

Due to the package loss issues I'm now testing everything via Wired connections, just to avoid any possible issues related with WiFi signals.

Wireless is even worse so I'm now focusing on the wired connections so I don't have to worry about WiFi signals for time being.

Another thing I just noticed when I shutdown the 2nd Node is a change in Log entries:

Jan 30 15:47:12 kernel: XX:XX:XX:XX:A6:6E not mesh client, can't update it's ip
Jan 30 15:47:12 kernel: XX:XX:XX:XX:6D:21 not mesh client, can't update it's ip
Jan 30 15:47:12 kernel: XX:XX:XX:XX:D6:67 not mesh client, can't update it's ip
Jan 30 15:47:14 kernel: XX:XX:XX:XX:A6:6E not mesh client, can't update it's ip
Jan 30 15:47:15 kernel: XX:XX:XX:XX6D:21 not mesh client, can't update it's ip
Jan 30 15:47:15 kernel: XX:XX:XX:XXD6:67 not mesh client, can't update it's ip
Jan 30 15:47:16 kernel: XX:XX:XX:XX:A6:6E not mesh client, can't update it's ip
Jan 30 15:47:16 kernel: XX:XX:XX:XX6D:21 not mesh client, can't update it's ip
Jan 30 15:47:16 kernel: XX:XX:XX:XXD6:67 not mesh client, can't update it's ip
Jan 30 15:47:17 kernel: XX:XX:XX:XX:A6:6E not mesh client, can't update it's ip
Jan 30 15:47:17 kernel: XX:XX:XX:XX6D:21 not mesh client, can't update it's ip
Jan 30 15:47:17 kernel: XX:XX:XX:XXD6:67 not mesh client, can't update it's ip
Jan 30 15:47:22 kernel: XX:XX:XX:XX:A6:6E not mesh client, can't update it's ip
Jan 30 15:47:22 kernel: XX:XX:XX:XX6D:21 not mesh client, can't update it's ip
Jan 30 15:47:22 kernel: XX:XX:XX:XXD6:67 not mesh client, can't update it's ip
Jan 30 15:48:30 kernel: XX:XX:XX:XX:A6:6E not mesh client, can't update it's ip
Jan 30 15:48:30 kernel: XX:XX:XX:XX6D:21 not mesh client, can't update it's ip
Jan 30 15:48:30 kernel: XX:XX:XX:XXD6:67 not mesh client, can't update it's ip
//SHUTDOWN ONE OF THE TWO NODES//
Jan 30 15:48:56 wlceventd: wlceventd_proc_event(507): eth6: Disassoc XX:XX:XX:XX:D6:67, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 30 15:48:56 wlceventd: wlceventd_proc_event(526): eth6: Auth XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:48:56 wlceventd: wlceventd_proc_event(490): eth6: Deauth_ind XX:XX:XX:XX:D6:67, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Jan 30 15:48:56 wlceventd: wlceventd_proc_event(526): eth6: Auth XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:48:56 wlceventd: wlceventd_proc_event(555): eth6: Assoc XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:48:57 wlceventd: wlceventd_proc_event(555): eth6: Assoc XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:49:02 wlceventd: wlceventd_proc_event(507): eth6: Disassoc XX:XX:XX:XX:D6:67, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 30 15:49:06 wlceventd: wlceventd_proc_event(526): eth6: Auth XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:49:06 wlceventd: wlceventd_proc_event(555): eth6: Assoc XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:49:07 wlceventd: wlceventd_proc_event(555): eth6: Assoc XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:49:07 wlceventd: wlceventd_proc_event(555): eth6: Assoc XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:49:12 wlceventd: wlceventd_proc_event(507): eth6: Disassoc XX:XX:XX:XX:D6:67, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 30 15:49:13 wlceventd: wlceventd_proc_event(526): eth6: Auth XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:49:13 wlceventd: wlceventd_proc_event(526): eth6: Auth XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:49:13 wlceventd: wlceventd_proc_event(555): eth6: Assoc XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:49:14 wlceventd: wlceventd_proc_event(555): eth6: Assoc XX:XX:XX:XX:D6:67, status: Successful (0), rssi:0
Jan 30 15:49:19 wlceventd: wlceventd_proc_event(507): eth6: Disassoc XX:XX:XX:XX:D6:67, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

 

[L&LD]

Your network is not a typical example of what I see with similar equipment and the RMerlin 386.1 Beta 5 (or later) firmware.

With over a hundred views of this thread, I think if an easy solution were available, it would have been stated, by now.

I would be setting my router/network back to a good/known state and proceeding very cautiously with any customizations past the suggested defaults from the (links) below.

Start with the Update/Reset Mini Guide link and you should soon be able to eliminate any glitches from your network if the suggested steps don't take care of that already.

Control Channel Setup 2021

 

[Plompie]

Thanks for that!

At first sight many tips are for WiFi but with my setup even the wired devices have packetloss. Will walk trough them anyway, starting with a fresh reset again can never harm.

 

[Plompie]

Your network is not a typical example of what I see with similar equipment and the RMerlin 386.1 Beta 5 (or later) firmware.

With over a hundred views of this thread, I think if an easy solution were available, it would have been stated, by now.

I would be setting my router/network back to a good/known state and proceeding very cautiously with any customizations past the suggested defaults from the (links) below.

Start with the Update/Reset Mini Guide link and you should soon be able to eliminate any glitches from your network if the suggested steps don't take care of that already.

Control Channel Setup 2021

Must admit I didn’t have much faith in these tips as they were mostly WiFi related. But as I wasn’t making any progress I started anyway and I must say it actually worked!

Not sure which action did the trick but I only changed three settings:

1. Set a LAN domain name
2. Changed WiFi preamble to short
3. Disabled Universal Beamforming

The WiFi and Ethernet form one network off course so maybe something on the WiFi created so much noise that it also created packet loss...?

Anyway thanks to all for your support!

 

[Plompie]

Just to close off on this topic. After a little while I started experience the same problems again. So I did more digging and finally found out what caused it, I'm now also able to reproduce the issue.

It was the Guest Network sharing over de AiMesh nodes. As soon as I active it (only possible on the first instance), I get the packet loss. It seems however that the settings are not always pushed properly to the nodes, if this fails the above solution seems to work until the setting pushed trough after all (restart or other setting update) and then the packet loss on the nodes starts again.

I have now only a guest network on the main "router only" and my system is super stable again. Have set it on the 3rd instance to avoid any accidental Sync / push to the nodes (Sync to Node is only available on the 1st instance).