Kvall
May 21, 2023, 9:00pm
1700
Found something possibly related while I was researching option flags.ap_isolate=1
I don't understand what this flag is supposed to do. Apparently it's supposed to be set to 1 for better security but you can probably flip it to 0 as a workaround to your issue.
opened 06:17PM - 17 Aug 20 UTC
core packages
release/19.07
flyspray
*PhobosK:*
I have two devices that show the same problem - both TP-Link, but di… fferent models.
The problem is that the devices/clients connected to any of the wlans are always isolated no matter what the config "isolate clients" is set to.
These devices cannot ping and see each other but they can be pinged and they can ping devices from/to devices in lan.
Further more the generated **/var/run/hostapd-phy0.conf** and **/var/run/hostapd-phy1.conf**
always have the //**ap_isolate=1**//
The tested devices are:
<code>
root@OpenWrt:~# ubus call system board
{
"kernel": "4.14.180",
"hostname": "OpenWrt",
"system": "Qualcomm Atheros QCA9558 ver 1 rev 0",
"model": "TP-Link Archer C7 v2",
"board_name": "tplink,archer-c7-v2",
"release": {
"distribution": "OpenWrt",
"version": "19.07.3",
"revision": "r11063-85e04e9f46",
"target": "ath79/generic",
"description": "OpenWrt 19.07.3 r11063-85e04e9f46"
}
}
</code>
<code>
root@OpenWrt:~# ubus call system board
{
"kernel": "4.14.180",
"hostname": "OpenWrt",
"system": "Atheros AR9344 rev 2",
"model": "TP-Link TL-WDR4300 v1",
"board_name": "tplink,tl-wdr4300-v1",
"release": {
"distribution": "OpenWrt",
"version": "19.07.3",
"revision": "r11063-85e04e9f46",
"target": "ath79/generic",
"description": "OpenWrt 19.07.3 r11063-85e04e9f46"
}
}
</code>
No packages have been updated manually on both devices.
Both devices has defaults sets coming with the default factory OpenWrt 19.07.3 image.
Both devices were set for their //Network -> Wireless -> wlan0 (and wlan1) -> Interface configuration -> Advanced settings -> Isolate clients// **//UNCHECKED//**
Here is the config of one of the devices (///etc/config/wireless//) and the respective generated ///var/run/hostapd-phy0.conf//
<code>
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/ahb/18100000.wmac'
option channel 'auto'
option country 'BG'
option htmode 'HT20'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option key 'XXXXXX'
option ssid 'YYYYYYYY'
option encryption 'psk2'
</code>
Even when option isolate '0' is added manually using uci not luci, and restarting the device the respective hostapd-phy0.conf remains with **ap_isolate=1**
<code>
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=BG
ieee80211d=1
hw_mode=g
beacon_int=100
channel=acs_survey
ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]
interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
wpa_passphrase=XXXXXX
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=YYYYYYYY
bridge=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=xx:xx:xx:xx:xx:xx
</code>
My guess is that hostapd/wpad doesn't set properly the ap_isolate according to the config.
Please let me know if you need further info.
Thanks
It might be worth checking how things are actually set in sysfs.
As I understand things, there are 3 "isolation" settings... first there is an internal
hostapd setting (ap_isolate=1), which should nowadays always be set on. This
prevents hostapd from forwarding between wifi clients internally. Instead what it does
is forward all the traffic to the br- interface and let that decide what to do with it, so that
multicast-to-unicast transforms may be performed to increase common-case
perform…
@RadianM - the way I understood it is the following:
there is a little known per-iface option option multicast_to_unicast which - if unset - defaults to true
that feature implies mac80211-level client isolation and handles client<>client forwarding using a mechanism called "bridge hairpinning" instead
in theory this should not prevent client<>client communication and work the same way as an unisolated wireless network but it seems that - at least on 17.04 - there might be some kernel level is…
I am on OpenWrt SNAPSHOT r22923-fd0118c0a5 / LuCI Master git-23.118.79121-6fb185f.
