Release ASUS RT-AX86 Series(RT-AX86U/RT-AX86S) Firmware version 3.0.0.4.388.22525

[Tech9]

Actually, the fact you have to move something to Guest Network so it starts working properly indicates issues with AX86U. This is not a "fix", but sort of "accidental workaround". Enjoy the advanced Guest Network until Asus "fixes it" with firmware update and your IoTs stop working again.

 

[iFrogMac]

Actually, the fact you have to move something to Guest Network so it starts working properly indicates issues with AX86U. This is not a "fix", but sort of "accidental workaround". Enjoy the advanced Guest Network until Asus "fixes it" with firmware update and your IoTs stop working again.

Actually the lights had the same behavior regardless the router I used (so, contrary to initial impressions) this isn't an Asus specific issue. As @drinkingbird mentioned on the specific thread on this topic, the lights were probably being flooded off the network being on the main wifi network, putting them on a guess isolated from the main network is for their sanity, not mine.

 

[Tech9]

Your main 2.4GHz Wi-Fi and Guest 2.4GHz Wi-Fi is the same radio. There should be no difference in behavior whatsoever.

 

[iFrogMac]

Your main 2.4GHz Wi-Fi and Guest 2.4GHz Wi-Fi is the same radio. There should be no difference in behavior whatsoever.

the main difference is, the guest network is a different subnet from the main network, so it isolates the bulbs from the main network traffic, and vs versa . One thing I can also report is, a couple of my Echo devices, would always report a busy wifi network with everything on one network, now that the bulbs are on their own supbnet and their traffic isn't on the main network, the same Echo devices that used to report noisy / busy wireless, report everything is clean.

So, the take away here is, putting the bulbs on their own subnet solved the problem. This just happened to be way of a guest network in this case. One additional thought to add here, I could have probably solved the same problem with a double NAT using two routers.

 

[Tech9]

As I said - "accidental workaround" for something buggy.

 

[drinkingbird]

As I said - "accidental workaround" for something buggy.

With the cheap IOT wifi chipsets, MDNS and broadcast traffic seems to overload them. So in this case moving to a separate broadcast domain (whether subnet isolation, or firewall isolation in the case of GW2 and 3) does seem to be an actual fix and not a fluke. Also helps that Asus uses EBTABLES to prevent the Guest devices from seeing each other at all, so the only broadcasts each device sees are the router interface.

 

[drinkingbird]

the main difference is, the guest network is a different subnet from the main network, so it isolates the bulbs from the main network traffic, and vs versa . One thing I can also report is, a couple of my Echo devices, would always report a busy wifi network with everything on one network, now that the bulbs are on their own supbnet and their traffic isn't on the main network, the same Echo devices that used to report noisy / busy wireless, report everything is clean.

So, the take away here is, putting the bulbs on their own subnet solved the problem. This just happened to be way of a guest network in this case. One additional thought to add here, I could have probably solved the same problem with a double NAT using two routers.

Yeah there are many forms of isolation, the double NAT would have done it, the separate subnet does it (simply by the way subnetting works) and even GW2 and 3 would probably work since the firewall blocks just about all traffic between the main LAN and also between the devices themselves (GW1 actually does that too).

So in reality you're benefitting from two things, the GW1 being on its own subnet and thus not seeing broadcasts (which includes MDNS which is very common now) from the main LAN, as well as the Layer2 isolation that Asus puts between the devices on the guest WIFI. So in essence each of your IOT devices are on their own isolated segment, two bulbs on the GW can't even see each other. Of course if you have a system where the devices need to talk to each other, or to a hub, or you need discovery from an Alexa type device to find the bulbs, that is a problem. But it seems a lot of systems have moved that functionality out to the cloud, probably at least partially for that reason (and the bigger part is to have you in a position where they can offer value added services for a fee, and maybe a little bit of usage monitoring to be able to make some money off your anonymized data).

 

[iFrogMac]

Yeah there are many forms of isolation, the double NAT would have done it, the separate subnet does it (simply by the way subnetting works) and even GW2 and 3 would probably work since the firewall blocks just about all traffic between the main LAN and also between the devices themselves (GW1 actually does that too).

