Wired Ai Mesh node keeps going offline

[droidkid]

Hi guys,

Quick question I recently moved into my new home and purchased 2 Asus AC3100's I have the main one in my office with a wired backhaul to the node in the family room. However, this Node is wired via an unmanaged switch and I'm wondering if that is my problem.
FYI All the network drops run to a central point in the basement.

Every few days the Family room (node 1) goes offline and will not come back until I reboot it. below is a diagram of my setup. I am thinking it might be the 8 port unmanaged switch? Not sure if I should just connect the Main router directly to Node 1 (using a coupler because I only have 2 network drops running from the office to the basement) and then run another ethernet from Node 1 to the 8 port switch? See Diagram 2 for an example.

 

[OzarkEdge]

Hi guys,

Quick question I recently moved into my new home and purchased 2 Asus AC3100's I have the main one in my office with a wired backhaul to the node in the family room. However, this Node is wired via an unmanaged switch and I'm wondering if that is my problem.
FYI All the network drops run to a central point in the basement.

Every few days the Family room (node 1) goes offline and will not come back until I reboot it. below is a diagram of my setup. I am thinking it might be the 8 port unmanaged switch? Not sure if I should just connect the Main router directly to Node 1 (using a coupler because I only have 2 network drops running from the office to the basement) and then run another ethernet from Node 1 to the 8 port switch? See Diagram 2 for an example.

Given suspect new cabling and switch, swap things in and out to discover a culprit.

Set the node connection priority to wired/Ethernet. Some switches defeat AiMesh Auto sensing of backhaul type.

Use a known good patch cable to test the remote node direct and through the switch.

If you use an Ethernet coupler, make sure it is rated for Gigabit Ethernet.

It might be worth buying an Ethernet cable tester to check all of the new cabling no matter this issue.

Be sure your router config started with a factory default reset.

OE

 

[droidkid]

Given suspect new cabling and switch, swap things in and out to discover a culprit.

Set the node connection priority to wired/Ethernet. Some switches defeat AiMesh Auto sensing of backhaul type.

Use a known good patch cable to test the remote node direct and through the switch.

If you use an Ethernet coupler, make sure it is rated for Gigabit Ethernet.

It might be worth buying an Ethernet cable tester to check all of the new cabling no matter this issue.

Be sure your router config started with a factory default reset.

OE

Thanks

So far today I set the Node to Ethernet and put 2 brand new patch cables in. I kept the Switch in and I'll monitor to see if the Node goes offline again. If it dose my next option is remove the switch and go direct.

Also seeing a ton of the following in my logs...

Oct 6 15:59:46 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc 9A:A7:7F:3B:9B:F9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Oct 6 15:59:46 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc 9A:A7:7F:3B:9B:F9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

Last night I see a bunch as soon as the Node went offline. I was searching the forms and a lot of people say to change the log level to from 6 to 5 is this recommended?

 

[OzarkEdge]

Thanks

So far today I set the Node to Ethernet and put 2 brand new patch cables in. I kept the Switch in and I'll monitor to see if the Node goes offline again. If it dose my next option is remove the switch and go direct.

Also seeing a ton of the following in my logs...

Oct 6 15:59:46 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc 9A:A7:7F:3B:9B:F9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Oct 6 15:59:46 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc 9A:A7:7F:3B:9B:F9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

Last night I see a bunch as soon as the Node went offline. I was searching the forms and a lot of people say to change the log level to from 6 to 5 is this recommended?

I'd leave the default log level unless you are looking for more entries.

I believe those log entries are a wireless client roaming node-to-node, perhaps band-to-band. You'll have to investigate why... evaluate signal overlap. Disabling Smart Connect and setting different SSIDs per band and connecting the client to the desired SSID/band can cut down on connection disruptions. Setting fixed, non-DFS channels instead of Auto channels can also cut down on connection disuptions.

OE

 

[droidkid]

I'd leave the default log level unless you are looking for more entries.

I believe those log entries are a wireless client roaming node-to-node, perhaps band-to-band. You'll have to investigate why... evaluate signal overlap. Disabling Smart Connect and setting different SSIDs per band and connecting the client to the desired SSID/band can cut down on connection disruptions. Setting fixed, non-DFS channels instead of Auto channels can also cut down on connection disuptions.

OE

So this weekend I tested all the cables in the new house and they all passed.
made sure the node is set to force wired backhaul.
Today I noticed the node is offline again (finally it has been good since last week). I do not want to reboot it since it takes so long for the issue to happen again.

Here is a snippet of when I believe something went wrong

Oct 13 02:54:30 WATCHDOG: [FAUPGRADE][auto_firmware_check:(6502)]retrieve firmware information
Oct 13 02:54:30 WATCHDOG: [FAUPGRADE][auto_firmware_check:(6517)]no need to upgrade firmware
Oct 13 04:01:13 WAN Connection: ISP's DHCP did not function properly.
Oct 13 04:01:13 DualWAN: skip single wan wan_led_control - WANRED off
Oct 13 04:01:13 nat: apply redirect rules
Oct 13 04:01:18 WAN Connection: Ethernet link down.
Oct 13 04:02:14 WAN Connection: Ethernet link up.
Oct 13 04:02:14 rc_service: wanduck 353:notify_rc restart_wan_if 0
Oct 13 04:02:19 WAN Connection: ISP's DHCP did not function properly.
Oct 13 04:02:23 WAN Connection: Ethernet link up.
Oct 13 04:02:23 rc_service: wanduck 353:notify_rc restart_wan_if 0
Oct 13 04:02:56 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 13 04:02:57 wan: finish adding multi routes
Oct 13 04:02:57 miniupnpd[649]: shutting down MiniUPnPd
Oct 13 04:02:57 miniupnpd[2504]: version 1.9 started
Oct 13 04:02:57 miniupnpd[2504]: HTTP listening on port 60367
Oct 13 04:02:57 miniupnpd[2504]: Listening for NAT-PMP/PCP traffic on port 5351
Oct 13 04:02:58 WAN Connection: WAN was restored.
Oct 13 04:03:14 BWDPI: fun bitmap = 3
Oct 13 04:03:15 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 13 04:03:15 dhcp client: bound 99.253.242.52/255.255.254.0 via 99.253.242.1 for 144930 seconds.

Full logs can be found here
Link to Logs

 

[Pergola Fabio]

Did you ever figured out what the issue was? I have same issues, they are going offline, when Ethernet still works, they are reachable... But wifi is complete gone on the node...

All is fine after a soft reset