What's new

ASUS RT-AX86U local network WIFI Ping issue 388.1

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

geoffroyg

Occasional Visitor
Hi,

I have 3 AX86U in Aimesh (wifi backhaul)

Since I upgraded to 388.1, I am getting a lot of short disconnect issue on WIFI, and also very slow ping to wifi devices on the local network. No issue on ethernet.

Anyone else experiencing this? If anyone has an idea of what could cause this?

Pinging a wifi device connected to the Main router.

Request timeout for icmp_seq 0
64 bytes from 192.168.3.203: icmp_seq=0 ttl=64 time=1666.141 ms
Request timeout for icmp_seq 2
64 bytes from 192.168.3.203: icmp_seq=1 ttl=64 time=2297.984 ms
64 bytes from 192.168.3.203: icmp_seq=2 ttl=64 time=1297.898 ms
64 bytes from 192.168.3.203: icmp_seq=3 ttl=64 time=450.337 ms
64 bytes from 192.168.3.203: icmp_seq=4 ttl=64 time=225.543 ms
64 bytes from 192.168.3.203: icmp_seq=5 ttl=64 time=1284.424 ms
64 bytes from 192.168.3.203: icmp_seq=6 ttl=64 time=592.623 ms
64 bytes from 192.168.3.203: icmp_seq=7 ttl=64 time=770.034 ms


Pinging one of the satelite Aimesh ax86u gives these results:

PING 192.168.3.210 (192.168.3.210): 56 data bytes
64 bytes from 192.168.3.210: icmp_seq=0 ttl=64 time=2.190 ms
64 bytes from 192.168.3.210: icmp_seq=1 ttl=64 time=8.886 ms
64 bytes from 192.168.3.210: icmp_seq=2 ttl=64 time=32.671 ms
64 bytes from 192.168.3.210: icmp_seq=3 ttl=64 time=52.867 ms
64 bytes from 192.168.3.210: icmp_seq=4 ttl=64 time=75.811 ms
64 bytes from 192.168.3.210: icmp_seq=5 ttl=64 time=3.677 ms
64 bytes from 192.168.3.210: icmp_seq=6 ttl=64 time=19.809 ms
64 bytes from 192.168.3.210: icmp_seq=7 ttl=64 time=1.942 ms
64 bytes from 192.168.3.210: icmp_seq=8 ttl=64 time=70.872 ms
64 bytes from 192.168.3.210: icmp_seq=9 ttl=64 time=81.417 ms
64 bytes from 192.168.3.210: icmp_seq=10 ttl=64 time=3.099 ms
 
Hi,

I have 3 AX86U in Aimesh (wifi backhaul)

Since I upgraded to 388.1, I am getting a lot of short disconnect issue on WIFI, and also very slow ping to wifi devices on the local network. No issue on ethernet.

Anyone else experiencing this? If anyone has an idea of what could cause this?

Pinging a wifi device connected to the Main router.

Request timeout for icmp_seq 0
64 bytes from 192.168.3.203: icmp_seq=0 ttl=64 time=1666.141 ms
Request timeout for icmp_seq 2
64 bytes from 192.168.3.203: icmp_seq=1 ttl=64 time=2297.984 ms
64 bytes from 192.168.3.203: icmp_seq=2 ttl=64 time=1297.898 ms
64 bytes from 192.168.3.203: icmp_seq=3 ttl=64 time=450.337 ms
64 bytes from 192.168.3.203: icmp_seq=4 ttl=64 time=225.543 ms
64 bytes from 192.168.3.203: icmp_seq=5 ttl=64 time=1284.424 ms
64 bytes from 192.168.3.203: icmp_seq=6 ttl=64 time=592.623 ms
64 bytes from 192.168.3.203: icmp_seq=7 ttl=64 time=770.034 ms


Pinging one of the satelite Aimesh ax86u gives these results:

PING 192.168.3.210 (192.168.3.210): 56 data bytes
64 bytes from 192.168.3.210: icmp_seq=0 ttl=64 time=2.190 ms
64 bytes from 192.168.3.210: icmp_seq=1 ttl=64 time=8.886 ms
64 bytes from 192.168.3.210: icmp_seq=2 ttl=64 time=32.671 ms
64 bytes from 192.168.3.210: icmp_seq=3 ttl=64 time=52.867 ms
64 bytes from 192.168.3.210: icmp_seq=4 ttl=64 time=75.811 ms
64 bytes from 192.168.3.210: icmp_seq=5 ttl=64 time=3.677 ms
64 bytes from 192.168.3.210: icmp_seq=6 ttl=64 time=19.809 ms
64 bytes from 192.168.3.210: icmp_seq=7 ttl=64 time=1.942 ms
64 bytes from 192.168.3.210: icmp_seq=8 ttl=64 time=70.872 ms
64 bytes from 192.168.3.210: icmp_seq=9 ttl=64 time=81.417 ms
64 bytes from 192.168.3.210: icmp_seq=10 ttl=64 time=3.099 ms
I'm afraid most of us with RT-AX86U's are experiencing quirkiness with 388.1 - especially with AiMesh as a Node for this router model.
You will see from my signature that I have reverted to 386.5_2 firmware on both of my RT-AX86U's and am back enjoying rock stead and speedy service from main and node.

You only other option is to run 388.1 on the main router only - and then run Asus stock firmware on the AiMesh Nodes.
Sadly you will not get any support at all from the developer of Merlinware because AiMesh is closed source and beyond his control - as are all WiFi drivers and their bugs.
 
I'm afraid most of us with RT-AX86U's are experiencing quirkiness with 388.1 - especially with AiMesh as a Node for this router model.
You will see from my signature that I have reverted to 386.5_2 firmware on both of my RT-AX86U's and am back enjoying rock stead and speedy service from main and node.

You only other option is to run 388.1 on the main router only - and then run Asus stock firmware on the AiMesh Nodes.
Sadly you will not get any support at all from the developer of Merlinware because AiMesh is closed source and beyond his control - as are all WiFi drivers and their bugs.
Thank you for your answer. I did downgrade to 386.5_2 and all problem solved. I found the issue, because I had to understand, what was causing those gigantic ping on my local network.

The answer is Guest Network. I was using a guest network and funneled it to a wireguard VPN. I wanted to have a specific SSID that would be directed to VPN. That caused the issue. I wanted to get rid of my other set of Aimesh routers specifically for that VPN... I guess they will stay for a while untill this is fixed.
 
Take note that on firmware 386.5_2 you must set "NO" in answer to "Intercept NTP client requests" on the Administration > System tab.
intercepts-no.png

There is a bug in the coding which was fixed in 388.1 - but exists still in 386.5_2 and in 386.7_2
If you answer YES to intercept ... the redirection of Guest Networks to a VPN Client simply does not work.
 
You only other option is to run 388.1 on the main router only - and then run Asus stock firmware on the AiMesh Nodes.
Sadly you will not get any support at all from the developer of Merlinware because AiMesh is closed source and beyond his control - as are all WiFi drivers and their bugs.
For me it didnt worked. I have installed 388.1 on main router and Asus stock on AiMesh, but have same problems. So I believe only reverting both, router and node, to previous would be solution (will do that and check during next following days)
 
Yes I have similar and found my AX86U nodes were dropping offline briefly even using stock firmware on the nodes and Merlin 388.1 on my RT-AX88U main router. There is something broken in 388 affecting the AX86U either with the Merlin main router losing the AX86U nodes, or in the stock AX86U firmware running as a node (more likely). I don't have the chance to run stock firmware to test on my main router as my network is awful without CAKE QoS.

I posted more info in this thread https://www.snbforums.com/threads/a...ing-with-new-firmware-when-downloading.82384/
 
My AX86U performance become erratic with latest Asus Merlin 388.1 upgrade. WAN speeds irregular, and wifi connections drops intermittently. Downgraded back to 386.7_2 and everything went back smooth steady.
 
I must wonder what it is that all of you experiencing problems are doing that I'm not. For one thing, my nodes are connected via ethernet. Before I wired my nodes, I found that 80 wide was much more stable yet I know part of the 160 wide issue is DFS use and my proximity to an airport.
 
Hi,

I have 3 AX86U in Aimesh (wifi backhaul)

Since I upgraded to 388.1, I am getting a lot of short disconnect issue on WIFI, and also very slow ping to wifi devices on the local network. No issue on ethernet.

Anyone else experiencing this? If anyone has an idea of what could cause this?

Pinging a wifi device connected to the Main router.

