I tried the revised kresd with no compression and nothing worked so I reverted back to dnsmasq which is handling both dhcp and dns for me at present.
2 Turris updates and 1 garmin connect later, things started to work without any specificsâŚ
Iâd love to know the reason behind in case it failed again in the near futureâŚ
Hello,
I have problem with connection to Wi-Fi with my Garmin Fenix 3 HR watch.
My watch can connect to any wifi network except Wi-Fi on Turris router.
I have two Turris routers. At home, at my office. Same problem on both Turris routers.
I already try set different channels, all possible Wi-Fi settings, First Wi-Fi card, second Wi-fi card⌠no luck.
No matter how many times I try, the watch times out with a âNetwork error. Try again laterâ message.
Any cheap Wi-Fi router works well with my Garmin watch.
Do you have any advice, what should I try to do?
Thanks
Jan
My Garmin Scale is also affected. I am experiencing no problems when I connect scale over mobile hotspot. But I cannot get it working over Turris.
I can see repeated DNS queries and responses in Wireshark. No communication with Garmin servers start. (exception NTP)
Interesting is that on wireless page in Turris I see Index Scale IP twice. Can that be the root cause?
Unfortunatly, following last night update, the scale is not able to connect to the Wifi anymore.
Other devices can connect to the WIFI thoughâŚ
Where can I look to get an insight of whatâs is (or isnât) happening ?
Hi,
I do have the very same problem:
My Fenix 5X connects to the Turris, gets an IP issued and then times out with âNetwork error. Try again laterâ.
Connecting via my smartphone hotspot works like a charm.
@Bounours: as the last nightâs (aka TurrisOS v.3.8) update included a new Wi-Fi driver it might be worth looking into whatâs changed in detail. Perhaps @cynerd could help here?
Unfortunately I have no idea what is going on. I would suggest to debug what it tries to do with wireshark to see why it fails (for example if it canât resolve some host name or establish some connection). But I have no garmin product at the moment to test it.
Also it seems to me that if you have ip address but canât reach internet then it shouldnât be wifi drivers fault (although I canât rule it out completely).
Thanks for your replies. I donât think the issue was with the driver but more with the resolverâŚ
This morning, the scale was able to connect. I donât if something as changer on the router or if Garmin was the culprit.
Thanks for your help
I had the same issue with an LG washing machine. DHCP logs and tcpdump showed that it was getting an IP address and resolving itâs necessary web service but going no further when using Knot as the DNS server. I resolved this by sending it to the Google DNS servers directly via a dchp config. Then today, I finally switched back to using dnsmasq-full as my DNS and DHCP server ( Iâm sure Knot is great but given that dnsmasq-full supports DNSSEC, it seems that knot is only on the Omnia because Turris wrote it). Guess what? Having the washing machine use the dnsmasq DNS server rather than go external now works fine. Thereâs someting in the DNS responses from Knot that upset a sample of IoT/embedded devices. in my house of 30+ wifi clients, only the washing machine had this issue. I have the packet captures if theyâre going to be useful.
Iâm knot-resolver developer (not Turris) and certainly would be interested in what breaks the devices. On âbig devicesâ the DNS is OK, right? (i.e. itâs not this issue where DNSSEC validation breaks when forwarding to some ISPâs servers?)
I donât have a Garmin device but was just reading through the thread.
It might be worth investigating the resolved IP: they are using Akamai and the Akamai CDN so there could be all sorts of tricks being played with the DNS. The resulting IP from forwarding may be different to full resolution with knot resolver.
gold.garmin.com. is an alias for gold.garmin.com.edgekey.net.
gold.garmin.com.edgekey.net. is an alias for e8867.b.akamaiedge.net.
e8867.b.akamaiedge.net. has IPv4 address 104.127.27.4
1 Like
Looking at the previous thread, I suppose the root cause is the same, and the name compression hasnât been changed in libknot since (so far), so only workarounds are available, e.g. like the one in the following post.
Future libknot-2.6.0 will contain improved name compression. With it the answer to gold.garmin.com. is compressed the same as from 8.8.8.8, so I suppose the problem might be gone after that (but itâs hard to say for devices sensitive to such perfectly legitimate differences).
If you want to send me your email, I can send you the pcaps from my research.
When will this be available for Turris Omnia?
Iâd be happy to test it.
Great. I would expect it to take a few weeks; it seems difficult to estimate (at least from my point of view). Iâll let you know after it happens.
Happy to test with my errant washing machine too when the release is done. No rush since dnsmasq (or the dhcp tag) is working fine.
I just rediscovered to be the owner of another device incapable connecting to www-services when using the TO - a Denon AVR (Denon DRA100). Itâs used to connect to webradio services.
Like the Garmin it optains an IP without problems but trying to access webradio it fails.
The device works great with the wifi of a Fritz!Box 7412 or the hotspot of my smartphone.
Do you know what kind of names it tries to access?