Garmin products unable to use Wifi despite IP address attributed

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?

How can I capture these names? Unfortunately majordomo seems to be getting no traffic at all…

Edit: majordomo needed more time to record it:


What I actually do not know - as the webradio-stations do have different names there might be more names if i tried to access other radio-stations (but this is quite annoying as the AVR freezes as soon as you insert a not working webradiostation…)

1 Like

tmo-datum.metricowireless.com would be affected by that “fix” in libknot >= 2.6.0 (released upstream already but not in Turris yet). As always, I see no way to be certain that a device will be fixed by it until it’s tried. In the meantime you can work around by various other ways, e.g.
Yamaha receiver problem with Knot DNS

With the google-DNS-workaround it works - for both the Denon AVR and the Garmin Watch.

1 Like

The upcoming release (Turris 3.9) contains the workaround in libknot, so we expect that these smart-device problems should just disappear without needing any configuration workarounds. 3.9 RC announcement.

I can confirm my Garmin Fenix 5X and the Denon DRA-100 after updating to TO v.3.9 work without the google DNS-workaround.