Open Bug 1964292 Opened 5 months ago Updated 2 months ago

Firefox fails to fall back to IPv4 on dual-stack websites when IPv6 is blocked by PIA VPN

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Version:
Firefox 138
Type:
defect

Tracking

()

Status:
REOPENED
Milestone:
141 Branch
Tracking Flags:
Tracking Status
firefox141 --- fixed

People

(Reporter: milindhvijay, Assigned: kershaw)

References

(Depends on 1 open bug)

Details

(Keywords: leave-open, Whiteboard: [necko-triaged])

Attachments

(2 files)

Bug 1964292 - Report address as unusable when socket is in transferring state, r=#necko
48 bytes, text/x-phabricator-request
Details | Review
Bug 1964292 - Revert previous change, r=#necko
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0

Steps to reproduce:

  1. Connect to PIA VPN (which blocks IPv6 and only supports IPv4).
  2. Open Firefox and try to visit a dual-stack (IPv6 + IPv4) website.

Actual results:

Firefox fails to connect to dual-stack websites when IPv6 is blocked by the VPN. It does not fall back to IPv4.

Expected results:

Firefox should have detected that the IPv6 connection is unavailable and should have fallen back to IPv4, as Safari and Chrome do under the same network conditions.

Issue has been reported before:

https://support.mozilla.org/az/questions/1437358

https://support.mozilla.org/ha/questions/1439478

The only workaround I found was either disabling IPv6 on my client or set network.dns.disableIPv6 to false.

