ap_isolate is set to 1 if not defined, at least for my setup. Please add
isolate=0
to your wlan interface.
ap_isolate is set to 1 if not defined, at least for my setup. Please add
isolate=0
to your wlan interface.
"option isolate 0" and "option isolate 1" makes no difference on my device and "ap_isolate" is always set to 1 in /tmp/run/hostapd-phy0.conf
Dont understand why...???
One could look at the script that creates the hostapd.conf, but currently i doesn´t remeber where this bash script is located...
lede 17.01.4
R7800
same problem
sad
/lib/netifd/netifd-wireless.sh
Thanks.
I found the script for hostapt in the same folder...
/lib/netifd/hostapd.sh
-> final rom
package/network/services/hostapd/files/hostapd.sh
-> open wrt src
Parse of config looks good to me, don´t know why i always get ap_isolate=1
in hostapd-X.conf
Looking at it here, https://openwrt.org/docs/guide-user/network/wifi/basic says default for isolate
is 0
, yet I see ap_isolate=1
in my hostapd-phy1.conf
Adding option isolate '0'
to the AP definition doesn't change the contents of hostapd-phy1.conf
here either.
(on master
here of a week or so ago)
You guys should read the earlier posts in this thread about the difference between isolate in uci and ap_isolate for hostapd
Since it's not documented in the wiki, and there's a year's worth of posts here, from June, 2017:
find /sys/devices -name hairpin_mode -exec sh -c 'printf "%s: %s\n" {} $( cat {} )' \;
Experiencing the same issue on a Linksys WRT1900ACSv1 / LEDE Reboot 17.01.4 r3560-79f57e422d.
Some WiFi clients (XP client in particular) cannot access Windows' Shares, others cannot "see" Network Printers.
Results / Configs
root@LEDE:/etc/config# find /sys/devices -name hairpin_mode -exec sh -c 'printf "%s: %s\n" {} $( cat {} )' \;
/sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/hairpin_mode: 1
/sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/hairpin_mode: 1
/sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/hairpin_mode: 0
root@LEDE:/sys# for f in $(find . -name hairpin_mode -o -name multicast_to_unicast -o -name isolate_mode); do echo $f; cat $f; done
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/isolate_mode
0
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/hairpin_mode
1
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/multicast_to_unicast
1
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/isolate_mode
0
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/hairpin_mode
1
./devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/multicast_to_unicast
1
./devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/isolate_mode
0
./devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/hairpin_mode
0
./devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/multicast_to_unicast
0
./kernel/debug/ieee80211/phy1/netdev:wlan1/multicast_to_unicast
0x0
./kernel/debug/ieee80211/phy0/netdev:wlan0/multicast_to_unicast
0x0
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=US
ieee80211d=1
ieee80211h=1
hw_mode=a
beacon_int=100
channel=36
ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
ieee80211ac=1
vht_capab=[RXLDPC][SHORT-GI-80][SU-BEAMFORMER][SU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][MAX-A-MPDU-LEN-EXP7]
interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=REDACTED
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=MANUMACH
bridge=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=REDACTED
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=US
ieee80211d=1
hw_mode=g
beacon_int=100
channel=11
ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
interface=wlan1
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=REDACTED
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=MANUMACH
bridge=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=REDACTED
it seems to me that when the wifi goes to "isolation mode", even the connection wifi to wired gets some problem.
It is not impossible like wifi to wifi, but it returns random errors.
I also have to admit that i remember in the last months with ddwrt i had the same problem (i had to periodically reboot the router since i could not access my wifi-connected raspis)
anyone without guest lan is experiencing this?
Sorry to be so hopelessly noobish but I feel that if this issue has been resolved, then a clear summary of the solution could do with being added to close this thread. I'm so far out of my depth, I can't identify which post if any provides the solution despite numerous repeat readings of the entire topic.
If, on the other hand, this is still unresolved then I can confirm that the default config of LEDE Reboot 17.01.4 on a Linksys WRT1900ACSv2 suffers from the problem of Wireless clients not being able to communicate with each other. For example, a laptop cannot view a wireless IP camera unless connected to the router via ethernet. My guess is that such a common use-case would result in this being solved by now. I hope I'm not wrong.
@RadianM - the way I understood it is the following:
option multicast_to_unicast
which - if unset - defaults to true
multicast_to_unicast
option is neither mentioned in the default wifi config, nor exposed in LuCI, users are not aware of it and are unable to disable it (without knowing that it exists + SSH access)
isolate
option is confusing as it is added despite option isolate 0
, due to the implicit-enabled-if-absent multicast_to_unicast
option multicast_to_unicast 0
to all affected config wifi-iface
sectionsSomeone please correct me if the above is wrong.
i've not digged inside my router, but as soon as i went from 17.01.4 to something newer i stopped having this sort of problems.
One addition would be the confusion around the "isolate" UCI parameter, presently documented at https://openwrt.org/docs/guide-user/network/wifi/basic
The bug reported in FS #714 is still present in 18.06 RC1, and leads to issues like WiFi printers no longer being reachable until a reboot or a 'wifi' command to restart the wifi subsystem.
To be clear, this bug is not a configuration bug, it is a time-based loss of functionality that works fine when first booted.
This is true. This is probably why the developers can't reproduce the bug.
After a fresh boot I can ping my devices connected to the router, but after a few hours they can't see each other anymore.
Example - 192.168.1.2 is my desktop-pc wired to eth1 and 192.168.1.3 is my android phone connected to ath1. After a fresh boot I get:
ping 192.168.1.3
Pinging 192.168.1.3 with 32 bytes of data:
Reply from 192.168.1.3: bytes=32 time=125ms TTL=44
Reply from 192.168.1.3: bytes=32 time=125ms TTL=44
Reply from 192.168.1.3: bytes=32 time=124ms TTL=44
Reply from 192.168.1.3: bytes=32 time=124ms TTL=44
Ping statistics for 192.168.1.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss).
Approximate round trip times in milli-seconds:
Minimum = 124ms, Maximum = 125ms, Average = 124ms
Then after a few hours:
ping 192.168.1.3
Pinging 192.168.1.3 with 32 bytes of data:
Reply from 192.168.1.2: Destination host unreachable.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.1.3:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss).
If I try pinging 192.168.1.3 again I get Reply from 192.168.1.2: Destination host unreachable.
all four times.
I don't understand why ping from my desktop resolves 192.168.1.3 as itself and pings 192.168.1.2 instead, obviously a obscure bug in the router.
I already tried:
echo 1 > /sys/devices/virtual/net/br0/lower_ath0/brport/hairpin_mode
echo 1 > /sys/devices/virtual/net/br0/lower_eth1/brport/hairpin_mode
and
swconfig dev eth0 set enable_vlan 1
swconfig dev eth0 set apply
Setting hairpin mode to 1 on eth1 causes all my LAN to loose connectivity to the router, can't even ping the gateway. Same bug happens on DD-WRT since it uses the same switch drivers.
This causes a series of problems, devices can't see each other for syncing anymore, printers cannot be found, remote control on demand can't reach the target devices waiting the requests anymore and much more.
You get a response from your local network stack, this is as expected for "Destination host unreachable", not a obscure router bug.
Probably because it sends ARP requests and when multicast does not go through it is unable to resolve the destination MAC address.
My bug report might be misleading now though. I wrote it because of the problem caused by some characters in the interface names. After i renamed the wifi interfaces i never had such problems anymore, my Archer C5 has more than 200 days uptime today (still on 17.01.4) and works prefectly fine. Also LAN ââ WLAN always worked for me, only between WLAN clients was no connection.
As far as i understand it, most people here experience a different bug, that comes after a somewhat random time and that affects different wired/wireless combinations.
It would probaly be helpful to try the workaround that Jow suggested here:
To make sure that it is really caused by this feature.
Must be a different root issue then, as my Wifi name is four alphabetic characters.
Carefully re-reading your bug report, I see there is no time component, it just did not work from the outset. Several of us conflated the loss of functionality similarity, but for us, everything works for 24 to 48 hrs, then mDNS (and other multicast) stops working.
So we need a new bug report focused specifically on the time-based loss of functionality, I'll compose one in the next day or so.
UP
I've the same issue on may 1200ac... (v 17.01.4 )
cannot ping from wlan to wlan.
root@spaceship:/# for f in $(find . -name hairpin_mode -o -name multicast_to_unicast -o -name isolate_mode); do echo $f; cat $f; done
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/isolate_mode
0
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/hairpin_mode
1
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0/net/wlan0/brport/multicast_to_unicast
1
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/isolate_mode
0
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/hairpin_mode
1
./sys/devices/platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0/net/wlan1/brport/multicast_to_unicast
1
./sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/isolate_mode
0
./sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/hairpin_mode
0
./sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0/brport/multicast_to_unicast
0
./sys/kernel/debug/ieee80211/phy1/netdev:wlan1/multicast_to_unicast
0x0
./sys/kernel/debug/ieee80211/phy0/netdev:wlan0/multicast_to_unicast
0x0
I'm not sure what I ve to do ...