Disabling "Access Intranet" on RT-AX86U guest network causes IoT devices on primary network to repeatedly disconnect

[mmseng]

Hi, I'm having an issue where some cheap Zengge (Magic Home) LED controllers are repeatedly losing connection to my primary wireless network whenever I disable "Access Intranet" on my guest network.

Previously I kept all IoT devices on my guest wifi network and disabled the bridging, as a standard isolation technique. This worked fine for years, including for these particular LED controllers. Recently I moved everything (including these controllers) to my primary LAN wireless network because I set up a Home Assistant server on the LAN. I'm not a huge fan of losing the isolation, but I'm coping with it for now, at least until I make a decision about whether to keep the HA server. While doing this I fully disabled my guest network to make things simpler. Everything worked as expected.

Afterward I turned my guest network back on and this causes these controllers to frequently lose their wifi connection. All 6 of them act exactly the same way. They usually stay connected for anywhere from 1 to 8 minutes, occasionally making it as long as 12 minutes, but rarely any longer.

It took me forever just to figure out that it was the guest network causing this. I tried tweaking dozens of settings in both the general wireless settings, professional settings, and guest network settings to no effect. Finally I figured out that enabling "Access Intranet" on the guest network solved the problem. But obviously I don't want to do this.

No other devices have this issue, so I recognize it could very well be a flaw with the specific LED controllers, however it doesn't make sense to me that the mere existence of a completely separate and unused network/SSID would cause this, and then only when unbridged. This is especially weird, because these devices existed on that unbridged guest network, coexisting with my primary wifi network for a long time, and only have issues when they are swapped to the primary wifi network. All of that being said, I'm vaguely aware that the primary and first guest wifi networks are somehow linked via the Asuswrt implementation, and also that the secondary and tertiary guest networks apparently work differently somehow. FWIW I have never tried using those additional guest networks.

