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

 

[penguin22]

Some "good" bad news. This morning, 2 days following the in-depth changes I highlighted above, a bunch of my Govee IoT devices dropped connection from my BE86U node. This was much longer than the issue would have shown before, though required a restart of that node, at which everything came back online.

Will continue to monitor over the next several days to see if this repeats. My thought remains unchanged where the router + nodes in current firmware releases have some form of bug in them primarily affecting IoT VLANs, whether wired or wireless, in specific configurations.

Unfortunately ASUS has been impossible to work with constantly requesting submission from the router using their Feedback form, which I don't have available on the BE88U running Merlin. Hopefully the feedback from customers and reviewing this forum (I hope they are), gives them enough information to hunt this down and resolve it without that captured information.

 

[jksmurf]

Some "good" bad news. This morning, 2 days following the in-depth changes I highlighted above, a bunch of my Govee IoT devices dropped connection from my BE86U node. This was much longer than the issue would have shown before, though required a restart of that node, at which everything came back online.

Ok… so still an issue. Quick question, do you have anywhere in your network a TP-Link Easy Smart switch eg TL-SG105E or similar?

Will continue to monitor over the next several days to see if this repeats.

Ok.

Unfortunately ASUS has been impossible to work with constantly requesting submission from the router using their Feedback form, which I don't have available on the BE88U running Merlin. Hopefully the feedback from customers and reviewing this forum (I hope they are), gives them enough information to hunt this down and resolve it without that captured information.

That is really unfortunate, one of the drawbacks of using alternative FW I guess, albeit the parts that are not working are ASUS closed source elements…

 

[penguin22]

Ok… so still an issue. Quick question, do you have anywhere in your network a TP-Link Easy Smart switch eg TL-SG105E or similar?

Ok.

That is really unfortunate, one of the drawbacks of usong alternative FW, I guess albeit the parts that are not working are ASUS closed source elements…

I have no other switches or hubs in the network, only ASUS routers. I do have an AX1800S acting as a media bridge for my son (wireless connected to the main BE88U router), which has several devices connecting wired to the MB.

The same Govee clients were again disconnected this morning on my BE86U, fixed with a reboot. It's still much better than it was before, with clients otherwise staying connected elsewhere and an uptime on the main BE88U router of 4 days (along with all other nodes besides the BE86U. I may just schedule a daily restart at this point until ASUS releases new firmware or a new Merlin comes out that I can test with.

 

[jksmurf]

I have no other switches or hubs in the network

Thanks for letting me know, just trying to rule out some things. Apparently the TP-Link Easy Smart switch has some quirks in its VLAN implementation and as far fetched as it may seem, I was wondering if that was leaking or otherwise affecting the Asus VLAN. So your confirmation that it’s confined to Asus is helpful.

I may just schedule a daily restart at this point until ASUS releases new firmware or a new Merlin comes out that I can test with.

Okey-dokey. I did try that on mine before I disabled the VLAN ACCESS mode to node ports but on reboot quite a few devices didn’t connect then when I eventually got them back via a sequence of node or main reboots, they started dropping off again.

Disabling VLAN access, not only did the devices all came back online very quickly after a system reboot, without a stutter, they have all stayed online as happy as Larry, since when you first suggested what the issue might be and I disabled it.

If it’s not easy smart switches I’m still baffled what makes @visortgw system work perfectly with VLAN Access or Trunk enabled, but ours does not. Maybe he’s just got different IoT devices that aren’t 10lb weaklings … or his devices are like limpets and never let go of their Wi-Fi … at this juncture it’s near-wild speculation with a sample size of the number of blueberries you get in your ice cream at a Michelin starred restaurant.

 

[visortgw]

Thanks for letting me know, just trying to rule out some things. Apparently the TP-Link Easy Smart switch has some quirks in its VLAN implementation and as far fetched as it may seem, I was wondering if that was leaking or otherwise affecting the Asus VLAN. So your confirmation that it’s confined to Asus is helpful.