(In reply to milindhvijay from comment #1)

Issue has been reported before:

https://support.mozilla.org/az/questions/1437358

https://support.mozilla.org/ha/questions/1439478

The only workaround I found was either disabling IPv6 on my client or set network.dns.disableIPv6 to true.

Component: Untriaged → Networking
Product: Firefox → Core

Hi Reporter,

Thanks for reporting this.
Could you try to capture a http log?
In about:logging, please select logging to file and send the file to necko@mozilla.com.

Thanks.

Flags: needinfo?(milindhvijay)

Sent.

Flags: needinfo?(milindhvijay)

This should be fixed when bug 1953459 is completed.

Severity: -- → S3
Depends on: 1953459
Priority: -- → P2
Whiteboard: [necko-triaged]

ETA?

(In reply to Kershaw Chang [:kershaw] from comment #5)

This should be fixed when bug 1953459 is completed.

Is that going to take long? Should I switch to other browser for the time being?

(In reply to milindhvijay from comment #7)

(In reply to Kershaw Chang [:kershaw] from comment #5)

This should be fixed when bug 1953459 is completed.

Is that going to take long? Should I switch to other browser for the time being?

We’re actively working on bug 1953459. In the meantime, you don’t need to switch to another browser.
As a workaround, you can try setting the preference network.dns.disableIPv6 to true in about:config. That should help avoid the issue for now.
We’d really appreciate it if you continue using Firefox, and please let us know if the workaround helps!

(In reply to Kershaw Chang [:kershaw] from comment #8)

(In reply to milindhvijay from comment #7)

(In reply to Kershaw Chang [:kershaw] from comment #5)

This should be fixed when bug 1953459 is completed.

Is that going to take long? Should I switch to other browser for the time being?

We’re actively working on bug 1953459. In the meantime, you don’t need to switch to another browser.
As a workaround, you can try setting the preference network.dns.disableIPv6 to true in about:config. That should help avoid the issue for now.
We’d really appreciate it if you continue using Firefox, and please let us know if the workaround helps!

That is not really a workaround since I am only facing issue when using VPN. At other times, I need IPv6 to work.

(In reply to milindhvijay from comment #9)

(In reply to Kershaw Chang [:kershaw] from comment #8)

(In reply to milindhvijay from comment #7)

(In reply to Kershaw Chang [:kershaw] from comment #5)

This should be fixed when bug 1953459 is completed.

Is that going to take long? Should I switch to other browser for the time being?

We’re actively working on bug 1953459. In the meantime, you don’t need to switch to another browser.
As a workaround, you can try setting the preference network.dns.disableIPv6 to true in about:config. That should help avoid the issue for now.
We’d really appreciate it if you continue using Firefox, and please let us know if the workaround helps!

That is not really a workaround since I am only facing issue when using VPN. At other times, I need IPv6 to work.

I'll try to work on a workaround patch next week.

Flags: needinfo?(kershaw)
Duplicate of this bug: 1961459

(In reply to Kershaw Chang [:kershaw] from comment #10)

(In reply to milindhvijay from comment #9)

(In reply to Kershaw Chang [:kershaw] from comment #8)

(In reply to milindhvijay from comment #7)

(In reply to Kershaw Chang [:kershaw] from comment #5)

This should be fixed when bug 1953459 is completed.

Is that going to take long? Should I switch to other browser for the time being?

We’re actively working on bug 1953459. In the meantime, you don’t need to switch to another browser.
As a workaround, you can try setting the preference network.dns.disableIPv6 to true in about:config. That should help avoid the issue for now.
We’d really appreciate it if you continue using Firefox, and please let us know if the workaround helps!

That is not really a workaround since I am only facing issue when using VPN. At other times, I need IPv6 to work.

I'll try to work on a workaround patch next week.

Any update?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(kershaw)

Hi,

While working on the workaround, I noticed that Firefox may not detect network‐change events when a VPN is active. As a result, Firefox continues to use the cached IPv6 address instead of doing a fresh DNS lookup.

Could you please capture a log again, following these steps:

  1. Start logging and add nsNotifyAddr:5 to the MOZ_LOG environment variable.
  2. Enable the VPN.
  3. Reproduce the issue.
  4. Stop logging.

Thanks.

Flags: needinfo?(milindhvijay)
See Also: → 1969090

(In reply to Kershaw Chang [:kershaw] from comment #13)

Hi,

While working on the workaround, I noticed that Firefox may not detect network‐change events when a VPN is active. As a result, Firefox continues to use the cached IPv6 address instead of doing a fresh DNS lookup.

Could you please capture a log again, following these steps:

  1. Start logging and add nsNotifyAddr:5 to the MOZ_LOG environment variable.
  2. Enable the VPN.
  3. Reproduce the issue.
  4. Stop logging.

Thanks.

Sent via mail.

Flags: needinfo?(milindhvijay)

Thanks for the log. I can confirm that Firefox successfully detected the network change.
From the log, I can see that after the VPN was enabled, the socket was reset during writing:

2025-05-06 18:38:56.685094 UTC - [Parent 11707: Socket Thread]: D/nsSocketTransport nsSocketOutputStream::Write [this=139ce4f80 count=305]
2025-05-06 18:38:56.685097 UTC - [Parent 11707: Socket Thread]: D/nsSocketTransport   calling PR_Write [count=305]
2025-05-06 18:38:56.685113 UTC - [Parent 11707: Socket Thread]: D/nsSocketTransport   PR_Write returned [n=-1]
2025-05-06 18:38:56.685117 UTC - [Parent 11707: Socket Thread]: D/nsSocketTransport ErrorAccordingToNSPR [in=-5961 out=804b0014]
2025-05-06 18:38:56.685121 UTC - [Parent 11707: Socket Thread]: D/nsSocketTransport nsSocketTransport::OnMsgOutputClosed [this=149576800 reason=804b0014]

However, we don't report this IPv6 address unusable because at this point the socket is at transferring state.

2025-05-06 18:38:56.685448 UTC - [Parent 11707: Socket Thread]: D/nsSocketTransport nsSocketTransportService::DetachSocket [handler=149576800]
2025-05-06 18:38:56.685453 UTC - [Parent 11707: Socket Thread]: D/nsSocketTransport nsSocketTransport::OnSocketDetached [this=149576800 cond=80004005]

I think we could loosen this condition slightly and report the address as unusable even when the socket is in the transferring state. This would help avoid repeatedly retrying the same (now unreachable) address. The risk of doing so should be low, since we reset the block list when all addresses are blocked.

Assignee: nobody → kershaw
Status: NEW → ASSIGNED
Pushed by kjang@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/fdb17bc483da https://hg.mozilla.org/integration/autoland/rev/1cde97b72971 Report address as unusable when socket is in transferring state, r=necko-reviewers,valentin

https://hg.mozilla.org/mozilla-central/rev/1cde97b72971

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
status-firefox141: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 141 Branch
QA Whiteboard: [qa-triage-done-c142/b141] [qa-ver-needed-c142/b141]
Flags: qe-verify+
QA Contact: cgeorgiu

Did this make into v141.0?, cuz the issue is not fixed.

(In reply to milindhvijay from comment #19)

Did this make into v141.0?, cuz the issue is not fixed.

Yes, it the patch should be in Fx141.

Hi, kershaw! Can you please take a look at this? I would verify myself but I cannot reproduce the issue.

Flags: needinfo?(kershaw)

(In reply to milindhvijay from comment #19)

Did this make into v141.0?, cuz the issue is not fixed.

Hi, thanks for testing.
Could you try to capture a log again? I'd like to investigate why this is not fixed.

Flags: needinfo?(kershaw) → needinfo?(milindhvijay)

(In reply to Kershaw Chang [:kershaw] from comment #21)

(In reply to milindhvijay from comment #19)

Did this make into v141.0?, cuz the issue is not fixed.

Hi, thanks for testing.
Could you try to capture a log again? I'd like to investigate why this is not fixed.

Emailed.

Flags: needinfo?(milindhvijay)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

This reverts commit fdb17bc483da2f2567387a4a98a397db3581246e.

Note that it's unlikely the previously landed patch (D252289) in this bug caused bug 1980171. However, since it is the most recent change in nsSocketTransport.cpp, I think we should revert it first and see if that resolves bug 1980171.

Keywords: leave-open
See Also: → 1980171

(In reply to Kershaw Chang [:kershaw] from comment #24)

Note that it's unlikely the previously landed patch (D252289) in this bug caused bug 1980171. However, since it is the most recent change in nsSocketTransport.cpp, I think we should revert it first and see if that resolves bug 1980171.

My expectation is that it won't resolve bug 1980171, because the error from bug 1980171 is emitted before the message from this extension.
For example, see this profile, which was captured for a never-seen-before domain (so no caching): https://bugzilla.mozilla.org/show_bug.cgi?id=1980171#c12

Select all tracks (at least parent process and socket thread), and set the "Marker Table" filter to ErrorAccordingToNSPR,Adding address to blocklist for host . It shows that ErrorAccordingToNSPR [in=-5999 out=80004005] comes before Adding address to blocklist for host [coolgoodtranscendentjoke.neverssl.com], host record [3e9dc8c70].used trr=0

(the last error message is emitted by ReportUnusable)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: