I sent you an e-mail about the disappearing Wi-Fi card on Turris Omnia. Regarding unstable Wi-Fi, were you using 2.4 / 5 GHz frequency? Did you try to different channel?
Thanks @Pepe !
The situation with channels is unfortunately complex:
I am using 2,4 GHz frequency WI-FI via the WLE900VX (channel 11, first floor), as channel 6 is occupied by a neighboor of mine and channel 1 used by my second accesspoint.
About the higher latency - I believe this is a very device-specific problem as I always have a lot of problems with this device. But I can and will only test after I introduced some hopefully working other options (adding 2 additional ap in relevant areas where my wife is always complaining).
off topic
The disconnection issues I right now have on 5.2.7 maybe introduced by moving from plain ath10k (which only allowed 80MHz channel width on 5.1.9) to ath10k-ct (which now allows 160MHz channel width). So if other workarounds donât solve it, I need to get back to ath10k and again no 160MHz 
So I tried again (this time with my spare TO, the productive is on its way to your support) - to reduce complexity first with only one Wi-Fi-card (one WLE900VX).
The TO is connected via eth2 (wan-port) to a managed switch, VIDs are 1,2 and 5 (all tagged, PVID is 1).
This time I encountered something completely new - when connecting via Wi-Fi linked to lan I will get no access to the router or internet even though I get a IP on my client and gateway/dns are correctly transferred (android 10/Windows 10).
Details
- dnsmasq, odhcp and firewall are deactivated (dump ap), dns and dhcp are served by a pihole-VM on my server (IP
192.168.1.12) /etc/config/network
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan0'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'eth2'
list ports 'eth3'
config bridge-vlan
option device 'br-lan'
option vlan '1'
list ports 'lan0'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'eth2:t*'
list ports 'eth3:t*'
config bridge-vlan
option device 'br-lan'
option vlan '2'
list ports 'eth2:t'
list ports 'eth3:t'
config bridge-vlan
option device 'br-lan'
option vlan '5'
list ports 'eth2:t'
list ports 'eth3:t'
config interface 'lan'
option device 'br-lan.1'
option proto 'static'
option ipaddr '192.168.1.2'
option netmask '255.255.255.0'
option gateway '192.168.1.1'
list dns '192.168.1.12'
option delegate '0'
config interface 'iot'
option device 'br-lan.2'
option proto 'none'
config interface 'gast'
option device 'br-lan.5'
option proto 'none'
/etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
option hwmode '11g'
option channel '11'
option htmode 'HT40'
option country 'DE'
option cell_density '0'
config wifi-iface 'wifinet1'
option device 'radio0'
option mode 'ap'
option network 'lan'
option ssid 'TOsv6test'
option encryption 'psk2+ccmp'
option key '<>'
option wpa_disable_eapol_key_retries '1'
- connection is up and totally stable:
root@turris:~# check_connection
Pinging 192.168.1.1 ... OK
IPv4 Gateway: OK
Pinging 217.31.205.50 ... OK
Pinging 198.41.0.4 ... OK
Pinging 199.7.83.42 ... OK
Pinging 8.8.8.8 ... OK
IPv4: OK
IPv6 Gateway: UNKNOWN
Pinging 2001:1488:0:3::2 ... FAILED
Pinging 2001:500:3::42 ... FAILED
Pinging 2001:500:2d::d ... FAILED
Pinging 2606:2800:220:6d:26bf:1447:1097:aa7 ... FAILED
IPv6: FAILED
Resolving api.turris.cz ... OK
Resolving www.nic.cz ... OK
Resolving c.root-servers.net ... OK
DNS: OK
Resolving www.rhybar.cz ... OK
DNSSEC: OK
- when connecting via wire everything works as expected
- when changing
option network 'lan'tooption network 'iot'everything again works as expected
Any idea where to digg for the error?
edit1: wlan0 seems to be correctly bridged to br-lan:
root@turris:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.d858d70042ff no lan4
lan2
wlan0
lan0
lan3
lan1
eth2
adding it manually to the br-vlan-section of VID1 doesnât help either.
The last update completely disables wifi. The only way I get it to work again was rollback to pre-udpate snapshot.
Here no problem after updates.
Even though HBD is a highly dangerous (experimental) branch, feel free to report any issues to OpenWrt or follow the article how to create issues. Also, you should provide more details or troubleshoot it. Unfortunately, this branch is for experienced users. The same applies to the HBL branch, where bugs might appear, and it should not be a problem to recover from it or fix it.
Because the Wi-Fi process is quite complex, there were almost ~60 changes related to Wi-Fi (mac80211, netifd, iw, âŚ) in the stable branch this week. Is it possible that some processes were not started after boot? Any logs (outputs) would be appreciated as usual. It is not enough to post a screenshot from the notification system, which was updated, because it is possible that we would not be able to reproduce it on our end.
Well, after few hours spent with trying many (noob) ways how to get wifi back I succeded with reset to factory default (TOS 5.3.1), then update to HBD and setting all from scratch. So far it seems wifi is working again (even 160MHz, which was working before problems too) with latest updates.
The only difference is that, I have not installed candela drivers yet, and while all is working I am not going to do so.
I have saved kernel and system logs, but they cannot be copied here because of 32000 character limit (it was about 439000 characters). I can send it to Turris support if you want together with diagnostic exports (before and after update.
After problematic update, wifi was gone:
Wireless network tab in LuCI before update:
Wireless network tab in LuCI after update:
PS: I know that HBD can be problematic, but I am awaiting new wifi 6 cards next week, which are working only on TOS 6, so I have to tried that everything is working before installation of these cards. 
check if wpad service is runing, if not enable and restart
I have tried that, but it didn´t help.
After latest (?) update, reForis is inaccessible. Seems that I am logged in, but nothing is displayed. Tried from Edge and Opera. Restart didn´t helped.
Yep⌠We are able to reproduce it on our end and we know what is going on. It will be addressed soon.
1 Like
I can confirm, that reForis is accessible again.