Okey-dokey. I did try that on mine before I disabled the VLAN ACCESS mode to node ports but on reboot quite a few devices didn’t connect then when I eventually got them back via a sequence of node or main reboots, they started dropping off again.

Disabling VLAN access, not only did the devices all came back online very quickly after a system reboot, without a stutter, they have all stayed online as happy as Larry, since when you first suggested what the issue might be and I disabled it.

If it’s not easy smart switches I’m still baffled what makes @visortgw system work perfectly with VLAN Access or Trunk enabled, but ours does not. Maybe he’s just got different IoT devices that aren’t 10lb weaklings … or his devices are like limpets and never let go of their Wi-Fi … at this juncture it’s near-wild speculation with a sample size of the number of blueberries you get in your ice cream at a Michelin starred restaurant.

I definitely have some low-power battery devices that come and go (e.g., Honeywell water leak/temperature alarms), but they're supposed to do that (i.e., work as designed).

 

[Seth Harman]

Thanks for letting me know, just trying to rule out some things. Apparently the TP-Link Easy Smart switch has some quirks in its VLAN implementation and as far fetched as it may seem, I was wondering if that was leaking or otherwise affecting the Asus VLAN. So your confirmation that it’s confined to Asus is helpful.

What quirks? I've got two of the 8-port versions of those TP-Link switches operating on my network tagging traffic and I have none of the problems being talked about in this thread.

 

[visortgw]

What quirks? I've got two of the 8-port versions of those TP-Link switches operating on my network tagging traffic and I have none of the problems being talked about in this thread.

But you are not using the Asus VLAN configuration — only a guess based upon my experience (and @jksmurf's), but there may be a conflict between the two.

 

[jksmurf]

What quirks? I've got two of the 8-port versions of those TP-Link switches operating on my network tagging traffic and I have none of the problems being talked about in this thread.

See link below, it’s an old thread though, some discussion about fixed VLAN1 and leaking. I’m not in a position (ie nowhere near any useful level of knowledge) to comment on whether it’s an issue for us.

However the thing here is that you don’t have VLAN capable nodes IIRC so you don’t have both ASUS VLAN and TP-Link VLAN working simultaneously on the same network, which was a (possibly short lived) fledgling theory…

Escaping from TP-Link Easy Smart Switches - Business Community

Model : Hardware Version : Firmware Version : ISP : Last week I bought a TL-SG1016DE and TL-SG108E for bulding a small Lan with a few VLANs (Internal, External, DMZ) because price and reported features was good. First lweb ogin and I've immediately r

community.tp-link.com

 

[Seth Harman]

See link below, it’s an old thread though, some discussion about fixed VLAN1 and leaking. I’m not in a position (ie nowhere near any useful level of knowledge) to comment on whether it’s an issue for us.

However the thing here is that you don’t have VLAN capable nodes IIRC so you don’t have both ASUS VLAN and TP-Link VLAN working simultaneously on the same network, which was a (possibly short lived) fledgling theory…

Escaping from TP-Link Easy Smart Switches - Business Community

Model : Hardware Version : Firmware Version : ISP : Last week I bought a TL-SG1016DE and TL-SG108E for bulding a small Lan with a few VLANs (Internal, External, DMZ) because price and reported features was good. First lweb ogin and I've immediately r

community.tp-link.com

The link you posted above contains a few posts that say the leaking packet issue was solved with an upcoming firmware release (and these posts are from 2018 so we're probably not even talking about the same hardware versions you can buy now).

I'm certainly no VLAN expert but I do recall when this all started in our monolithic thread about GNP someone else tried using TP-Link managed switches and weren't having much luck, but when they posted their config screenshots it was setup differently than mine in a way that didn't make a lot of sense to me, and that can be an issue in and of itself because if those switches aren't setup exactly right everything can go haywire.