Summary

Since installing 21.0-20241023-nightly, apps on my tablet can no longer access Internet when Wireguard is connected. This worked just fine right up until 20241023-nightly, and Wireguard’s app hasn’t been updated in over a year, so I’m pretty sure it’s the new build.

Looks like it’s DNS. (It’s always DNS.) There are a couple of conspicuously related-looking commits in this build: 406071 (VPN-covered DNS traffic may not fall through) and 406070 (Revert ”Prevent DNS traffic from bypassing lockdown VPNs”).

Expected Behavior

Apps should be able to connect to the Internet even when Wireguard is connected.

Current Behavior

Apps lose access to Internet immediately when Wireguard is connected. Curiously, Chrome is unaffected; all other apps that I’ve tested are affected, including Firefox, which says ”Address not found”, hinting at DNS.

Steps to Reproduce

1. Install Wireguard
2. Set up a connection that doesn’t route all traffic but just that interface’s address space. I’m including a screenshot of my Wireguard configuration below.
3. Toggle the Wireguard interface on.
4. Open Firefox and try to browse the web.

Device information

/codename gts4lvwifi /version 21 /date 2024-10-23 /kernel 4.9.337-g16026dfb9b4c #1 Wed Oct 23 13:53:22 UTC 2024 /baseband none /mods Google Apps

I have read the directions

I’m using the ActivityPub plugin to enable following posts from my WordPress blog. The posts federate as excerpts with a URL pointing to the full post on my site.

Tapping on that URL in the Android app only causes it to reload the post (excerpt) inside the app, instead of opening the URL in either webview or a browser as I’d expect it to.

The (official) IOS app does open the URL a browser, as does Firefox on the desktop, which is why I suspect the Android app being at fault here.

I don’t know of a way to link my blog here it so that it opens in the app (which is a bit ironic), but here’s a deck link to the federated posts on mastodon.social. My personal Mastodon account is on mastodon.social.

Both my Android phone and Android tablet are affected, both are on Mastodon version 2.2.1. The phone is running Android 10 (with Samsung’s One UI 2.0), the tablet is on Android 11 (One UI 3.1).

Below is a screen recording from the Android phone exhibiting the issue: the first tap of the URL opens the federated note in single view, and subsequent taps then just reload that same view.

Issue

JSON files can be added to cards as attachments, but they are empty when downloaded from a card.

Server Setup Information

• Did you test in newest Wekan?: 5.90
• Did you configure root-url correctly so Wekan cards open correctly? yes
• Operating System: Ubuntu 20.04
• Deployment Method: snap
• Http frontend if any: Apache
• What webbrowser version are you using? Firefox (reproducible in Brave too)

Problem description

Reproduction Steps

1. Have a JSON file, such as the example from Wikipedia. Name it example.json.
2. Open a card in Wekan.
3. Select + from the Attachments section.
4. Select ”Computer” from the popup.
5. Select example.json.
6. With the JSON file now attached to the card, select to ”Download” it.
7. Open the downloaded JSON file.

What I expect to happen

For the downloaded file contents to match the uploaded file.

What happens instead

The file is empty.

Logs

Nothing in either the browser console nor snap logs when the issue is triggered.

Other info

• Deleting the attachment seems to work.
• The issue can be worked around by renaming the JSON file prior to uploading to have a .txt extension instead of (or in addition to) .json.

Also, I tested the 94.0a1 nightly now, and the issue is still present.

I ran mozregression like this (twice, to be sure):

MOZ_ENABLE_WAYLAND=1 mozregression --profile /home/jani/.mozilla/firefox/fyaus28k.LP1940417 --bad 91 --good 89 --profile-persistence clone-first

Here’s the result (it was the same for both bisects):

5:25.73 INFO: No more integration revisions, bisection finished.
5:25.73 INFO: Last good revision: 9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8
5:25.73 INFO: First bad revision: 7b82d177a6b979036f180329be6b029d690d9e0c
5:25.73 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8&tochange=7b82d177a6b979036f180329be6b029d690d9e0c

According to that log, this changeset was introduced to address #1661516.

For me this seems to have resolved itself since Ubuntu-distributed Firefox was updated to 84, though for all I know, it may have just coincided with some change implemented at Twitter’s end.