Guest Network on 386 builds doesn't play nice with Chromecast, and a potential workaround

[john9527]

I found where it's being forced!!!! (Well, pretty sure )
Will have a new test build for you in about an hour.....

 

[JWoo]

what about the gui settings? And so i guess a minor issues then.

The "problem" created in the 386 builds is that Asus changed the behavior of the GUI settings.

So in a 386 build, if you select "Access Intranet" = "Disable" and click "Apply", the Guest Network function turns on AP isolation and also updates routing. If "Access Intranet" = "Enable" then AP Isolation is off but your guest network devices now have full run of your LAN.

What is wanted is a setting as in the 384 builds where the devices on the guest network can communicate with other devices on that guest network, but cannot access the LAN. The workaround is to set "Access Intranet" = "Disable" and then manually set the AP isolation parameter = 0. That gives the same behavior as on the 384 builds. As others on this thread have suggested, the ideal permanent solution would be a 3rd option on "Access Intranet" which the devices on the guest network cannot access the LAN, but can talk with each other on that guest network.

 

[JWoo]

I found where it's being forced!!!! (Well, pretty sure )
Will have a new test build for you in about an hour.....

You are a smart cookie @john9527 and you excel also in perseverance. Is the whole function closed source or did Asus make some parts of the source code available for the guest network?

 

[cooloutac]

The "problem" created in the 386 builds is that Asus changed the behavior of the GUI settings.

So in a 386 build, if you select "Access Intranet" = "Disable" and click "Apply", the Guest Network function turns on AP isolation and also updates routing. If "Access Intranet" = "Enable" then AP Isolation is off but your guest network devices now have full run of your LAN.

View attachment 28601

What is wanted is a setting as in the 384 builds where the devices on the guest network can communicate with other devices on that guest network, but cannot access the LAN. The workaround is to set "Access Intranet" = "Disable" and then manually set the AP isolation parameter = 0. That gives the same behavior as on the 384 builds. As others on this thread have suggested, the ideal permanent solution would be a 3rd option on "Access Intranet" which the devices on the guest network cannot access the LAN, but can talk with each other on that guest network.

yes I understand the issue. but those ap isolation settings are not found in the gui is what I was saying. a minor issue for you, but not for the less savvy. I myself haven't noticed any problems with my guest network devices talking to each other on guest 2 and 3 but maybe i'm wrong? I was also wondering if setting that to disable on a guest network also affects ap isolation setting on the main network. But you have just pointed out in your other post those are separate settings so I'm assuming not, and probably why i haven't noticed issues there either.

 

[JWoo]

yes I understand the issue. but those ap isolation settings are not found in the gui is what I was saying. a minor issue for you, but not for the less savvy. I myself haven't noticed any problems with my guest network devices talking to each other on guest 2 and 3 but maybe i'm wrong? I was also wondering if setting that to disable on a guest network also affects ap isolation setting on the main network. But you have just pointed out in your other post those are separate settings so I'm assuming not, and probably why i haven't noticed issues there either.

Agree with you 100%. Sorry for recapping the problem, again.. From my experiences on the 384 and 386 builds, AP isolation on the guest network does not impact the main network. As you state, this is definitely an issue for the less tech savvy because when they run the 386 builds their ChromeCast will likely break. In my own case, I had recently updated firmware on most of the IoT devices so took a bit to discern the router as causing the ChromeCast to not work.

 

[cooloutac]

Agree with you 100%. Sorry for recapping the problem, again.. From my experiences on the 384 and 386 builds, AP isolation on the guest network does not impact the main network. As you state, this is definitely an issue for the less tech savvy because when they run the 386 builds their ChromeCast will likely break. In my own case, I had recently updated firmware on most of the IoT devices so took a bit to discern the router as causing the ChromeCast to not work.

yep nice catch.

 

[john9527]

@JWoo @L&LD

There's a new AX58 build in my development folder
https://1drv.ms/f/s!Ainhp1nBLzMJiF2l3WjM46lSmxrH

Fingers crossed....

 

[JWoo]

yep nice catch.

@JWoo @L&LD

There's a new AX58 build in my development folder
https://1drv.ms/f/s!Ainhp1nBLzMJiF2l3WjM46lSmxrH

Fingers crossed....

Here is the result of patch testing.

I created new Guest Networks with "Access Intranet" = "Disable" and with the patched build from @john9527 AP isolate = 0 (without the patch it would have been 1). I also updated a Guest Network where I had set AP isolate =1 and with the patched build, the function set AP isolate back to 0. Using "Access Intranet" = "Enable", AP isolate is also 0.

Both the "Access Intranet" setting "Enable" and "Disable" appear to set AP isolate = 0.

This patch is a success. It makes the 386 build's Guest Network function the same as it did under the 384 builds.

 

[john9527]

@JWoo
Thanks for the quick check!

I have another compile going right now which adds 'AP Isolation' to the gui.....

