Link preview fetches prefer ipv6, not failing over to ipv4

[declanmalone]

• [X] I have searched open and closed issues for duplicates
• [X] I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

---

Bug Description

After updating to 6.23.0 production of signal-desktop, the preview feature no longer works on some URLs that I want to share. The preview box briefly appears and then disappears again for those URLs.

Steps to Reproduce

1. copy and paste a YouTube video URL into Signal
2. wait for preview

Actual Result:

Preview panel pops up briefly but then disappears

Expected Result:

Expect preview box to show thumbnail image and brief text for the video.

Screenshots

Platform Info

Signal Version:

Operating System:

Linux/Devuan (like Debian v11.1)

Linked Device Version:

Signal for Android, version 6.24.4

Link to Debug Log

Warn/info messages appear in debug log:

WARN  [...] fetchLinkPreviewMetadata: failed to fetch link preview HTML; bailing
INFO  [...] addLinkPreview: failed to load preview (not necessarily a problem)

[trevor-signal]

@declanmalone does this happen for every youtube video? What about other link previews? Is it possible your network setup is interfering somehow?

[declanmalone]

@trevor-signal :

Yes, it seems to happen for every youtube video. The same thing happens with other sites, too, eg https://www.nytimes.com/, https://npr.org/, https://www.irishtimes.com/. A lot of other sites do work, though.

I don't think that my network setup is at fault. I do have DNS-based blocking of some ad/tracker-serving sites, but I haven't updated that list recently and it's only after updating signal that the problem started. Besides, I can browse the affected sites with no problem at all.

[trevor-signal]

@declanmalone can you share more of your debug log? I'd expect to see a warning indicating why the fetch failed

[declanmalone]

I went into signal-desktop, triggered the buggy behaviour a few times (by pasting an URL and adding '&t=' followed by some random characters) and then did View -> Debug Log and hit 'Share' within that screen:

https://debuglogs.org/desktop/6.23.0/e93f52182635d54aaa1fd78125a34d71a11370d547329296e23ef546579425b0.gz

[scottnonnenberg-signal]

@declanmalone One thing to keep in mind is that we're making requests directly to those sites, just like you would, with one change: user agent. Perhaps there's some user-agent analysis being used by those sites to try to prevent bots, and that's targeting you for some reason?

You can see the user agent Desktop is using when fetching link previews here: https://github.com/signalapp/Signal-Desktop/blob/3bafe5d82233ea5a6011fe332932930ffeb01670/ts/linkPreviews/linkPreviewFetch.ts#L20

[declanmalone]

Solved. So, I said that I didn't think that my network setup was responsible, but it turns out that it was.

I had a spurious ipv6 route appear on my network after a power-out/reboot. The advertised route was not actually valid, so any attempts to connect over it would fail.

It appears that Signal prefers to use ipv6 addresses if available when doing the previews, so it appears that if any site is dual-hosted (ipv4 and ipv6), then previews don't work for it.

My web browser, by way of comparison, seems to either default to ipv4 or falls back on it if it can't connect to the ipv6 address.

[wzrdtales]

we experience this too with our own website

https://wizardtales.com

seems to be related to IPv6. the system route is fine, using curl on it just works