Request timeout for icmp_seq 0
64 bytes from 192.168.3.203: icmp_seq=0 ttl=64 time=1666.141 ms
Request timeout for icmp_seq 2
64 bytes from 192.168.3.203: icmp_seq=1 ttl=64 time=2297.984 ms
64 bytes from 192.168.3.203: icmp_seq=2 ttl=64 time=1297.898 ms
64 bytes from 192.168.3.203: icmp_seq=3 ttl=64 time=450.337 ms
64 bytes from 192.168.3.203: icmp_seq=4 ttl=64 time=225.543 ms
64 bytes from 192.168.3.203: icmp_seq=5 ttl=64 time=1284.424 ms
64 bytes from 192.168.3.203: icmp_seq=6 ttl=64 time=592.623 ms
64 bytes from 192.168.3.203: icmp_seq=7 ttl=64 time=770.034 ms


Pinging one of the satelite Aimesh ax86u gives these results:

PING 192.168.3.210 (192.168.3.210): 56 data bytes
64 bytes from 192.168.3.210: icmp_seq=0 ttl=64 time=2.190 ms
64 bytes from 192.168.3.210: icmp_seq=1 ttl=64 time=8.886 ms
64 bytes from 192.168.3.210: icmp_seq=2 ttl=64 time=32.671 ms
64 bytes from 192.168.3.210: icmp_seq=3 ttl=64 time=52.867 ms
64 bytes from 192.168.3.210: icmp_seq=4 ttl=64 time=75.811 ms
64 bytes from 192.168.3.210: icmp_seq=5 ttl=64 time=3.677 ms
64 bytes from 192.168.3.210: icmp_seq=6 ttl=64 time=19.809 ms
64 bytes from 192.168.3.210: icmp_seq=7 ttl=64 time=1.942 ms
64 bytes from 192.168.3.210: icmp_seq=8 ttl=64 time=70.872 ms
64 bytes from 192.168.3.210: icmp_seq=9 ttl=64 time=81.417 ms
64 bytes from 192.168.3.210: icmp_seq=10 ttl=64 time=3.099 ms

Thank you for your answer. I did downgrade to 386.5_2 and all problem solved. I found the issue, because I had to understand, what was causing those gigantic ping on my local network.

The answer is Guest Network. I was using a guest network and funneled it to a wireguard VPN. I wanted to have a specific SSID that would be directed to VPN. That caused the issue. I wanted to get rid of my other set of Aimesh routers specifically for that VPN... I guess they will stay for a while untill this is fixed.

When you downgraded, was did you have the router on the same channel as when you had the long pings? The pings you are showing are typical of a congested network or channel
 
Sorry to resurrect an older thread, but wondering if this might be similar to the problem I'm seeing on my network. I'm using 4 APs for wireless coverage. A AC86U for the main node and older AC68U for coverage across the house. All the AiMesh nodes are connected via ethernet for backhaul. The AC86U is then plugged into a 24 port unmanaged switch.

Main Node: RT-AC86U Current Version : 386.11
3 AiMesh Nodes RT-AC68U Current Version : 386.11

I have a linux server that is on 24x7. I have several wireless devices such as tasmota and a vacuum. The server can access these devices, and ping them no problem. However all other client devices (windows PC, mac laptop, iPads and iPhone) cannot access these wireless devices -- for a while? If I set up a ping, it will take 2-3 minutes, then it responds and I can pull up the web interface on the device. This issue has been driving me crazy, as it makes accessing my IoT wireless devices difficult and overly time consuming.

I see that 386.12_6 is out. Could this fix the problem, or am I better off reverting to 386.7_2 as mentioned earlier to see if that resolves the problem? Any help at all is appreciated as this is now a bigger issue as the robot vacuum can't be easily pulled up on ipads for a 'quick clean' :)
 
Sorry to resurrect an older thread, but wondering if this might be similar to the problem I'm seeing on my network. I'm using 4 APs for wireless coverage. A AC86U for the main node and older AC68U for coverage across the house. All the AiMesh nodes are connected via ethernet for backhaul. The AC86U is then plugged into a 24 port unmanaged switch.

Main Node: RT-AC86U Current Version : 386.11
3 AiMesh Nodes RT-AC68U Current Version : 386.11

I have a linux server that is on 24x7. I have several wireless devices such as tasmota and a vacuum. The server can access these devices, and ping them no problem. However all other client devices (windows PC, mac laptop, iPads and iPhone) cannot access these wireless devices -- for a while? If I set up a ping, it will take 2-3 minutes, then it responds and I can pull up the web interface on the device. This issue has been driving me crazy, as it makes accessing my IoT wireless devices difficult and overly time consuming.

