Loading forever when using Wireguard in poor network connectivity condition
Categories
(Core :: Networking, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox76 | --- | wontfix |
People
(Reporter: xcffl, Unassigned)
Details
Steps to reproduce
-
Use a Wireguard VPN with
AllowedIPs = 0.0.0.0/0(bascially means all traffic except from wireguard to the VPN server), on a computer where UDP packages are randomly dropped -
wg-quick up wg0 -
Use firefox to browse 1.1.1.1, AMO, DuckDuckGo, Google, and Youtube
-
Wait for seconds respectively, before refreshing all the pages.
-
Use about:network to resolve those domain manually.
Actual results
DuckDuckGo and 1.1.1.1 are loaded very fast. AMO, Google, and Youtube wait for a response for 10s+ but nothing happens.
After refreshed, more resources may be loaded on those who haven't.
Inspecting the network dashboard, it shows the first resource on each site (before refreshing) was "block"-ed for several seconds, and they also spends several seconds on DNS resolving. The following resources don't have that (probably since it's counted on the first one).
When resolving those domain manually in about:network, they are resolved very fast.
The network speed under WireGuard is 35M, tested on fast.com
Expected results
All websites should be loaded as fast as when Wireguard is off.
The network log is here: https://dislash.keybase.pub/log.txt-main.22877.moz_log
More likely it's just the timeout of DNS queries is too long. Chrome appears have a threshold and behave more like normally.
|
||
Updated•6 years ago
|
|
||
Comment 2•6 years ago
|
||
Could you try to see if it's a problem of DoH by disabling it manually?
https://support.mozilla.org/en-US/kb/firefox-dns-over-https#w_manually-enabling-and-disabling-dns-over-https
|
||
Comment 3•6 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Comment 4•6 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Comment 5•6 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Comment 6•6 years ago
|
||
The severity of these bugs was changed, mistakenly, from normal to S3.
Because these bugs have a priority of --, indicating that they have not been previously triaged, these bugs should be changed to Severity of --.
(In reply to Junior [:junior] from comment #2)
Could you try to see if it's a problem of DoH by disabling it manually?
https://support.mozilla.org/en-US/kb/firefox-dns-over-https#w_manually-enabling-and-disabling-dns-over-https
No, it persists even if DoH is disabled. But I think it's more a problem that WG is actively being blocked. It may not be valuable to improve Firefox's handling in this case.
|
||
Updated•6 years ago
|
Description
•