YazFi How to test IP address assignment for guest network?

[DTS]

I am using YazFi to assign guests to a unique IP address range (192.168.20.x) so guests can be routed to my WAN connection directly, bypassing my VPN.

This appears to be working as expected, but I notice a potential issue when testing. I wonder if this is simply a consequence of how I'm testing.

My Android device is connected to the WiFi radio (and NOT as a guest) and it has an IP address via that Wireless connection. Then, to test YazFi, I switch myAndroid WiFi connection to the guest network. I do not immediately get assigned a 192.168.20.x address. Eventually I will, but something (I'm not sure what) has to happen first.

At first this made me think that real guests might not be reliably given the 192.168.20.x addresses. Then I realized what I'm seeing may be an artifact of the way I'm testing. My device may simply be keeping the prior assigned IP address, which would not be true for real guests.

Other than "putting this into production" with real guests, is there a good way to test using my own Android device? Or is there another way I can ensure that guests will only be assigned IP's in the desired address range?

 

[eibgrad]

As always, JY is the authority on his own scripts. But just speaking from experience, I can tell you that scripts like these are usually imperfect, if only because they have to force the system to do things it normally wouldn't do.

Under normal circumstances, what YazFi does is NOT possible. The wireless network interfaces are *still* assigned to the private network's bridge (br0), even when using YazFi, which you can verify w/ a dump of the bridging tables.

brctl show

That alone would normally prevent the guest networks from being assigned differently from everything else on the default private network (br0). It would also normally prevent the firewall from responding to the individual wireless network interfaces, and only to references of br0. But somehow JY has made changes that manage to bypass that behavior. I suppose if I had the inclination to spend all day delving into his code, I'd find the answer. But since I don't, I can only assume those changes can't deal w/ the problem of the client changing network interfaces w/ an existing lease. The router is probably reverting to its default behavior in that case, and sees the assignment on br0 as still valid. Had the wireless network interface actually been properly removed from the br0 bridge and assigned to a new bridge (e.g., br3), this wouldn't be an issue.

Again, all very speculative. But as I said, almost *all* scripting comes w/ various limitations, or fails to consider every possible scenario. And the more those scripts jury-rig things to get around certain inherent behaviors, the more you start to see these kinds of anomalies. It's why I don't generally recommend solutions that make these kinds of extensive, low-level changes. Just too many things can go wrong. And why I strongly recommend users use a separate FT (FreshTomato) router to support additional guest/IOT networks.

Don't misunderstand. YazFi is probably fine for most situations. If anyone is capable of making the router do the impossible, it's JY. But even so, if you push it (like most any other scripting), you'll likely find some oddball problems.

All I can recommend when using YazFi is that you always formally release the DHCP lease before changing to YazFi.

JMTC