AI Mesh DHCP issue

[Wipedrive]

I have an AX6100 (2x RT-AX92U) mesh system on firmware 3.0.0.4.386_41535. I have an interesting problem with how the mesh is handling DHCP with guest networks. Frequently after a reboot devices will have issues getting reconnected to my 2.4GHz guest network that I use for segmenting off IoT devices. The system logs fill up quickly with repeated
messages saying that the DHCP is unable to give an address over br1, and devices are unable to communicate as a result. On more rare occasions I've seen it also randomly hand out 192.168.100.x network addresses rather than the usual address pool (192.168.50.x) I have setup. I have tried just disabling and re-enabling that guest network, but that causes ANOTHER weird issue that makes the WAN freak out and become unavailable, saying some error about the ISP DHCP not working right.

I have figured out a workaround that involves me disabling ALL of my guest networks (I have 3 including the one mentioned above), then rebooting the mesh system (both main router and the secondary node). If I do that then re-enable the guest networks after the fact it seems like it's good to go. It's not as horribly inconvenient as I may have made it sound, but I like tinkering with the smart connect rules and such for fun so as long as I leave it alone it's stable. I'm mostly curious if anyone has had the same issue as opposed to needing an immediate solution or anything.

 

[ColinTaylor]

The new 386 firmware uses different IP address ranges (192.168.101.x and 192.168.102.x) and interfaces for the first guest network on each band.

http://www.snbforums.com/threads/asuswrt-386-new-guest-network-ip-space-and-dhcp-static-ips.67598/
http://www.snbforums.com/threads/gu...-chromecast-and-a-potential-workaround.68307/

 

[Wipedrive]

The new 386 firmware uses different IP address ranges (192.168.101.x and 192.168.102.x) and interfaces for the first guest network on each band.

http://www.snbforums.com/threads/asuswrt-386-new-guest-network-ip-space-and-dhcp-static-ips.67598/
http://www.snbforums.com/threads/gu...-chromecast-and-a-potential-workaround.68307/

Cool good to know for the subnet range weirdness, although for me it hasn't actually been giving those 100.x addresses out regularly and is still giving devices in the first guest networks IPs in my normal pool. I wonder if that is a little buggy then since it goes back and forth trying to assign IPs from both ranges.

Im not sure what your second link was about though in context. My IoT devices don't need to talk to each other and I'm not having any Chromecast issues or issues with client isolation. Once they are actually issued an ip they work as intended, it's just the problem of an IP actually getting assigned.

 

[ColinTaylor]

The second link was just another confirmation of the change in IP addresses and an FYI in case you experienced those issues. I don't use that firmware but I do get the impression that it's still a work in progress.

 

[Wipedrive]

The second link was just another confirmation of the change in IP addresses and an FYI in case you experienced those issues. I don't use that firmware but I do get the impression that it's still a work in progress.

Ahh gotcha, I appreciate you looking out then weeeee. I may just try setting up the guest networks in other slots as suggested, though I'll be sad that I won't be able to utilize the Sync to Nodes option they added recently. My place isn't big enough to matter though anyways.