1921382 - Firefox unable to reconnect to WebSocket connection after network change (e.g. turn on VPN)

Status: RESOLVED FIXED

(Core :: Networking, defect, P2)

Description

[Matthieu Foucault]

Attachment: log-linear-websocket-issue.txt-main.72647.moz_log

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0

Steps to reproduce:

In troubleshooting mode, with a tab open on a site that uses a Websocket connection (in this case, https://linear.app), I changed networks by connecting to a VPN (NordLayer).

Actual results:

The following errors occurred (with the time of the logs in the console):

• 1:10:16.201 UTC: An HTTPS request fails because of CORS
• 1:10:19.337 UTC: the connection to the WebSocket was interrupted
• 1:10.19.713 UTC: Subsequent attempts to reconnect to the WebSocket fail, retrying with an exponential backoff

This problem requires a restart of the browser to be fixed.

Expected results:

Either no requests should fail, or the subsequent attempts to reconnect to the WebSocket should succeed

Comment 1

[Matthieu Foucault]

Attachment: console logs screenshot

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Kershaw Chang [:kershaw]]

Thanks for reporting this and providing the log.
The log shows that after network change, the DNSFlag of new connection attempts have RESOLVE_DISABLE_IPV4 set.

2024-09-27 01:10:20.764012 UTC - [Parent 72647: Socket Thread]: V/nsHttp Creating DnsAndConnectSocket [this=7d5a10cbdac0 trans=7d59f728ed00 ent=sync.linear.app key=.S........[tlsflags0x00000000]sync.linear.app:443^partitionKey=%28https%2Clinear.app%29]
2024-09-27 01:10:20.764021 UTC - [Parent 72647: Socket Thread]: V/nsHttp DnsAndConnectSocket::SetupDnsFlags [this=7d5a10cbdac0] 
2024-09-27 01:10:20.764029 UTC - [Parent 72647: Socket Thread]: V/nsHttp DnsAndConnectSocket::SetupDnsFlags flags=8320 flagsBackup=8320 [this=7d5a10cbdac0]

So, the socket is always trying to connect with IPV6 address.
Maybe this is the reason why the WebSocket connection failed.

Reporter, after VPN is connected, could you try to do shift reload (Ctrl + Shift + R) and see if it works?
If not, could you try to capture a http log again?
Thanks.

Comment 4

[Matthieu Foucault]

Attachment: Logs with Shift Refresh

Comment 5

[Matthieu Foucault]

I have attached a google drive link to the new log file, which is larger than the 10MB limit. Ctrl + Shift + R does not solve the issue.

https://drive.google.com/file/d/1dxNZ_qA8T2dWdN_3z4IlNMmxKc8AfA2R/view?usp=sharing

Comment 6

[Kershaw Chang [:kershaw]]

Could you try to download the linux build from this try push and test again?
If it still doesn’t work, a log would be appreciated.

Thanks.

Comment 7

[Matthieu Foucault]

The linux build linked above fixes the issue, thanks!

Any idea of the release timeline?

Comment 8

[Kershaw Chang [:kershaw]]

Attachment: Bug 1921382 - Call ResetIPFamilyPreference after network change, r=#necko

The problem of this bug is that after network change, a connection entry that prefers IPv6 is always trying IPv6 address.
It's possible that after network change, IP preference is changed, so we should reset it after network change.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/42b8b048a355
Call ResetIPFamilyPreference after network change, r=necko-reviewers,valentin

Comment 10

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/42b8b048a355