I see that 386.12_6 is out. Could this fix the problem, or am I better off reverting to 386.7_2 as mentioned earlier to see if that resolves the problem? Any help at all is appreciated as this is now a bigger issue as the robot vacuum can't be easily pulled up on ipads for a 'quick clean' :)
Please provide a network diagram for all switches and Asus devices. Your VLAN mapping and include the VLAN configuration for all ports that your Asus devices connect to and if connected as a host port or trunk port.
 
Please provide a network diagram for all switches and Asus devices. Your VLAN mapping and include the VLAN configuration for all ports that your Asus devices connect to and if connected as a host port or trunk port.
I have a very simple network. No VLANs. the internet is plugged into the RT-AC86U WAN port. An old Linksys SR2024 is plugged into port 1. The server and most other wired devices are also plugged into that 24 port unmanaged switch. My PC is plugged into the RT-AC86U port 2. Wireless devices are not immediately found on the Win11 PC, or other wired devices such as raspberry PIs. My ubuntu 22.04 server can ping all the wireless devices immediately just fine.

Just wireless devices take a long time to reach. Anything wired, I can access on any device immediately.
 
I have a very simple network. No VLANs. the internet is plugged into the RT-AC86U WAN port. An old Linksys SR2024 is plugged into port 1. The server and most other wired devices are also plugged into that 24 port unmanaged switch. My PC is plugged into the RT-AC86U port 2. Wireless devices are not immediately found on the Win11 PC, or other wired devices such as raspberry PIs. My ubuntu 22.04 server can ping all the wireless devices immediately just fine.

Just wireless devices take a long time to reach. Anything wired, I can access on any device immediately.

Now you don't mention the mesh nodes. They are hard wired yet where do they do they connect and what is the full path between the router and each noce? What status does the router show for each node? show the ping of each node.
 
Sorry, I missed that. the 3 mesh nodes are plugged into the SR2024 switch (I do also use the ethernet ports on the mesh nodes for plugging in a few local devices such as an nVidia shield). So full path to each mesh node would be AC68U <-> SR2024 <-> AC86U.

On the AIMesh screen, the Connection Quality to all 3 nodes is 'Great'. One weird thing, on the Network tab, the 'Backhaul Information' and 'fronthaul information' just shows 0's for transmit and receive rates.

The ping results look good as well:

$ ping 192.168.0.114
PING 192.168.0.114 (192.168.0.114): 56 data bytes
64 bytes from 192.168.0.114: icmp_seq=0 ttl=64 time=4.925 ms
64 bytes from 192.168.0.114: icmp_seq=1 ttl=64 time=4.855 ms
64 bytes from 192.168.0.114: icmp_seq=2 ttl=64 time=3.079 ms
64 bytes from 192.168.0.114: icmp_seq=3 ttl=64 time=3.163 ms
--- 192.168.0.114 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.079/4.006/4.925/0.885 ms

$ ping 192.168.0.115
PING 192.168.0.115 (192.168.0.115): 56 data bytes
64 bytes from 192.168.0.115: icmp_seq=0 ttl=64 time=2.866 ms
64 bytes from 192.168.0.115: icmp_seq=1 ttl=64 time=2.895 ms
64 bytes from 192.168.0.115: icmp_seq=2 ttl=64 time=4.034 ms
64 bytes from 192.168.0.115: icmp_seq=3 ttl=64 time=4.871 ms
64 bytes from 192.168.0.115: icmp_seq=4 ttl=64 time=3.655 ms
--- 192.168.0.115 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.866/3.664/4.871/0.751 ms

$ ping 192.168.0.116
PING 192.168.0.116 (192.168.0.116): 56 data bytes
64 bytes from 192.168.0.116: icmp_seq=0 ttl=64 time=3.517 ms
64 bytes from 192.168.0.116: icmp_seq=1 ttl=64 time=7.469 ms
64 bytes from 192.168.0.116: icmp_seq=2 ttl=64 time=3.421 ms
64 bytes from 192.168.0.116: icmp_seq=3 ttl=64 time=4.242 ms
64 bytes from 192.168.0.116: icmp_seq=4 ttl=64 time=2.829 ms
--- 192.168.0.116 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.829/4.296/7.469/1.649 ms
 
Sorry, I missed that. the 3 mesh nodes are plugged into the SR2024 switch (I do also use the ethernet ports on the mesh nodes for plugging in a few local devices such as an nVidia shield). So full path to each mesh node would be AC68U <-> SR2024 <-> AC86U.

