I had same issue with wifh, yesterday it forced me to flash actual image from SD card, delete NAND. After that my Turris 1.0 get working back again.
In /etc/config/updater change the line having ādisableā option from ā0ā to ā1ā.
I have noted same problem after latest upgrade. Problem luckily occurs only with my & wifeās Sony Xperia Z3 compact phones and one 1St gen chromecast stick. With phone easy solution is to change from 2,4Ghz to 5Ghz or wiseversa, which fixes problem. With chromecast power on/off loop does same trick. My gut feeling is that problem lies on dhcp/routing department. I try to look into log files if I can get some time
Thanks for the tip. Iāll look into it, at least temporarily. Itās crazy that end-users of a consumer piece of electronics should have to take such actions though.
Running Omnia (no extras). The Atheros card fails since update. The only way Iāve had ANY success keeping it on is to change the setup of the card from AC to N, drop power to 20, force cypher to auto. The other wireless doesnāt seem to be a problem so far, itās what Iām stuck with at the moment.
If youāre having issues reproducing then start with the firmware that was shipped and progress it through the various updates youāve released up to the current. Youāll have the same issue since everyone seems to be in the same boat now.
So are there an options how to relatively easily revert to previous FW on Turris 1.1? I have found some guide for Omnia, where it seems to be super easy, but it seems that turris doesnt have magical schnapps
There is clearly no QA other than some casual tests by developers.
1 Like
Because they canāt reproduce it. They asked us politely to test it. Only few members tested it!
I donāt have an original Turris, and thatās a bullshit excuse. I can get 10 different bugs just doing a fresh install.
1 Like
Donāt understand your post. Saironek, which he is one developer from Turris team ask you and others to provide more informations. As I can see only one guy did it! Itās hard to fix something that they canāt reproduce, right?
This thread should be related to ath9k and this thread was for Turris 1.x., but it can be also for Omnia (for card Compex WLE200N2, which is only 2.4 GHz), but donāt mix it please with ath10k. Itās separately issue and it shouldnt be in this thread. A lots of users did it and itās hard to recognize which post was for ath9k and ath10k.
I think you have problem with ath10k driver - Compex WLE900VX 5 GHZ AC ( Compex WLE900VX 5 GHZ AC card)
Also what I said miska request some users to test new update for ath10k (Ath10k (5GHz card) after upgrade to 3.3). Only few users did it.
So he was forced to push another update, which it seems was bad, so heās trying to figure it out. It will help him if you can try: opkg update; opkg install ath10k-firmware-qca988x; and tell us result in that thread! It will be highly appreciated
Hi, this issue is not resolved yet! I know that Turris 1 has been āfreeā but still it should work. There is no request from turris dev team for additional data or testsā¦ So I had to bought some cheap zyxel wifi router to get working wireless network.
There are my network symptoms againā¦ Iām using 2.4 GHz, channel 6, no other networks at this channel. I tried the same settings for turris and zyxel (only one at the same time). This issue is in Turris OS 3.3 and 3.4.
Turris ping to android / ESP8266:
64 bytes from 10.20.30.8: icmp_seq=253 ttl=64 time=12.5 ms
64 bytes from 10.20.30.8: icmp_seq=254 ttl=64 time=696 ms
64 bytes from 10.20.30.8: icmp_seq=255 ttl=64 time=57.0 ms
64 bytes from 10.20.30.8: icmp_seq=256 ttl=64 time=5.38 ms
64 bytes from 10.20.30.8: icmp_seq=257 ttl=64 time=8.50 ms
64 bytes from 10.20.30.8: icmp_seq=258 ttl=64 time=1695 ms
64 bytes from 10.20.30.8: icmp_seq=259 ttl=64 time=673 ms
64 bytes from 10.20.30.8: icmp_seq=260 ttl=64 time=1031 ms
64 bytes from 10.20.30.8: icmp_seq=261 ttl=64 time=16.1 ms
64 bytes from 10.20.30.8: icmp_seq=262 ttl=64 time=8.66 ms
64 bytes from 10.20.30.8: icmp_seq=263 ttl=64 time=7.04 ms
64 bytes from 10.20.30.8: icmp_seq=264 ttl=64 time=5642 ms
64 bytes from 10.20.30.8: icmp_seq=265 ttl=64 time=4615 ms
64 bytes from 10.20.30.8: icmp_seq=266 ttl=64 time=3591 ms
64 bytes from 10.20.30.8: icmp_seq=267 ttl=64 time=2568 ms
64 bytes from 10.20.30.8: icmp_seq=268 ttl=64 time=1557 ms
64 bytes from 10.20.30.8: icmp_seq=269 ttl=64 time=535 ms
64 bytes from 10.20.30.8: icmp_seq=270 ttl=64 time=884 ms
64 bytes from 10.20.30.8: icmp_seq=271 ttl=64 time=7.24 ms
64 bytes from 10.20.30.8: icmp_seq=272 ttl=64 time=7.84 ms
Zyxel ping to android / ESP8266:
64 bytes from 10.20.30.8: icmp_seq=1568 ttl=64 time=3.94 ms
64 bytes from 10.20.30.8: icmp_seq=1569 ttl=64 time=3.12 ms
64 bytes from 10.20.30.8: icmp_seq=1570 ttl=64 time=4.22 ms
64 bytes from 10.20.30.8: icmp_seq=1571 ttl=64 time=2.76 ms
64 bytes from 10.20.30.8: icmp_seq=1572 ttl=64 time=4.47 ms
64 bytes from 10.20.30.8: icmp_seq=1573 ttl=64 time=3.98 ms
64 bytes from 10.20.30.8: icmp_seq=1574 ttl=64 time=4.33 ms
64 bytes from 10.20.30.8: icmp_seq=1575 ttl=64 time=3.30 ms
64 bytes from 10.20.30.8: icmp_seq=1576 ttl=64 time=5.12 ms
64 bytes from 10.20.30.8: icmp_seq=1577 ttl=64 time=3.80 ms
64 bytes from 10.20.30.8: icmp_seq=1578 ttl=64 time=23.7 ms
64 bytes from 10.20.30.8: icmp_seq=1579 ttl=64 time=2.78 ms
64 bytes from 10.20.30.8: icmp_seq=1580 ttl=64 time=3.15 ms
64 bytes from 10.20.30.8: icmp_seq=1581 ttl=64 time=2.97 ms
64 bytes from 10.20.30.8: icmp_seq=1582 ttl=64 time=3.94 ms
64 bytes from 10.20.30.8: icmp_seq=1583 ttl=64 time=5.95 ms
If anyone from turris team needs some additional data, just send me an email.
Thanks
Guys you are wasting your time wating for team to solve it. As I already wrote here flash newest image from sdcard as described in official documentation. To me that solved wifi problem.
Thanks, Iāve just spend about 4 hours with wiping, flashing and restoring to previous state (updating packages, configuring network, dhcp, firewall and vpn). But it didnāt help. The issue is still there.
1 Like
Well to me it works flawlesly on Turris 1 without any problems.
Not sure if it the same problem but for me since some recent turris1.0 update (3.3?) wifi power saving is broken for internal wifi card. I have very bad connection from one android tablet and OpenPandora and figured out that when I run āiwconfig wlan0 power offā on my OpenPandora the connectivity works perfectly. when I run āiwconfig wlan0 power onā it breaks again. When connecting to my other access point it runs fine even with power management turned on. I donāt know how to disable wlan power saving on my android to see if it is the same problem but most probably it is.
I did not find any way to tune this on Turris side in Luci. Toggling WMM checkbox makes no difference. It worked fine for years before the 3.x update.
Here is ping example with power saving on and off. Looks like the packets get queued somewhere (for up to 15 seconds!) and sometimes get through all at once.
panda:~# iwconfig wlan0 power on
panda:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=15653 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=14650 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=13642 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=12635 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=11627 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=10620 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=9615 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=8607 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=7600 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=6592 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=5585 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=4577 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=3569 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=2562 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=1554 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=546 ms
64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=16398 ms
64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=15396 ms
64 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=14388 ms
64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=13381 ms
64 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=12373 ms
64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=11365 ms
64 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=10358 ms
64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=9350 ms
64 bytes from 192.168.0.1: icmp_seq=39 ttl=64 time=8343 ms
64 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=7335 ms
64 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=6329 ms
64 bytes from 192.168.0.1: icmp_seq=42 ttl=64 time=5322 ms
64 bytes from 192.168.0.1: icmp_seq=43 ttl=64 time=4317 ms
64 bytes from 192.168.0.1: icmp_seq=44 ttl=64 time=3313 ms
64 bytes from 192.168.0.1: icmp_seq=45 ttl=64 time=2306 ms
64 bytes from 192.168.0.1: icmp_seq=46 ttl=64 time=1300 ms
64 bytes from 192.168.0.1: icmp_seq=47 ttl=64 time=292 ms
^C
ā 192.168.0.1 ping statistics ā
52 packets transmitted, 33 received, 36% packet loss, time 51381ms
rtt min/avg/max/mdev = 292.522/8227.682/16398.270/4795.860 ms, pipe 17
panda:~# iwconfig wlan0 power off
panda:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.95 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=3.14 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1.83 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=2.07 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=2.22 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=1.83 ms
^C
ā 192.168.0.1 ping statistics ā
6 packets transmitted, 6 received, 0% packet loss, time 5009ms
rtt min/avg/max/mdev = 1.830/2.175/3.142/0.457 ms
Iāve switched to another AP because my Turris 1 was unusable. What a shame.
I have exactly the same issue on my Omniaās radio1 (2,4). Not fixed from the beginning. Iām not the only one, a friend of mine has it too. There is something in common here between Turris1/Omnia 2,4 wlan firmware or drivers.
Iām solving this problem in the same way as drstkova. WiFi on Turris 1 is after upgrade unusable.
Is there something what could I do for faster repair?
1 Like
I also experience these issues with my Turris 1.0. Long response over Wifi 2.4 from some devices, sometimes lost packets. Devices getting disconnected. Signal strength is ok.
I am ready to provide more details if someone from Turris team is interested.
Probably fixed with 3.5