So in reality you're benefitting from two things, the GW1 being on its own subnet and thus not seeing broadcasts (which includes MDNS which is very common now) from the main LAN, as well as the Layer2 isolation that Asus puts between the devices on the guest WIFI. So in essence each of your IOT devices are on their own isolated segment, two bulbs on the GW can't even see each other. Of course if you have a system where the devices need to talk to each other, or to a hub, or you need discovery from an Alexa type device to find the bulbs, that is a problem. But it seems a lot of systems have moved that functionality out to the cloud, probably at least partially for that reason (and the bigger part is to have you in a position where they can offer value added services for a fee, and maybe a little bit of usage monitoring to be able to make some money off your anonymized data).

I only had to connect the phone to the guest network with the bulbs to pair them. Once paired, they can can either talk through the cloud, or locally in the LAN over UDP via the app. For pairing, they use a combination of Bluetooth, and WiFi. After that, not sure if BT is used at all.

 

[drinkingbird]

I'm not sure exactly what happened but the reboot fixed it. FYI: I'm running on a clean setup of this firmware e.g. I factory reset and cleared data, and set up as brand new. Something may have just gotten stuck, I had made changes, but didn't reboot initially. Maybe I should have, will keep and eye on it. I usually don't go into the web UI all that much once things are stable.

Client list has its occasional flukes. It has gotten a lot better and in my case (old AC router) have not noticed any issues since 384 code base. Sometimes a device disappears because it is in low power mode and hasn't sent any traffic in a long time, pinging it makes it reappear. That and when it first comes up, devices that are no longer connected show for a couple seconds and disappear.

The source for that is closed so sometimes a bit of a mystery what it is doing and why.

 

[iFrogMac]

@drinkingbird, regarding the client list. I knew it was frozen up when I disconnected my iPad, which is a regularly connected device that shows up. The devices list was not updated for the disconnect / reconnect. When I say I disconnected it, I turned it off, waited about 5 minutes and powered up. After rebooting the router, I tried again with a spare Apple TV, and the status changes were reported within a few seconds of each other.

 

[drinkingbird]

I only had to connect the phone to the guest network with the bulbs to pair them. Once paired, they can can either talk through the cloud, or locally in the LAN over UDP via the app.

Edited - looking at this further, I'm not sure why you were able to configure it from your phone on the same guest network. At first it appeared to me that UDP was allowed but actually the guest networks have AP isolation enabled so that would block any traffic before it hits the ebtables rules (which allow UDP). My guess is your phone actually connected directly to the bulb (using the temporary wifi network the bulb creates before it is paired) and probably didn't have to be on the guest network at all. Or it may have completely used bluetooth for the initial setup. Maybe you just had to be on the guest network for it to capture the SSID and password from your phone and transfer it to the bulbs.

They should not be able to do UDP to anything other than the internet, nothing on the guest or LAN, from what I can see. So all traffic must be going via the cloud.

 

[drinkingbird]

@drinkingbird, regarding the client list. I knew it was frozen up when I disconnected my iPad, which is a regularly connected device that shows up. The devices list was not updated for the disconnect / reconnect. When I say I disconnected it, I turned it off, waited about 5 minutes and powered up. After rebooting the router, I tried again with a spare Apple TV, and the status changes were reported within a few seconds of each other.

Yeah, I wouldn't worry about it, it has never been 100% but it is a lot better now than it used to be. Powering off the IPAD may result in a stale ARP entry or something that takes 5-10 mins to clear out, or the whole process for client list may have just frozen.

For those that really want client list to be as reliable as possible, a scheduled nightly reboot at like 3AM isn't a bad idea, but in my case it hasn't been necessary, issues are few and far between now.

 

[iFrogMac]

Yeah, I wouldn't worry about it, it has never been 100% but it is a lot better now than it used to be. Powering off the IPAD may result in a stale ARP entry or something that takes 5-10 mins to clear out, or the whole process for client list may have just frozen.

For those that really want client list to be as reliable as possible, a scheduled nightly reboot at like 3AM isn't a bad idea, but in my case it hasn't been necessary, issues are few and far between now.

