Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port isolation in a bridge wlan devices is not working #10864

Open
PhobosK opened this issue Sep 30, 2022 · 5 comments
Open

Port isolation in a bridge wlan devices is not working #10864

PhobosK opened this issue Sep 30, 2022 · 5 comments

Comments

@PhobosK
Copy link

PhobosK commented Sep 30, 2022

Activating the Port isolation option of any wlan device that is part of a bridge, commits the configuration properly (adding the option isolate '1') but is not turning the kernel option on or off at all. For ethernet devices it works OK.
Example:

  1. Check isolation of the wlan1 device of bridge br-lan
root@OpenWrt:~# cat /sys/class/net/br-lan/brif/wlan1/isolated
0
  1. Turn on isolation:
root@OpenWrt:~# uci set network.cfg1a0f15.isolate='1'
root@OpenWrt:~# uci commit
  1. The config in /etc/network is ok:
config device
	option name 'wlan1'
	option isolate '1'
  1. but the change is not actually committed:
root@OpenWrt:~# cat /sys/class/net/br-lan/brif/wlan1/isolated
0

OpenWrt 22.03.0, r19685-512e76967f
TP-Link Archer C7 v2
Kernel Version 5.10.138

@brada4
Copy link

brada4 commented Sep 30, 2022

3 is not ok. First file name is off and you need isolate in wifi-iface (i.e wifi SSID section) in /etc/config/wireless

@PhobosK
Copy link
Author

PhobosK commented Sep 30, 2022

Thanks for your input.

Yes I have also turned on the option Isolate Clients in Wifi Advanced settings - file /etc/wireless

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option key 'XXXXXXXXXXXXXXXXXX'
	option ssid 'XXXXXXXXX'
	option encryption 'psk2'	
	option isolate '1'

But this is expected to only Isolate wireless clients from each other, not all the clients between the ports of the bridge...
Thus allowing the clients from lan (eth1.1 in this case which is part of br-lan together with wlan1) to communicate with clients from wireless...

The device isolate option in /etc/network is expected to have totally different behaviour... It should block clients communication between isolated ports of the bridge...

Actually when doing manually:

echo 1 > /sys/class/net/br-lan/brif/wlan1/isolated

everything becomes OK - meaning clients from wlan are separated from those in lan (eth1.1)...

Or am I wrong in the understanding how all these should work? :)

@jow-
Copy link
Contributor

jow- commented Sep 30, 2022

I suppose this is a genuine issue. Might be that netifd is actively ignoring the settings for wlan1 since it treats wireless netdevs specially (for various reasons, targeting wifi netdevs directly from within /e/c/network is either inhibited or resulting in undefined behaviour).

@nbd168 - any thoughts?

@ptpt52
Copy link
Contributor

ptpt52 commented Oct 1, 2022

mark.

@PhobosK
Copy link
Author

PhobosK commented Oct 1, 2022

Thanks you :)

Just to add a bit more info..

Turns out all of the options in the LuCi's Interfaces->Devices->ANY_WIRELESS_NETWORK_DEVICE->Configure->Bridge port specific options for wireless network devices members of a bridge exhibit the same behaviour -> i.e. no matter how you change them, they change in the config files but never change the respective kernel option in /sys
At the same time manually setting them by sysfs always works...
For example these always stay as these defaults when you change them in the interface, but work when you change them directly:

root@OpenWrt:~# cat /sys/class/net/wlan1/brport/multicast_router
1
root@OpenWrt:~# cat /sys/class/net/wlan1/brport/unicast_flood
1
root@OpenWrt:~# cat /sys/class/net/wlan1/brport/learning
1

Seems like they never hit the system_bridge_addif() in netifd/system-linux.c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants