Close to give up on my Omnias :(

Software SW bugs discussion
1

First of all, let me say thanks for this project. I love the idea, motivation and dedication.

However, it might just not be for me as I just can’t get many things to work. I bought four Omnias from Amazon and I only have a few days left to possibly return them. I tried everything I could find on the forum running anything from stable to night builds.

Assembly wasn’t stellar. I had to open up and fix things in three out of four devices (LED button stuck in case, LEDs misaligned on the case front, etc. Nothing big, my issues are really the software side.

1.) 5Ghz Wifi is still unstable. Android devices often disconnect claiming “no internet”. This has become worse since Turris 3.6 release. Some posts say it’s the driver, for some the 5ghz card doesn’t even reliability appear in PCI after reboot. For me the card appears, but Android clients keep dropping off. I tried all channels, different channel widths, power settings, country settings, antennas, router locations. No fix. I could try a better Wifi module like the R11e-5HacT, but I’m sort of running out of time and really would like to get the hardware I bought to work.

2.) [Fixed] DNSSEC was always reported as working fine in Foris connection check before 3.6. Now it’s red with forwarding and green without. On the other hand, https://www.dnssec.cz/ always displays green, but other test sites don’t agree. I’m lost here, as I know too little about DNSSEC. From what I found on Google it should work with my provider (Deutsche Telekom VDSL).

3.) Disabling forwarding makes DNS super slow. I guess I understand why that it is and that’s probably by design. But could it cache resolved entries longer then?

4.) Updater.sh usually worked fine when running in console, but never when scheduled. I always got the famous /tmp/crl.pem missing errors. I understand that this may just mean WAN connection not available and this should be reported differently in recent builds, but that’s not true. I setup continuous connection tests and there wasn’t even a single glitch when the updater runs and fails. One time I caught it on the console also failing to resolve api.turris.cz. Also, sort of well-known and reported on the forum. I think this actually has something to do with DNS not reliably working. Since 3.6 I’m not getting any messages in Foris regarding updates. Neither failed nor positive ones.

5.) The dhcp-sequential-ip option of dnsmasq somehow doesn’t work. The option in LUCI doesn’t work as the setting is never transformed to /var/etc/dnsmasq.conf. But also, when putting it directly in /etc/dnsmasq.conf (included from /var/etc/dnsmasq.conf) it simply doesn’t work.

6.) [Fixed] Tiny, but LED brightness is always lost after reboot. I usually run it at the lowest setting. The “brightness step” is remembered after reboot, but not the brightness itself. So, I get max brightness after reboot, but after one push of the button LEDs turn completely off.

About my configuration:
• I disabled IPv6 as described on How can I disable IPV6 as my ISP doesn’t provide it. I also set option net_ipv6 ‘0’.

• I configured forwarding to dnsmasq as described on Dnsmasq .lan domain while still using knot resolver as I really need dhcp hostnames to resolve. Also, I think this really should work by default.

• I’m running the Turris behind a TPLINK Archer VR200v. I have the turris configured as DMZ host on the VR200v, so everything is forwarded to it. This also appears to work, even with dynamic upnp mappings on the Turris.

I wouldn’t mind providing remoter access and paying someone to at least look into the issues. I’d hate to send the Omnias back, but I also can’t have 1360 EUR of unstable devices lying around.

Thanks and best regards

1 Like
2

This seems contradictory, as DTAG actually offers a pretty decent IPv6 support on the residential VDSL lines.

Is the VR200v running stock firmware or openwrt/lede? If stock firmware you might have more luck with lede (if the vdsl modem part is supported). I would not trust a typical home routers DMZ implementation to do the right thing. As far as I can tell there is no guarantee that the tp-link’s NAT does not re-map ports even if only connected to a single host (your omnia), You might have less interferece, if you use the tp-link in vdls bridge mode (assuming that router supports such a mode) and have the omnia run the PPPoE client, that way IPv6 might simply start to work with out much magic…

Best Regards

3
  1. I have also lowest setting, after restart they are bright, but after some time they goes down to the saved setting. Automatically, I would gues rainbow script check runned by cron
  • DNS: try to revert any changes, related forwarding to dnsmasq, and just use lovercase letters to name hosts (Static leases). It works out of box for me (maybe it will/is fixed by newer kresd, but anyway, it does trick to me and I dont care about case sensitivness)

Cant help with non-forwarding DNS, as I am using forwarding, disabled DNSSEC, and still got green flag as ISP does it for me.

Also 5GHz cant comment, I throw away 5Ghz card, diplexers, and running clean 2.4GHz at home

4

It’s actually Congstar. I’m unsure If they offer IPv6, even though technically it should just be DTAG VDSL. At least the VR200v doesn’t get an additional IPv6 address.

OpenWRT support is rather poor for the VR200v so I kept it on stock for now. I did some tests and forwarding actually seems to work fine.

I wouldn’t mind buying a dedicated VDSL modem if there would be any good choices. I looked at the DrayTek Vigor130, but then again people in this forum are having issues with it and IPv6. I would buy it if someone could confirm that it is actually doing well with the OT and DTAG.

I solved issues 2&3. It was apparently caused by setting the VR200v also as DNS on the WAN config tab in Foris. I made that change recently in a shotgun debugging attempt and thought it didn’t change anything. I’m not sure how this can have an effect with forwading disabled, but the super slow DNS lookups are gone and DNSSEC check is positive again with forwarding enabled. So entirely my bad, sorry for the noise.

Still the flanky 5Ghz Wifi is driving me nuts and might be the one reason I’ll send them back. It’s quite some extra money for another Wifi board, cables and antennas. And all of that x4.

Thanks and best regards

5

Ok, guess I can live with that. I hope at one time I don’t have to reboot the device mutiple times a day. Show stopper really is the flaky 5Ghz Wifi.

6

Ah, fair point. I have no personal experience with congstar VDSL lines and I see to recall a discussion, that congstar will re-sell non-DTAG lines as well. So I guess you were right in the no IPv6 observation, sorry.

I was under the impression, that if one used a VDSL-modem/router in bridge mode all it will do is convert ethernet to VDSL2-PTM and vice versa, so it seems quite contrary to expectations that IPv6 issues should show up. I have hard a number of users relatively happy with bridged Vigor130 in regards to functionality. There are general complaints that lantiq/intel based modems do not work that smoothly with the usual (for DTAG at least) broadcom based vectoring linecards. But as far as I can see that issue only affects some users (some only notice that lantiq devices achieve lower sync than broadcom ones), but I digress. So for telekom-branded DTAG vdsl2 lines the vigor 130 seems to work decently, no idea about congstar lines (but if those are re-labeled DTAG lines it should work; but I realize you would want to hear that from someone actually using a vigor 130 on a congstar line, which I can not offer).

Sure wlan issues can be nerve wrecking my sympathy (my own omnia works fine, but I operate it only as secondary router and hence have 2x5Ghz and 2X2.4GHz SSIDs available and simply switch networks if problems occur (and, knock on wood, so far all issues proofed to be temporary only).

7

Just did some more testing with the 2.4Ghz and it’s basically the same if not worse. Is there anything particular stupid I’m doing?

/etc/config/wireless

config wifi-device 'radio0'                                                               
        option type 'mac80211'                                                            
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'        
        option country 'CZ'                                                               
        option disabled '0'                                                               
        option hwmode '11a'                                                               
        option htmode 'VHT80'                                                             
        option channel 'auto'                                                             
        option txpower '20'                                                               
                                                                                          
config wifi-iface                                                                         
        option device 'radio0'                                                            
        option network 'lan'                                                              
        option mode 'ap'                                                                  
        option key 'key'   
        option ssid 'ssid'                                                                   
        option disabled '0'                                                               
        option encryption 'psk2+ccmp'                                                     
                                                                                          
config wifi-device 'radio1'                                                               
        option type 'mac80211'                                                            
        option country 'CZ'                                                               
        option hwmode '11g'                                                               
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'        
        option txpower '19'                                                               
        option channel '13'                                                               
        option htmode 'HT20'                                                              
                                                                                          
config wifi-iface                                                                         
        option device 'radio1'                                                            
        option network 'lan'                                                              
        option mode 'ap'                                                                  
        option ssid 'ssid'                                                          
        option key 'key'   
        option encryption 'psk2+ccmp'

What is correct max txpower value for those cards? Seems LUCI can’t decide and randomly allows me to put 20, 23, or 27.

8

@hdo: you might have a look at:

Yes, it’s not cheap but it is rock solid and has a super wifi performance on both wifi modules. I am using this configuration since November 2016 with quite a few (about 25) IoT, iOS, Android and Windows devices connected per wifi. Also, a workstation and a Sonos sound system are connected per LAN. I never had a signal drop out, connectivity issues or similar instabilities.

1 Like
9

Yes, I already looked at your setup on Amazon before buying. I might actually just replicate that. I can find the cards for reasonable prices, but the antennas are a bit sickening (given that I’d need 2x the 4x pack). Is there anyplace I can buy 5 of these?

Does the the R11e-5HacT support 160Mhz wide or 80+80Mhz channels?

10

If it is configured to run as a pure modem, how could it have issues with IPv6? I ordered and received an Allnet ALL-BM100VDSL2 to be used with my future DTAG line. But I can only report in six weeks or so. I expect it to work flawlessly.

11

It could also be the clients themselves. Several people have remarked that their clients were the culprit. Try turning off every client device but one, and see? For me the 5 GHz works for my android mobile phone. You could try to put the 2.4 GHz and 5 GHz on differently named SSID? Try and work with just 802.11n and no 802.11ac?

12

Ok, made some progress isolating this. I use cron to wifi down in the night and wifi (up) in the morning and this seems to be at least a big part of the problem.

In the morning I’m never able to get internet connectivity on the 5 Ghz card unless I connect first to the 2.4 Ghz card. Then on the next connect the 5Ghz wifi works and is no longer reported as having “no internet” on all my devices. To me this sounds like some route/dhcp/dns issues then. I haven’t found a good way to diagnose this from my Android devices. Any hints appreciated.

13

Was considering that modem as well. I now figured my Archer VR200v actually can be configured in pure bridge pppoe mode and that’s what I’m using now. I have to say TP-Link support is excellent. It’s a long time I just called a free hotline and immediately got a very competent person answering all my questions in seconds.

14

So, I finally had some time to look into the wifi issues, I solved pretty much anything else. When a disconnect on the 5Ghz happens I get

hostapd[]: wlan0: STA xxx IEEE 802.11: disconnected due to excessive missing ACKs

I found some other threads here, but hardly a solution. Basically that means today this still is on open issue and people facing this basically have no choice but to get another Wifi card that actually works?

15

try:
echo 0 >/sys/kernel/debug/ieee80211/phy0/ath9k/ani

reference
https://dev.openwrt.org/ticket/12372

16

Does this apply to ath10k as well? I only have /sys/kernel/debug/ieee80211/phy0/ath10k/ani_enable

17

try:
echo 0 /sys/kernel/debug/ieee80211/phy0/ath10k/ani_enable

18

I have the same error
IEEE 802.1 1: disconnected due to excessive missing ACKs
on both wlan0 and wlan1 cards from various connected clients.

I took the router to cz.nic and they tested it for one day and returned it with comments that “they couldn’t reproduce the issue and that the cards were running smoothly for them” …

I have Omnia on the same place where I had Asus RT-N66 router which run without any issue - so I don’t think there can be an interference from other equipment. As I’m not wifi expert I don’t know what else should I check / change. So far I don’t know what the error even means.

19

Those problems with devices disconnecting due to missing ack’s are also happening on LEDE and, most likely, also on OpenWRT. They also tend to happen more with a certain fruity manufacturer of devices. What @maurer recommended seems to help some people. Although, with bleeding edge LEDE, it doesn’t seem tot happen. Still, it will take some time for it to trickle down to turris-os.

20

I was thinking what was different when I took TO to cz.nic - I changed password to a weaker one. I tried to setup another wifi network with that weaker password - I connected my phone to that test network and it looked promising for a while but then my phone disconnected and connected to the other wifi network on the same card. What was interesting was that the phone stopped seeing the test network while it was connected on first one (the same radio and antennas … )

As I was watching logs and wireless tab I noticed some clients appearing and disappearing (with relatively strong signal) When I checked the logs I could see that phone of my wife connected and disconnected within 7 secs due to inactivity. 7 seconds is really a short period of time - any idea why it could happen?

2017-03-20T22:28:40+01:00 omnia daemon info hostapd[]: wlan1: STA xxx IEEE 802.11: authenticated
2017-03-20T22:28:40+01:00 omnia daemon info hostapd[]: wlan1: STA xxx IEEE 802.11: associated (aid 3)
2017-03-20T22:28:40+01:00 omnia daemon info hostapd[]: wlan1: STA xxx RADIUS: starting accounting session 72176B96C90FE253
2017-03-20T22:28:40+01:00 omnia daemon info hostapd[]: wlan1: STA xxx WPA: pairwise key handshake completed (RSN)
2017-03-20T22:28:44+01:00 omnia daemon info hostapd[]: wlan1: STA xxx WPA: group key handshake completed (RSN)
2017-03-20T22:28:46+01:00 omnia daemon info hostapd[]: wlan1: STA xxx IEEE 802.11: disassociated
2017-03-20T22:28:47+01:00 omnia daemon info hostapd[]: wlan1: STA xxx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)