I even went as far as packet capturing the communications from the LED controllers, in an attempt to see just WTF they are doing during these reset events. I got pretty close, but I think my available hardware and/or skills are not sufficient for making Wireshark decrypt their packets. (I can't manage to capture all 4 of the necessary EAPOL packets).

Can anyone think of a reason why a device connected to the main wifi network would work fine without the guest network on, fine with the guest network on and bridged, but NOT fine when the guest network is on and NOT bridged? Does the "connection reset every 1-10 minute" pattern ring any bells? I'm out of ideas and I've hit the limits of my knowledge and skills.

Thanks in advance for any insights or suggestions.

P.S. I googled extensively and this is perhaps the closest thread I've found with a similar sounding issue. Most of the suggestions there weren't helpful, although I admit I have not tried anything relating to IPv6 settings.

My environment:

• RT-AX86U running Asuswrt-Merlin 3004.388.4
• I normally have both the 2.4 and 5GHz radios on both the primary and guest network enabled (with sync'd settings), but I've tried all combinations of enabled radios, and used various wireless MAC filtering on the 4 SSIDs to force different combinations. The problematic devices only ever connect to 2.4GHz regardless, even though I think they technically support 5GHz (not sure on that).
• DHCP provided by the router. DNS provided by Pihole on the primary network.
• Single-family home with little to no external network interference, and literally all network devices are accounted for and have dedicated IP reservations on the LAN. There's usually a maximum of 20 devices that are connected at any one time.

 

[drinkingbird]

Hi, I'm having an issue where some cheap Zengge (Magic Home) LED controllers are repeatedly losing connection to my primary wireless network whenever I disable "Access Intranet" on my guest network.

Previously I kept all IoT devices on my guest wifi network and disabled the bridging, as a standard isolation technique. This worked fine for years, including for these particular LED controllers. Recently I moved everything (including these controllers) to my primary LAN wireless network because I set up a Home Assistant server on the LAN. I'm not a huge fan of losing the isolation, but I'm coping with it for now, at least until I make a decision about whether to keep the HA server. While doing this I fully disabled my guest network to make things simpler. Everything worked as expected.

Afterward I turned my guest network back on and this causes these controllers to frequently lose their wifi connection. All 6 of them act exactly the same way. The usually stay connected for anywhere from 1 to 8 minutes, occasionally making it as long as 12 minutes, but rarely any longer.

It took me forever just to figure out that it was the guest network causing this. I tried tweaking dozens of settings in both the general wireless settings, professional settings, and guest network settings to no effect. Finally I figured out that enabling "Access Intranet" on the guest network solved the problem. But obviously I don't want to do this.

No other devices have this issue, so I recognize it could very well be a flaw with the specific LED controllers, however it doesn't make sense to me that the mere existence of a completely separate and unused network/SSID would cause this, and then only when unbridged. This is especially weird, because these devices existed on that unbridged guest network, coexisting with my primary wifi network for a long time, and only have issues when they are swapped to the primary wifi network. All of that being said, I'm vaguely aware that the primary and first guest wifi networks are somehow linked via the Asuswrt implementation, and also that the secondary and tertiary guest networks apparently work differently somehow. FWIW I have never tried using those additional guest networks.

I even went as far as packet capturing the communications from the LED controllers, in an attempt to see just WTF they are doing during these reset events. I got pretty close, but I think my available hardware and/or skills are not sufficient for making Wireshark decrypt their packets. (I can't manage to capture all 4 of the necessary EAPOL packets).

Can anyone think of a reason why a device connected to the main wifi network would work fine without the guest network on, fine with the guest network on and bridged, but NOT fine when the guest network is on and NOT bridged? Does the "connection reset every 1-10 minute" pattern ring any bells? I'm out of ideas and I've hit the limits of my knowledge and skills.

Thanks in advance for any insights or suggestions.

P.S. I googled extensively and this is perhaps the closest thread I've found with a similar sounding issue. Most of the suggestions there weren't helpful, although I admit I have not tried anything relating to IPv6 settings.

My environment:

• RT-AX86U running Asuswrt-Merlin 3004.388.4
• I normally have both the 2.4 and 5GHz radios on both the primary and guest network enabled (with sync'd settings), but I've tried all combinations of enabled radios, and used various wireless MAC filtering on the 4 SSIDs to force different combinations. The problematic devices only ever connect to 2.4GHz regardless, even though I think they technically support 5GHz (not sure on that).
• DHCP provided by the router. DNS provided by Pihole on the primary network.
• Single-family home with little to no external network interference, and literally all network devices are accounted for and have dedicated IP reservations on the LAN. There's usually a maximum of 20 devices that are connected at any one time.

My first thought is those devices still remember the guest SSID and are swapping over to it (or attempting to). Are you using a totally new SSID for guest?

 

[mmseng]

My first thought is those devices still remember the guest SSID and are swapping over to it (or attempting to). Are you using a totally new SSID for guest?

I had briefly considered that perhaps they still had some sort of lingering settings related to the guest network, but I kind of dismissed it since the devices work fine on the primary network, plus in the course of troubleshooting I've "reset" them all several times, which for these devices means power cycling them 3 or 4 times in a row and re-pairing with their app. They don't have any interface by which I can see what network settings they're using, whether they might have additional network settings saved, or any mechanism by which network settings could be cleared, outside of doing the aforementioned "reset" procedure.

It also doesn't really make sense to me that the bridging mode of the guest network would have an effect on this.

But no, changing the guest network's SSID is not something I've tried yet, so I'll give it a shot. Thanks for the reply.

 

[bennor]

They don't have any interface by which I can see what network settings they're using, whether they might have additional network settings saved, or any mechanism by which network settings could be cleared, outside of doing the aforementioned "reset" procedure.

Check the IoT device's app to see if it is possibly saving the WiFi SSID and password info. Its possible the IoT online service (or local hub if it uses one) is saving the previous WiFi login information online. For example; Amazon's Echo devices does or did this, WiFi login information is/was saved to one's online Amazon account and one had to delete that online information else the device would attempt to connect to other WiFi networks first.

 

[mmseng]

Thanks. Unfortunately if that were actually the case then there's no way to fix it, and the stale wifi information is trapped in the device forever. As noted above, there is nowhere in the app that exposes this, factory resetting the device per the official instructions doesn't change the issue, and the company doesn't even have a website (outside of a few static knowledgebase pages); all account functionally is handled through the app.

 

[drinkingbird]

Thanks. Unfortunately if that were actually the case then there's no way to fix it, and the stale wifi information is trapped in the device forever. As noted above, there is nowhere in the app that exposes this, factory resetting the device per the official instructions doesn't change the issue, and the company doesn't even have a website (outside of a few static knowledgebase pages); all account functionally is handled through the app.

Try using a different SSID on the guest and see if it fixes it, then you at least know if that is part of the issue or not.

If they are on the guest and you enable guest isolation that would certainly explain why they stop working.

You can also look in the router status page to see which SSID they're connected to.

 

[mmseng]

Try using a different SSID on the guest and see if it fixes it, then you at least know if that is part of the issue or not.

If they are on the guest and you enable guest isolation that would certainly explain why they stop working.

You can also look in the router status page to see which SSID they're connected to.

I should mention is that I've primarily been monitoring the issue by watching the client list modal on the main "Network Map" page, using the "Interface" grouping. This list updates roughly every 3 seconds, and the devices never leave the primary SSID's 2.4GHz group. I also just checked the "System Log -> Wireless Log" page and I see the same behavior.

If they are attempting to connect to the guest SSID and failing then this might make sense. However the other thing I should have mentioned is that the guest SSID and password have both remained unchanged. So in theory, even if they are trying to auto connect to the guest SSID, they really should be succeeding.

I probably also failed to mention that DNS is functioning on the isolated guest network. So if they were successfully connecting to the guest SSID, they should not be dropping due to a lack of DNS. DNS is being successfully passed from even the isolated guest network to the pihole on the primary network, which is proven by forcing my phone onto the isolated guest network (with cell connection disabled) and seeing its DNS queries show up in the pihole log, and the phone not having any internet issues. I'll be honest, it's been a while since I set up the pihole, so I've kind of forgotten how I accomplished this DNS configuration, to get the isolated guest net to use the internal DNS server, but it does work. I believe it was a combination of setting the router's DHCP DNS server to the pihole, disabling the router from advertising itself as a DNS, and using DNS filtering ("DNS Director").

At any rate, all of that being said, I changed the guest SSID and it did not change the behavior of the devices.

Thanks, I appreciate your input.

 

[drinkingbird]

I should mention is that I've primarily been monitoring the issue by watching the client list modal on the main "Network Map" page, using the "Interface" grouping. This list updates roughly every 3 seconds, and the devices never leave the primary SSID's 2.4GHz group. I also just checked the "System Log -> Wireless Log" page and I see the same behavior.

If they are attempting to connect to the guest SSID and failing then this might make sense. However the other thing I should have mentioned is that the guest SSID and password have both remained unchanged. So in theory, even if they are trying to auto connect to the guest SSID, they really should be succeeding.

I probably also failed to mention that DNS is functioning on the isolated guest network. So if they were successfully connecting to the guest SSID, they should not be dropping due to a lack of DNS. DNS is being successfully passed from even the isolated guest network to the pihole on the primary network, which is proven by forcing my phone onto the isolated guest network (with cell connection disabled) and seeing its DNS queries show up in the pihole log, and the phone not having any internet issues. I'll be honest, it's been a while since I set up the pihole, so I've kind of forgotten how I accomplished this DNS configuration, to get the isolated guest net to use the internal DNS server, but it does work. I believe it was a combination of setting the router's DHCP DNS server to the pihole, disabling the router from advertising itself as a DNS, and using DNS filtering ("DNS Director").

At any rate, all of that being said, I changed the guest SSID and it did not change the behavior of the devices.

Thanks, I appreciate your input.

Perhaps your somewhat unknown DNS setup has some sort of loop in it requiring queries to go via the guest interface, and when you block that it fails. Or just the creation of the two VLANs and subnets that occurs when you disable intranet from guest is interfering, some config you don't remember is tied to that etc. Honestly at this point you might want to hard factory reset the router and start from scratch. Alternatively another test you can try is moving to guest 2 or 3 which will not create VLANs and subnets for guests when you disable intranet access (though it will still block traffic with firewall rules).

Basically there is no reason that guest config should impact your main LAN at all so it has to be something related to an addon, script, custom config, etc. Given your description above I'm leaning toward something related to your pihole setup.

 

[mmseng]

It certainly could be, though the DNS configuration has not changed since moving the devices from the guest net (where they were working) to the LAN. FWIW, while my configuration is perhaps unusual, I've not made any config changes to the router outside of the GUI, aside from SSHing in to try restarting various services during troubleshooting. Pretty much the only reason I moved from stock ASUS firmware to Merlin is for that "DNS Director" functionality, which allowed me to force devices to use the pihole. Hilariously when I first set this up, I neglected to give the pihole an exemption, so it was in fact looping its own upstream DNS queries back to itself. But that was pretty obvious since it broke my entire network, flooded the pihole logs, and raised my rpi's temps by like 10°C or more, IIRC.

I had been avoiding this as these devices are kind of annoying to reset and reconfigure with their app, but I will try moving them back to the guest net to see if they still work there. If not, then I would agree that something with the router config is screwing with them, even though other devices have no issues with it.

P.S. are you aware of any documentation that explains the different behaviors of the 3 guest nets? I've heard they operate differently (and you just confirmed it), but I'd like to understand how. I keep seeing "YazFi" mentioned everywhere, and it looks like this might provide a little more control over the different guest networks, and maybe some insight into that question. I have not tried installing/using it yet though.

 

[drinkingbird]

It certainly could be, though the DNS configuration has not changed since moving the devices from the guest net (where they were working) to the LAN. FWIW, while my configuration is perhaps unusual, I've not made any config changes to the router outside of the GUI, aside from SSHing in to try restarting various services during troubleshooting. Pretty much the only reason I moved from stock ASUS firmware to Merlin is for that "DNS Director" functionality, which allowed me to force devices to use the pihole. Hilariously when I first set this up, I neglected to give the pihole an exemption, so it was in fact looping its own upstream DNS queries back to itself. But that was pretty obvious since it broke my entire network, flooded the pihole logs, and raised my rpi's temps by like 10°C or more, IIRC.

I had been avoiding this as these devices are kind of annoying to reset and reconfigure with their app, but I will try moving them back to the guest net to see if they still work there. If not, then I would agree that something with the router config is screwing with them, even though other devices have no issues with it.

P.S. are you aware of any documentation that explains the different behaviors of the 3 guest nets? I've heard they operate differently (and you just confirmed it), but I'd like to understand how. I keep seeing "YazFi" mentioned everywhere, and it looks like this might provide a little more control over the different guest networks, and maybe some insight into that question. I have not tried installing/using it yet though.

I'm not aware of any documentation about the different behavior, at least not detailed. It may exist though. I think I've written some up about it but can't find a succinct single post.

The basics for stock Asus (does not apply to YazFi):

Couple things that are consistent:
All 3 operate exactly the same if you have Access Intranet ENabled. They are just additional SSIDs for your main LAN with no filtering or segmentation (so basically fairly pointless other than being able to use a password that you can give to guests and can change often without having to update your own devices).
All 3 block inter-client communication within the guest network (AP Isolation enabled) when you DISable intranet access.

Where it differs is only when you have access intranet DISabled

GW1 creates two or three VLANs (VLAN 501/192.168.101.0/24 for 2.4ghz Guest1, VLAN 502/192.168.102.0/24 for 5ghz guest1, and on tri-band routers VLAN 503/192.168.103.0/24 for 5ghz-2 guest1)
The main reason for this is to have the ability to propagate this guest wireless to AiMesh nodes and have the segmentation "survive" across all nodes, this requires VLANs to work, and you can't span a single subnet across multiple VLANs. However as a side effect, it does provide a bit more security by having two layers of firewall, and a bit more flexibility should you want to modify those firewall rules with a script.
It uses ebtables and iptables to block communication to and from the main LAN. Some stuff is just identical rules with 2 layers of protection, other stuff is more granular in one or the other. For example ebtables allows all UDP, but iptables then filters it to only DHCP and DNS to the guest router interface.
So in summary, GW1 becomes a routed interface when you disable intranet access, different subnet, VLAN, and has to pass through the routing module/firewall on the Asus to communicate with anything.

GW2/3 do not create any VLANs and share your main LAN subnet, even if you disable intranet access. They will not propagate to aimesh nodes. Ebtables is the main filtering to block communication to the main LAN. Iptables is just barely involved to permit the clients to do DHCP and DNS but not ping/telnet etc to the router interface, so iptables is basically just protecting the router itself from guests, not your main LAN, that relies almost completely on ebtables (along with some arp blocking and broadcast filtering that comes with AP isolation).
In summary, there is no routing here (beyond normal routing to the internet), just essentially a port on the switch with some filtering applied to it.

Like I said above, all 3 will block inter-client communication within the guest network using AP isolation when intranet access is disabled.

You can see more details on the EBTABLES/IPTABLES rule differences here https://www.snbforums.com/threads/d...-network-not-working.85988/page-2#post-854834

Worth noting that the subnets for guest wireless 1 (192.168.x.x) are hardcoded, you can't control them and can't reserve DHCP leases, at least not in 386 code, not certain on 388 but I don't believe there either. They have 2 through 254 set for DHCP leases so you can't even safely set a static IP in them.

Of course all of these behaviors can be overridden with scripts.

 

[mmseng]

Thank you for the writeup(s). Based on that I feel like guest nets 2/3 probably don't help my current situation, but it's definitely enlightening.

I'm pretty far out of my lane, but also based on your linked post, it seems like the reason DNS works across the isolation (which is something that's a little mysterious to me) may be because it is allowed through both ebtables and iptables, where other communications are not.

I did move one of the devices back to the isolated guest net and it works fine again, while the others on the LAN wifi are still resetting.

I don't fully understand some of the other stuff in your linked post but I saw you mention a discrepancy with ARP (at least on the guest 2/3 nets). I'm wondering if this has anything to do with it, since I specifically noted some strange ARP behavior from the devices when I was Wiresharking. I may be getting into the weeds here, but I just took another look and the problematic devices seem to be ARP probing for their own reserved IP at regular intervals, which I assume makes sense, since they are repeatedly reconnecting. What's even stranger is that the device I moved back to the guest net works fine, but the rpi is frequently spamming out ARP requests asking who has this device's old reserved ip on the LAN. I suppose it could just be because Pihole and/or Home Assistant (both running in containers on the rpi) technically know this device's MAC and LAN-reserved IP and are looking for it, since it's no longer on that IP.

At any rate, this all seems moot since the devices work fine on the LAN wifi when the guest net is disabled or not isolated, and I'm out of my league at this point regardless. I appreciate your input, but unless I can think of something else to try (that doesn't involve wiping the router), I'll probably just live without a guest net for now and deal with the LEDs not working whenever I inevitably turn it on for guests. I do finally have a 2nd rpi coming soon so I may considering moving Home Assistant over to the guest network and putting all of my IoT back on that net.

 

[drinkingbird]

it seems like the reason DNS works across the isolation (which is something that's a little mysterious to me) may be because it is allowed through both ebtables and iptables, where other communications are not.

Correct

I did move one of the devices back to the isolated guest net and it works fine again, while the others on the LAN wifi are still resetting.

I don't fully understand some of the other stuff in your linked post but I saw you mention a discrepancy with ARP (at least on the guest 2/3 nets). I'm wondering if this has anything to do with it, since I specifically noted some strange ARP behavior from the devices when I was Wiresharking. I may be getting into the weeds here, but I just took another look and the problematic devices seem to be ARP probing for their own reserved IP at regular intervals, which I assume makes sense, since they are repeatedly reconnecting. What's even stranger is that the device I moved back to the guest net works fine, but the rpi is frequently spamming out ARP requests asking who has this device's old reserved ip on the LAN. I suppose it could just be because Pihole and/or Home Assistant (both running in containers on the rpi) technically know this device's MAC and LAN-reserved IP and are looking for it, since it's no longer on that IP.

At any rate, this all seems moot since the devices work fine on the LAN wifi when the guest net is disabled or not isolated, and I'm out of my league at this point regardless. I appreciate your input, but unless I can think of something else to try (that doesn't involve wiping the router), I'll probably just live without a guest net for now and deal with the LEDs not working whenever I inevitably turn it on for guests. I do finally have a 2nd rpi coming soon so I may considering moving Home Assistant over to the guest network and putting all of my IoT back on that net.

ARP can be very odd to watch. It won't always make sense. If you fire up the Asus GUI and open client list, and then watch your sniffer you'll see the router ARP scanning the whole network every few minutes. Some devices do gratuitous ARPs (announcing their MAC when nobody has asked). Others will ARP an IP assigned to them by DHCP to make sure it isn't in use.

The odd behavior I was seeing was looking at the ARP table on devices themselves and seeing "incomplete" even though I had disabled AP isolation and there was no reason they should not have been able to ARP for the other device. This was confirmed in the sniffer by seeing it ask and getting no response. That is something that appears to be done somewhere in the driver or firmware for GW2 and 3, I didn't spend a lot of time troubleshooting it to really figure it out.

I honestly think what you're seeing is some sort of DNS loop or some configuration that is still tied to the guest network that you're not realizing. But if you don't want to go through a reset and reconfigure, and are ok with not having the guest, then you can run that way until you're ready to look into it more.

In normal operation there is absolutely nothing in the guest config (regardless of 1, 2, or 3) that should have any impact on the main LAN. The only possible thing I can think is if you have a device hardwired to the router and that device is VLAN aware, it will start seeing tagged frames coming out of that port once you enable GW1 with intranet disabled, but if you haven't configured the VLANs on it, it will just discard them so that should not be an issue either.

Home Assistant is another challenge as its discovery will typically rely on clients being on the same subnet and being able to reply (and in some cases even needing those clients to be able to initiate a connection).

Guest networks and IOTs are a bit of a problem. Sometimes it can be made to work, sometimes you need to do scripting, and other times it just isn't worth it.

At the very least I'd fire up maybe guest 2 or 3 with a tottally new SSID and password just to see what happens. If that has no negative impact, then turn that off and put that same new SSID/PW on GW1. That should at least tell you if it is simply enabling the guest that is a problem, or if it is a device that may be remembering a guest SSID.

 

[mmseng]

I would have guessed that if the issue was the devices remembering the guest net, then changing the guest SSID would have made a difference. But to be fair I wasn't particularly thorough in my testing after changing the SSID. When I get some more time I'll give it another shot and also try out the 2nd/3rd guest nets.

Thanks for the discourse.

 

[macster2075]

I have this issue as well. It doesn't matter which Guest Network I use, 1-3 or what type of SSID or password. If Intranet Access is disabled, it blocks Internet access altogether. As soon as I enable it, then Internet access comes back. I don't remember it being this way in the past.

 

[mmseng]

I don't have a resolution, but just thought I'd circle back and post a followup. I eventually got around to buying some Shelly RGBW2 units to replace these cheap ZENGGE controllers. At first I found that they had the same (or a similar) issue where they would only stay connected for a short while. However I eventually discovered that my router had a "roaming assistant" setting enabled which kicks devices with weak signals off (I guess). I disabled this and it immediately solved the issue for the Shelly device, even with the guest network (#1) enabled. However disabling "roaming assistant" did not solve the issue for the ZENGGEs. I even placed a Shelly much further from the router and with more stuff in between than the ZENGGEs and it still stayed connected just fine.

So my conclusion is that the ZENGGE devices either:

• have really poor radios
• have failing components
• have buggy firmware
• and/or have some other quirk or flaw which makes them incompatible with my current network configuration
• or, the Shellys are just more robust to whatever idiosyncrasy my networking configuration has

At any rate it looks like throwing money at Shelly was a viable solution.

 

[mmseng]

Ugh. So... my last post was a false start. After more troubleshooting it looks like the Shelly devices still have the same issue as the ZENGGE devices; that is they work more or less fine until I enable my guest network. It's just that changing pretty much any setting resets the AP, which causes the clients to reconnect, until they drop off again. The graph I posted implied that the Shelly device wasn't disconnecting while the ZENGGEs were, but in reality, it was just that Home Assistant (where the graph came from) apparently isn't able to track connectivity of the different devices in the same way, so the Shelly just appeared consistent, but wasn't actually. I'm still doing some extended testing, but now I have an automation that turns the Shellys on and off every 5 minutes, so I can see if and roughly when any device stops responding.

Additionally, after reading countless threads I've come to the conclusion that the wifi chip shared by these devices (ESP8266) is simply flawed (possibly along with some related chips to a lesser degree, such as ESP32 and ESP8285), or at least has some idiosyncrasies that simply aren't compatible with my wireless configuration.

There is literally no end to forum posts, github issues, SO threads, etc. complaining about ESP8266 devices randomly or regularly losing wifi connection. The vast majority of these posts are either abandoned or "solved" for very specific use cases by implementing various workarounds.

The underlying issue appears to be that this chip (and/or it's various firmware implementations) simply has esoteric quirks with its power-saving implementation, as well as it's ability to deal with noisy or weak wireless networks. It also appears to implement a forced reboot whenever it gets overwhelmed or overheated, likely contributing to the frequent reports of regular reboots/crashes/disconnects. Even when the chip is working as expected, it seems that it likes to fall asleep in lower power modes. This is particularly vexing because it confounds troubleshooting results. Constantly interfacing or even just pinging the devices seem to keep them awake, making them appear to be functioning perfectly, but as soon as they are left alone for a period of time, they may disconnect and never recover, because they are no longer online to receive any further interactions. They only seems to recover if A) they are power cycled or B) the AP is reset. It's like Schrodinger's cat and the chicken and egg problem combined. There are also reports that some firmware implementations erroneously transposed the "high" and "light" sleep modes, which really confused a lot of troubleshooters (one of a few sources: https://github.com/esphome/issues/issues/1532). On top of all that there seems to be a vague pattern of acknowledgement that Asus routers cause more problems with these chips than other brands, but no specifics or confirmations.

It's kind of incredible seeing how many of these threads there are with no single place fully acknowledging the obviously widespread issue, and the sheer amount of human hours wasted on troubleshooting this particular chip is staggering. The best sources have been various threads on the forums for Home Assistant, Arduino, and the ESPHome custom firmware project, but even they acknowledge that the issue is very low level and they have no idea how to fix it, only offering some of the common workarounds, which generally revolve around optimizing network traffic: https://esphome.io/guides/faq.html#my-node-keeps-reconnecting-randomly

Here is just a tiny sample of the relevant threads:

• https://community.home-assistant.io/t/esphome-devices-lose-their-connection/160062/90
• https://github.com/esphome/issues/issues/1237#issuecomment-633061461
• https://community.home-assistant.io/t/esp8266-weird-wifi-issues/50484/22
• https://community.home-assistant.io/t/cant-stop-esphome-restarting-with-weak-wifi/453821/23
• https://community.home-assistant.io/t/mqtt-dropping-on-esp8266/280775/2
• https://github.com/esphome/issues/issues/4138
• https://community.home-assistant.io...domly-when-wifi-connection-gets-poorer/429388
• https://community.home-assistant.io/t/esp8266-drops-wifi-connection/424855
• https://forums.mbed.com/t/esp8266-constantly-lose-connection-with-wifi-router/16187
• https://www.esp8266.com/viewtopic.php?p=87757

All of that being said I'm still not entirely sure how my this applies to my situation or what to do about it. For me it's very clear that things appear to work fine when my guest net #1 is disabled, and break after a short while when it's enabled (with intranet access disabled). Simply disabling the guest net is enough to cause the devices to recover their connection and stay responsive, however as mentioned earlier I'm pretty sure that's just due to the fact that the AP gets reset whenever any guest net is enabled or disabled.

At any rate I'm doing some further testing, and trying to be more patient and thorough, as in waiting a day between any changes, to make sure I'm not seeing misinterpreting any more results.

 

[glens]

Ugh. ...

Looked like a good post, but I confess I gave up after a while.

So the issues are with some Chicom chips? Why should they care anything beyond SSID/passphrase to reach a suitable network? Is suitability not being provided?

 

[mmseng]

So, your question is... Does my network exist and work?

Look, at this point I've mostly given up that anyone besides myself will be able or willing to help me (not least because I'm unwilling to tear my entire network down and rebuild it from scratch, or buy a second very expensive AX router just to test it as a 1-1 replacement, all just to accommodate some cheap led controllers). So I'm mostly just continuing to post here as a log for myself and possibly any future googlers who may find it useful.

I'll freely admit that I have no real idea what I'm talking about and am grasping at straws. I also recognize that blaming the design of a microcontroller when I have zero background in chip engineering reeks of misguidedness and immaturity, but in the absence of guidance I'm just calling things like I see them. I've couched it in a healthy acceptance that the problem is possibly just with my own network configuration. But it's impossible to ignore that I now have 12 similar devices from 2 disparate manufacturers which all exhibit this same wild behavior, when nothing else on my network has this issue.

 

[bennor]

Asus released a firmware update just over a week ago for the RT-AX86U Pro (see this link) that deals with disabling guest network intranet access. Hopefully they'll filter out that update to other models soon. May (or may not) help address certain issues being discussed.

ASUS RT-AX86U Pro Firmware version 3.0.0.4.388_24199
Version 3.0.0.4.388_24199 52.74 MB 2024/01/04
Bug Fixes and Enhancements：
- Resolved guest network connectivity issues on AiMesh nodes by disabling guest network internal access.

 

[mmseng]

Thanks for the heads up. I noticed the notification in my router interface recently and then promptly forgot to check it.