PS - They hid the 'force' of ap_isolate in plain sight....in the gui code of all places

 

[JWoo]

Just as an FYI, here is the whole list of parameters Asus is using on each guest network. I am assuming (have not tested) that lanaccess and ap_isolate are the parameters driving this function.

2.4Ghz, 3rd guest network parameters

wl0.3_akm=
wl0.3_ap_isolate=0
wl0.3_auth=0
wl0.3_auth_mode=none
wl0.3_auth_mode_x=open
wl0.3_bridge=
wl0.3_bss_enabled=0
wl0.3_bss_maxassoc=128
wl0.3_bw_dl=
wl0.3_bw_enabled=0
wl0.3_bw_ul=
wl0.3_closed=0
wl0.3_crypto=aes
wl0.3_expire=0
wl0.3_hwaddr=XX:XX:XX:XX:XX:XX
wl0.3_ifname=wl0.3
wl0.3_infra=1
wl0.3_key=1
wl0.3_key1=
wl0.3_key2=
wl0.3_key3=
wl0.3_key4=
wl0.3_lanaccess=off
wl0.3_maclist=
wl0.3_macmode=disabled
wl0.3_maxassoc=128
wl0.3_mode=ap
wl0.3_net_reauth=36000
wl0.3_preauth=
wl0.3_radio=1
wl0.3_radius_ipaddr=
wl0.3_radius_key=
wl0.3_radius_port=1812
wl0.3_sae_anti_clog_threshold=5
wl0.3_sae_groups=19 20 21
wl0.3_sae_sync=5
wl0.3_ssid=ASUS_48_2G_Guest3
wl0.3_sta_retry_time=5
wl0.3_unit=0.3
wl0.3_wep=disabled
wl0.3_wep_x=0
wl0.3_wfi_enable=0
wl0.3_wfi_pinmode=0
wl0.3_wme=auto
wl0.3_wme_bss_disable=0
wl0.3_wpa_gtk_rekey=3600
wl0.3_wpa_psk=
wl0.3_wps_mode=disabled
wl0_vifnames=wl0.1 wl0.2 wl0.3
wl0.3_maclist=

 

[JWoo]

@JWoo
Thanks for the quick check!

I have another compile going right now which adds 'AP Isolation' to the gui.....

PS - They hid the 'force' of ap_isolate in plain sight....in the gui code of all places

Our cat is also great at hiding in plain site. Sometimes that is the best place to hide. Really looking forward to your GUI addition!

 

[francovilar]

Using aimesh: main router wl0.1 was ap isolate 1, changed nvram and the clients connected to main router were ok. On node router the only wl with 1 was wl0.2, if I change some clients disconnected. John can you make a build for a ac86u (both my routers are 86u)? Or my issue is a different game...

 

[john9527]

There may actually be some interaction with ap_isolate and aimesh. The code was checking for aimesh capable routers (not that aimesh was actually configured) and forcing isolate if lan access was disabled. That's why this needs to be checked in various configs.

I'll kick off an ac86u build later today.

 

[john9527]

I've added a second build to my development folder...
RT-AX58U_386.1_beta2-g5ae5a5c402

If I didn't make any dumb typo's this should add an 'AP Isolation' setting to the guest gui....

 

[JWoo]

Totally loving it. Looks totally professional.

In testing, the Access Intranet setting is correctly toggling the variable wlx.y_lanaccess. The new AP Isolation setting in the GUI is not toggling the parameter wlx.y_ap_isolate. When I save AP Isolation Enabled in the GUI, the setting in the GUI remains as Disabled and the parameter is also not changed.

 

[john9527]

@JWoo
Sorry....forgot to check if it was in the shared nvram defs so it could be updated by the gui. re-building.....

 

[Jack Yaz]

@JWoo
Thanks for the quick check!

I have another compile going right now which adds 'AP Isolation' to the gui.....

PS - They hid the 'force' of ap_isolate in plain sight....in the gui code of all places

How does your build interact with YazFi's setting of the ap_isolate , if at all? YazFi already makes these configurable per guest network.

 

[john9527]

How does your build interact with YazFi's setting of the ap_isolate , if at all? YazFi already makes these configurable per guest network.

Shouldn't behave any different than it behaved on 384 code
But, since it wasn't in the gui on 384 either, depending on where you intercept the setup to make your changes, it may be possible that someone could override your setting by changing the gui. Not sure where you do your magic.

 

[Jack Yaz]

Shouldn't behave any different than it behaved on 384 code
But, since it wasn't in the gui on 384 either, depending on where you intercept the setup to make your changes, it may be possible that someone could override your setting by changing the gui. Not sure where you do your magic.

currently it will be applied on either firewall-start or a restart_wireless event

 

[jrodiono]

Does anyone know if this thing will work out in the final version? Blocking the communication of machines on guest networks makes it impossible to use the entire guest network on IoT devices.