Category: Linux

TeamViewer (sometimes) doesn’t work with DNSSEC enabled

Update (2022-12-06): It looks like TeamViewer fixed their DNS config (before and after).

Update (2022-11-12): I tested again after Frankie in the comments noted that it works on his machine, and indeed it does for me, too, even with DNSSEC turned back on. My only explanation is that it’s an intermittent issue.

I couldn’t figure out why TeamViewer was perpetually stuck in the ‘Not ready. Please check your connection’ state, and the help article didn’t give any clues (port 5938 was already open for outbound connections).

The dreaded ‘Not ready. Please check your connection’

The log files (/opt/teamviewer/logfiles/TeamViewer15_Logfile.log in Fedora) gave a hint:

The host would cycle from router1.teamviewer.com to router16.teamviewer.com, but none of them would resolve. Long story short, DNSSEC is broken for these TeamViewer domains, and the application won’t work if none of them can be reached.

Sadly, this problem was reported years ago but nothing has changed.

Workarounds

Neither of these is good! I recommend contacting TeamViewer and letting them know about this issue (particularly if you’re a paying customer).

Hard code an IP address in hosts

Adding an IP address for router1.teamviewer.com to hosts seems to make the application functional.

I just picked the first IPv4 address and added it to /etc/hosts:

These IP addresses are of course liable to change.

Disable DNSSEC

Note: DNSSEC exists for a reason – don’t disable it unless absolutely necessary.

The nuclear option is to turn off DNSSEC checks entirely, or switch to using DNS servers that don’t support it in the first place (I recommend neither).

On Fedora 36 with systemd-resolved, this means editing /etc/systemd/resolved.conf and adding DNSSEC=no under [Resolve].

WebRender in Firefox 83 in Fedora 33 (KDE 5.20, X11)

I wanted to test out WebRender in Firefox now that it’s on the brink of being turned on by default in GNOME environments. Despite enabling gfx.webrender.all, about:support showed that WebRender wasn’t working and reported errors including Failed to load EGL library: FEATURE_FAILURE_EGL_LOAD_3 and Failed GL context creation for WebRender.

Fixing this in my environment (Fedora 33, KDE Plasma 5.20, X11, AMD Mesa) came down to simply installing libglvnd-gles.

I’m not sure if this is required for other hardware configurations or desktop environments or under Wayland. I like trying out the latter with each KDE Plasma release, but while things seem to be getting better, the number of crashes still makes it feel very far from being ready for prime time.

VA-API hardware video acceleration

A significant advantage of WebRender is that it enables support for VA-API hardware video acceleration. Just set flags media.ffmpeg.vaapi.enabled to true, media.ffvpx.enabled to false and environment variable MOZ_X11_EGL to 1 to give your CPU a nice rest.

In related news, I’m excited to see progress on this long-standing bug that should mean VLC’s VA-API option actually works under AMD Mesa. (Update: Mesa 20.3.2 is available for testing, and it’s working well.)

Ubuntu 16.04: heirloom-mailx is replaced by s-nail

As of Ubuntu 16.04, the heirloom-mailx package is a transitional package for s-nail.
Not realising this, I was having trouble with mailx not recognising the /etc/nail.rc file I’d copied from a working Ubuntu 15.10 server. As it turns out, the global config file path for s-nail is /etc/s-nail.rc. I found this out quickly by using strings to find the text '.rc' in the mailx binary: strings /usr/bin/mailx | grep '\.rc' (thanks to jpollard for this tip).