On the AIMesh screen, the Connection Quality to all 3 nodes is 'Great'. One weird thing, on the Network tab, the 'Backhaul Information' and 'fronthaul information' just shows 0's for transmit and receive rates.

The ping results look good as well:

$ ping 192.168.0.114
PING 192.168.0.114 (192.168.0.114): 56 data bytes
64 bytes from 192.168.0.114: icmp_seq=0 ttl=64 time=4.925 ms
64 bytes from 192.168.0.114: icmp_seq=1 ttl=64 time=4.855 ms
64 bytes from 192.168.0.114: icmp_seq=2 ttl=64 time=3.079 ms
64 bytes from 192.168.0.114: icmp_seq=3 ttl=64 time=3.163 ms
--- 192.168.0.114 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.079/4.006/4.925/0.885 ms

$ ping 192.168.0.115
PING 192.168.0.115 (192.168.0.115): 56 data bytes
64 bytes from 192.168.0.115: icmp_seq=0 ttl=64 time=2.866 ms
64 bytes from 192.168.0.115: icmp_seq=1 ttl=64 time=2.895 ms
64 bytes from 192.168.0.115: icmp_seq=2 ttl=64 time=4.034 ms
64 bytes from 192.168.0.115: icmp_seq=3 ttl=64 time=4.871 ms
64 bytes from 192.168.0.115: icmp_seq=4 ttl=64 time=3.655 ms
--- 192.168.0.115 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.866/3.664/4.871/0.751 ms

$ ping 192.168.0.116
PING 192.168.0.116 (192.168.0.116): 56 data bytes
64 bytes from 192.168.0.116: icmp_seq=0 ttl=64 time=3.517 ms
64 bytes from 192.168.0.116: icmp_seq=1 ttl=64 time=7.469 ms
64 bytes from 192.168.0.116: icmp_seq=2 ttl=64 time=3.421 ms
64 bytes from 192.168.0.116: icmp_seq=3 ttl=64 time=4.242 ms
64 bytes from 192.168.0.116: icmp_seq=4 ttl=64 time=2.829 ms
--- 192.168.0.116 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.829/4.296/7.469/1.649 ms

Try moving all your nodes from the switch to the router. The retest and look at all status.
 
OK, I have 2 open ports on the router, so I'll disconnect all 3 mesh devices and plug 2 back directly into the router. The devices that are slow to respond, interestingly it's just inbound. if I go to the linux server and open up a web page on the tasmota device, I can operate it fine and it can connect to the internet. I have to ping the wireless tasmota device for 1-3 minutes from the windows PC/mac laptop (or reload the web page several times from an ipad) before it responds.

Looking at the clients page, another interesting item. One of the devices that I'm trying to connect to (192..168.0.20) doesn't show up in the client list. When I ping it, once it responds I can access it's web page:

$ ping 192.168.0.20
PING 192.168.0.20 (192.168.0.20): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
ping: sendto: Host is down
Request timeout for icmp_seq 7
ping: sendto: Host is down
Request timeout for icmp_seq 8
ping: sendto: Host is down
Request timeout for icmp_seq 9
ping: sendto: Host is down
Request timeout for icmp_seq 10
ping: sendto: Host is down
Request timeout for icmp_seq 11
ping: sendto: Host is down
Request timeout for icmp_seq 12
ping: sendto: Host is down
Request timeout for icmp_seq 13
ping: sendto: Host is down
Request timeout for icmp_seq 14
ping: sendto: Host is down
Request timeout for icmp_seq 15
ping: sendto: Host is down
Request timeout for icmp_seq 16
ping: sendto: Host is down
Request timeout for icmp_seq 17
ping: sendto: Host is down
Request timeout for icmp_seq 18
ping: sendto: Host is down
Request timeout for icmp_seq 19
ping: sendto: Host is down
Request timeout for icmp_seq 20
ping: sendto: Host is down
Request timeout for icmp_seq 21
ping: sendto: Host is down
Request timeout for icmp_seq 22
ping: sendto: Host is down
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
Request timeout for icmp_seq 28
ping: sendto: No route to host
Request timeout for icmp_seq 29
ping: sendto: Host is down
Request timeout for icmp_seq 30
ping: sendto: Host is down
Request timeout for icmp_seq 31
ping: sendto: Host is down
Request timeout for icmp_seq 32
ping: sendto: Host is down
Request timeout for icmp_seq 33
ping: sendto: Host is down
Request timeout for icmp_seq 34
ping: sendto: Host is down
Request timeout for icmp_seq 35
ping: sendto: Host is down
Request timeout for icmp_seq 36
ping: sendto: Host is down
Request timeout for icmp_seq 37
ping: sendto: Host is down
Request timeout for icmp_seq 38
ping: sendto: Host is down
Request timeout for icmp_seq 39
ping: sendto: Host is down
Request timeout for icmp_seq 40
ping: sendto: Host is down
Request timeout for icmp_seq 41
ping: sendto: Host is down
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
64 bytes from 192.168.0.20: icmp_seq=44 ttl=64 time=67.572 ms
64 bytes from 192.168.0.20: icmp_seq=45 ttl=64 time=2.895 ms
64 bytes from 192.168.0.20: icmp_seq=46 ttl=64 time=2.863 ms
 
