IoT Devices falling off nodes (only) always requires reboot to fix

[visortgw]

Ah ok thanks. I recall the cheap managed switches discussion.
So yeah, it will be difficult to isolate as the sample size of those with my specific setup, so far is… maybe 2 or 3 including me.

@visortgw has a working system, the difference his to mine appears to be primarily HW.

@jksmurf: Some more details on my configuration:

1. GT-BE98 Pro primary router with two (2) ports configured for 2.4 GHz IoT VLAN (Access Mode)
   • one 2.5 Gbps port connected to 8-port TP-Link unmanaged switch; and
   • one 1 Gbps port connected directly to Sony BRAVIA TV.
2. One 10 Gbps port of GT-BE98 Pro connected to 10 Gbps port of TP-Link 10 Gbps (2-port)/2.5 Gbps (8-port) managed switch.
3. Second 10 Gbps port of managed switch connected to 8-port 10 Gbps unmanaged switch which feeds GT-AXE16000 AiMesh node (and other devices)
   • four 1 Gbps ports configured for 2.4 and 5 GHz (two each) IoT VLANs (Access Mode) to two NASs
   • one 2.5 Gbps port configured for 2.4 IoT VLANs (Access Mode) to 8-port TP-Link unmanaged switch
4. One 2.5 Gbps port of managed switch configured for 2.4 GHz IoT VLAN to 8-port TP-Link unmanaged switch.
5. Two more unrestricted 2 .5 Gbps ports of managed switch connected to two (2) GT-AX6000 AiMesh nodes — individual ports are configured on each of these nodes as needed for individual devices to access 2.4 GHz IoT VLAN (Access Mode).
6. My 2.4 GHz IoT VLAN has Set AP Isolated disabled to allow eufy devices to reach the eufy HomeBase on the same VLAN.
7. IPv6 is not enabled in my network.
8. I have configured one-way access from my primary network (.222 subnet) to my IoT and guest networks (.52, .53, and .54 subnets with the following additions to /jffs/scripts/firewall-start:

iptables -I FORWARD -i br0 -s 192.168.222.0/24 -d 192.168.52.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.222.0/24 -d 192.168.53.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.222.0/24 -d 192.168.54.0/24 -j ACCEPT
service restart-firewall

Hope this helps!

 

[jksmurf]

Thank you @visortgw , appreciated again.

Mine is a wee bit simpler.

• Main VLAN 0, Guest on VLAN 62 and IoT on VLAN 63 (2.4GHz only)
• Set AP isolated on Guest VLAN 62 only.
• Access Intranet enabled on IoT VLAN 63 only.
• IPv6 (Native, 56) enabled on Main IPv6 menu but not on either of the individual Guest Networks.
• GT-AX6000 Main connected to two RT-AX86U Pro Nodes; plus one RT-AX58U Node, all wired BH, all 1G WAN first. All latest Merlin FW per sig.
• All 3 of GT-AX6000 and RT-AX86U Pro are GNP AND VLAN Capable.
• I (had, currently disabled as it was causing IoT instability) VLAN (Access Mode, IoT VLAN 63 Network ) on Ethernet Port 1 (LAN-1) on each of the two RT-AX86U Pro Nodes, That's it.
• Each of those LAN-1 ports had an ESP32 (Wavshare) Ethernet-based Bluetooth Proxy IoT Device for use with HA (Wifi capable if you configure it that way, which they are right now as I disabled VLAN access).
• 5Ghz Radio disabled (AiMesh menu) on the RT-AX58U as I only use it for IoT AND in any case that interface does not get propogated to that Node (AiMesh capable but not GNP capable nor VLAN capable). The RT-AX58U has a TP-Link TL-SG105E 'Easy Smart' Switch attached to it so the HA Server (on the Switch) plus some other wired HA devices all get IoT VLAN 63.
• Addons are Diversion, MerlinAU, YazDHCP, Tailmon, DC, FD, LED.

The points of difference (to your setup) do not seem that great; so is it just the RT-AX86U Pro GPL? Is it the errant RT-AX58U on the older FW codebase (but why would that stuff up the rest of the syste?) No idea. One thing I have not done (mea culpa) is reset the nodes (due to them being thousands of km away), so I am trying to get someone to go do that for me asap.

#!/bin/sh

if [ -x /opt/bin/tailscale ]; then tailscale down; tailscale up; fi # Added by TAILMON

# Added by KM to allow access to the Home Assistant Server from any client on the PRIMARY Network - WORKS
iptables -I FORWARD -i br0 -s 192.168.47.0/24 -d 192.168.63.18/32 -j ACCEPT

# Added by KM to allow Mii Xiaomi Smart Hub 2 access from PRIMARY network - WORKS
iptables -I FORWARD -i br0 -s 192.168.47.0/24 -d 192.168.63.20 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.47.0/24 -d 192.168.63.21 -j ACCEPT

# Added by KM to allow access to Chromecast and Samsung TV on Guest from any client on the PRIMARY Network
#
# For SamsungTV (192.168.62.238) # For GoogleTV (192.168.62.239) 
iptables -I FORWARD -i br0 -s 192.168.47.0/24 -d 192.168.62.238 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.47.0/24 -d 192.168.62.239 -j ACCEPT
#
# Reverse Direction
iptables -I FORWARD -i br52 -s 192.168.62.238 -d 192.168.47.0/24 -j ACCEPT
iptables -I FORWARD -i br52 -s 192.168.62.239 -d 192.168.47.0/24 -j ACCEPT

# For Guest to TV and vice-versa, all on Guest Network, due to Guest Isolation being enabled.
#
# For SamsungTV (192.168.62.238) # For GoogleTV (192.168.62.239)
iptables -I FORWARD -i br52 -s 192.168.62.0/24 -d 192.168.62.238 -j ACCEPT
iptables -I FORWARD -i br52 -s 192.168.62.238 -d 192.168.62.0/24 -j ACCEPT
#
# Reverse Direction
iptables -I FORWARD -i br52 -s 192.168.62.0/24 -d 192.168.62.239 -j ACCEPT
iptables -I FORWARD -i br52 -s 192.168.62.239 -d 192.168.62.0/24 -j ACCEPT

# Allow PRIMARY network to access entire IoT VLAN 63 - NOT NEEDED ATM
# iptables -I FORWARD -i br0 -s 192.168.47.0/24 -d 192.168.63.0/24 -j ACCEPT
# iptables -I FORWARD -i br53 -s 192.168.63.0/24 -d 192.168.47.0/24 -j ACCEPT

# Restart firewall-start with service restart_firewall
# Check interfaces with iptables -S | grep 192.168.47.0 OR iptables -S | grep 192.168.62.0 OR iptables -S | grep 192.168.63.0