Part of my problem was I made a bunch of changes regarding the bandwidth limiter and other settings (we already talked about) and never rebooted after finishing the changes. Maybe I should have to flush the memory. Anyway, not important now. Everything seems OK.

 

[drinkingbird]

Part of my problem was I made a bunch of changes regarding the bandwidth limiter and other settings (we already talked about) and never rebooted after finishing the changes. Maybe I should have to flush the memory. Anyway, not important now. Everything seems OK.

Pretty much after any major (or even minor, anything other than like a DHCP reservation or custom client name) change, I reboot. I've noticed for example when you enable Guest wireless 1, VLAN 502 (5ghz) doesn't get created until you reboot, but 501 gets created right away. So yeah a good idea to reboot after changing stuff around, at least once you've gotten stuff finalized and working how you want it (though you may have to reboot to find out if it is actually working how you want it to anyway).

 

[iFrogMac]

Pretty much after any major (or even minor, anything other than like a DHCP reservation or custom client name) change, I reboot. I've noticed for example when you enable Guest wireless 1, VLAN 502 (5ghz) doesn't get created until you reboot, but 501 gets created right away. So yeah a good idea to reboot after changing stuff around, at least once you've gotten stuff finalized and working how you want it (though you may have to reboot to find out if it is actually working how you want it to anyway).

One other thing I wanted to make you aware of @drinkingbird when I had everything on the same network, a few of my more basic amazon echo devices would always report a dirty / busy wireless network. After isolating the bulbs to their own subnet / guests, the same echo devices report a clean and working properly network. So, I think the bulbs themselves also generate quite a bit of noise, due to cheap wireless chipsets. So I wanted to let you know I solved two problems by doing this. With that said, my wireless network seems a lot cleaner now all around.

 

[drinkingbird]

One other thing I wanted to make you aware of @drinkingbird when I had everything on the same network, a few of my more basic amazon echo devices would always report a dirty / busy wireless network. After isolating the bulbs to their own subnet / guests, the same echo devices report a clean and working properly network. So, I think the bulbs themselves also generate quite a bit of noise, due to cheap wireless chipsets. So I wanted to let you know I solved two problems by doing this. With that said, my wireless network seems a lot cleaner now all around.

Any network device will generate a bit of noise (ARP requests mostly, possibly other broadcasts but likely your bulbs aren't initiating any broadcasts other than ARP). But the main "noise" (IP noise, not to be confused with RF noise) comes from when a router, standard host, or MDNS host sends a broadcast, all the devices on the segment will respond to many types, and when you have a lot of devices, that generates a lot of small packets which can really overload something that isn't up for processing all that. Packets Per Second is a commonly overlooked but pretty important factor of a device's network performance. Add to that having to process the MDNS packets and respond to them, it is a lot for a cheap little bulb's chipset to handle.

So in reality it is likely the same thing that was causing both issues, and the fix is the same too, just segmenting stuff off. This didn't really become an issue until people started deploying a bunch of these cheaper IOT devices, and around the same time MDNS/Bonjour/Avahi became standard and common.

Not sure what the Echos key that statistic off, it could be amount of broadcasts and other traffic they're seeing, could be latency due to all of those packets, or just that the wifi throughput is low due to the congestion being caused. Regardless, the isolation significantly decreases the broadcast traffic and alleviates the issue.

A few years ago, network segmentation in the home was not even a topic for the average person, but it will be more and more. I suspect you'll even start seeing "IOT" networks as a feature in these home routers similar to "Guest" networks, and multiple subnets will be a standard.

 

[Tech9]

With the cheap IOT wifi chipsets, MDNS and broadcast traffic seems to overload them. So in this case moving to a separate broadcast domain (whether subnet isolation, or firewall isolation in the case of GW2 and 3) does seem to be an actual fix and not a fluke.

Seems to overload and seems to fix are assumptions. There is definitely something buggy around the AP or the clients. I remember a few people fixing the IoT situation just by using a better quality AP with more clients support.

 

[Tech9]

Would be great to get the upper UNII4 channels.

What you need them for?

 

[bbunge]

What you need them for?

Because I like to try things. Same as you.

 

[Tech9]

Try it with what? There is no single client supporting it.