OK, I have 2 open ports on the router, so I'll disconnect all 3 mesh devices and plug 2 back directly into the router. The devices that are slow to respond, interestingly it's just inbound. if I go to the linux server and open up a web page on the tasmota device, I can operate it fine and it can connect to the internet. I have to ping the wireless tasmota device for 1-3 minutes from the windows PC/mac laptop (or reload the web page several times from an ipad) before it responds.

Looking at the clients page, another interesting item. One of the devices that I'm trying to connect to (192..168.0.20) doesn't show up in the client list. When I ping it, once it responds I can access it's web page:

$ ping 192.168.0.20
PING 192.168.0.20 (192.168.0.20): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
ping: sendto: Host is down
Request timeout for icmp_seq 7
ping: sendto: Host is down
Request timeout for icmp_seq 8
ping: sendto: Host is down
Request timeout for icmp_seq 9
ping: sendto: Host is down
Request timeout for icmp_seq 10
ping: sendto: Host is down
Request timeout for icmp_seq 11
ping: sendto: Host is down
Request timeout for icmp_seq 12
ping: sendto: Host is down
Request timeout for icmp_seq 13
ping: sendto: Host is down
Request timeout for icmp_seq 14
ping: sendto: Host is down
Request timeout for icmp_seq 15
ping: sendto: Host is down
Request timeout for icmp_seq 16
ping: sendto: Host is down
Request timeout for icmp_seq 17
ping: sendto: Host is down
Request timeout for icmp_seq 18
ping: sendto: Host is down
Request timeout for icmp_seq 19
ping: sendto: Host is down
Request timeout for icmp_seq 20
ping: sendto: Host is down
Request timeout for icmp_seq 21
ping: sendto: Host is down
Request timeout for icmp_seq 22
ping: sendto: Host is down
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
Request timeout for icmp_seq 28
ping: sendto: No route to host
Request timeout for icmp_seq 29
ping: sendto: Host is down
Request timeout for icmp_seq 30
ping: sendto: Host is down
Request timeout for icmp_seq 31
ping: sendto: Host is down
Request timeout for icmp_seq 32
ping: sendto: Host is down
Request timeout for icmp_seq 33
ping: sendto: Host is down
Request timeout for icmp_seq 34
ping: sendto: Host is down
Request timeout for icmp_seq 35
ping: sendto: Host is down
Request timeout for icmp_seq 36
ping: sendto: Host is down
Request timeout for icmp_seq 37
ping: sendto: Host is down
Request timeout for icmp_seq 38
ping: sendto: Host is down
Request timeout for icmp_seq 39
ping: sendto: Host is down
Request timeout for icmp_seq 40
ping: sendto: Host is down
Request timeout for icmp_seq 41
ping: sendto: Host is down
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
64 bytes from 192.168.0.20: icmp_seq=44 ttl=64 time=67.572 ms
64 bytes from 192.168.0.20: icmp_seq=45 ttl=64 time=2.895 ms
64 bytes from 192.168.0.20: icmp_seq=46 ttl=64 time=2.863 ms

Please move all 3 nodes to the router. Even if you have to move a host from the router to the switch. We need know that the nodes all talk to the router and work properly or possibly not. If you have a laptop, wiring it to each node and pinging the router would be very helpful. If all of that passes, then pings from anywhere on your asus network across the switch will be very telling.
 
Can do. Will be a little later this afternoon, and I'll also ping the router and server from my laptop from all 3 mesh nodes.
 
OK, I plugged each of the AC68U mesh nodes directly into the AC86U router. I then used my laptop with wireless and then wired to ping the router. The results:

#### AI Mesh Node 1 ###
wireless near 192.168.0.114
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.908 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.659 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=1.273 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1.594 ms
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.908/1.359/1.659/0.298 ms

wired into 114
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.296 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.298 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.284 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.429 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.347 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.413 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=0.284 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=0.363 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=0.325 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=0.329 ms
--- 192.168.0.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.284/0.337/0.429/0.049 ms

#### AI Mesh Node 2 ###
wireless from 192.168.0.77 (was 192.168.0.116 but the IP address changed after the cable move)
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=1.954 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.228 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.921 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=5.440 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=1.579 ms
--- 192.168.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.921/2.224/5.440/1.644 ms

wired from 192.168.0.77
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.450 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.410 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.386 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.418 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.549 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.492 ms
--- 192.168.0.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.386/0.451/0.549/0.055 ms

#### AI Mesh Node 3 ###
wireless from 192.168.0.115
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=1.035 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.135 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=1.593 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1.677 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=1.718 ms
--- 192.168.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.035/1.432/1.718/0.288 ms

wired from 192.168.0.115
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.350 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.266 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.331 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.343 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.297 ms
--- 192.168.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.266/0.317/0.350/0.031 ms

#####
After all of this, I wanted to see if the problem of accessing devices went away, and alas it did not. from my wireless laptop, I tried pinging 192.168.0.20:

PING 192.168.0.20 (192.168.0.20): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down

[.... snip ...]

Request timeout for icmp_seq 194
ping: sendto: Host is down
Request timeout for icmp_seq 195
Request timeout for icmp_seq 196
64 bytes from 192.168.0.20: icmp_seq=197 ttl=64 time=4.636 ms
64 bytes from 192.168.0.20: icmp_seq=198 ttl=64 time=13.951 ms
64 bytes from 192.168.0.20: icmp_seq=199 ttl=64 time=13.914 ms
64 bytes from 192.168.0.20: icmp_seq=200 ttl=64 time=3.731 ms
64 bytes from 192.168.0.20: icmp_seq=201 ttl=64 time=10.153 ms
--- 192.168.0.20 ping statistics ---
212 packets transmitted, 15 packets received, 92.9% packet loss
round-trip min/avg/max/stddev = 2.169/13.948/72.654/18.146 ms


At about icmp_seq 95 I logged into my linux server to ping the same device, and no problem.

# ping 192.168.0.20
PING 192.168.0.20 (192.168.0.20) 56(84) bytes of data.
64 bytes from 192.168.0.20: icmp_seq=1 ttl=64 time=7.24 ms
64 bytes from 192.168.0.20: icmp_seq=2 ttl=64 time=1.63 ms
64 bytes from 192.168.0.20: icmp_seq=3 ttl=64 time=37.5 ms
64 bytes from 192.168.0.20: icmp_seq=4 ttl=64 time=1.46 ms
64 bytes from 192.168.0.20: icmp_seq=5 ttl=64 time=17.1 ms
64 bytes from 192.168.0.20: icmp_seq=6 ttl=64 time=1.45 ms
64 bytes from 192.168.0.20: icmp_seq=7 ttl=64 time=1.43 ms
--- 192.168.0.20 ping statistics ---
8 packets transmitted, 7 received, 12% packet loss, time 7004ms
rtt min/avg/max/mdev = 1.432/9.713/37.591/12.588 ms
 
The devices I'm trying to access are using 2.4ghz. My laptop is using 5Ghz.

And just in case any of these settings help, here is my Wireless Professional tab settings:

Band 2.4ghz
Enable Radio Yes
Enable wireless scheduler No
Set AP Isolated No
Roaming assistant Enable Disconnect clients with RSSI lower than : -55 dBm
Bluetooth Coexistence Disable
Enable IGMP Snooping Disable
Multicast Rate(Mbps) Auto
Preamble Type Long
AMPDU RTS Enable
RTS Threshold 2347
DTIM Interval 3
Beacon Interval 100
Enable TX Bursting Enable
Enable WMM Enable
Enable WMM No-Acknowledgement Disable
Enable WMM APSD Enabble
Optimize AMPDU aggregation Disable
Modulation Scheme Up to MCS 11
Airtime Fairness Enable
Multi-User MIMO Enable
Explicit Beamforming Enable
Universal Beamforming Enable
Tx power adjustment Performance
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top