Firefox Nightly (143a) intermittently drops internet access
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: donjfarnham, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:141.0) Gecko/20100101 Firefox/141.0
Steps to reproduce:
Use Firefox Nightly. Unfortunately not consistent behaviour, but using a couple of webcams, or reels on Facebook more likely cause the issue, but not consistently
Actual results:
WiFi Adaptor stops working, and needs to be disabled/enabled in Device Manager
Expected results:
Adaptor keeps working
|
Reporter | |
Comment 1•3 months ago
|
||
This issue does not occur in Firefox 141.
|
||
Comment 2•3 months ago
|
||
Are other browsers working when this happens? Moving to Networking for debugging.
|
|
Reporter | |
Comment 3•3 months ago
|
||
Doesn't matter whether other browsers are working when this happens, as long as Nightly is running, it will happen.
|
||
Comment 4•3 months ago
|
||
Hi Reporter,
Could you try opening about:config and setting network.http.http3.max_gso_segments to 1? Then see if you can still reproduce the issue.
Thanks.
|
|
Reporter | |
Comment 5•3 months ago
|
||
I have amended about:config as suggested, and so far (nearly 2 days) it seems more stable - no drop outs yet - although it does seem a little slower in obtaining info from websites, but that may be my imagination.
|
|
||
Comment 6•3 months ago
|
||
Thanks for testing.
I think we can close this as a duplicate.
Thank you Don for reporting and testing. This is very helpful.
Thank you Kershaw for linking these issues.
In case you are willing to test some more, could you try out the following:
- install git
- install a Rust toolchain
- checkout https://github.com/quinn-rs/quinn/
cd quinn-udpcargo test- post the output here
Some background. We are using quinn-udp for UDP IO. This seems to be related to a recent optimization we introduced, namely sending multiple UDP datagrams at once. The above cargo test tests the new feature in isolation on your system. You can find more details in https://bugzilla.mozilla.org/show_bug.cgi?id=1979279.
|
|
Reporter | |
Updated•3 months ago
|
@Don let me know if there is any way I can help you help us, e.g. with the above attempt to reproduce. More information about your setup (e.g. CPU, network card, OS version, network driver version) would be helpful as well.
I tried to reproduce this bug on 6 Windows machines (both x86-64 and ARM) without success. In addition, we don't have any other reports of network drivers crashing.
|
|
Reporter | |
Comment 9•3 months ago
|
||
CPU - AMD Ryzen 5 3600
Motherboard - Micros-Star X570-A PRO
Network Adaptor - TP-LINK TXE70UH(EU) V1 - doesn't matter whether on 2.5, 5 or 6ghz.
OS Version Windows 11 PRO Insider Preview
Network Driver version 5001.19.102.1
Hope this helps, but let me know if you need more.
|
||
Comment 10•2 months ago
|
||
Thank you Don.
After the crash, are you able to find any logs? E.g. in the Windows network event logs?
Network Driver version 5001.19.102.1
There seem to be newer versions of this driver available. In case you are able to update, would you mind testing with a newer version once more?
|
|
Reporter | |
Comment 11•2 months ago
|
||
Hi Max,
The logs I saw in Event Viewer were WLAN-AutoConfig (event 10002) :-
WLAN Extensibility Module has stopped.
Module Path: C:\WINDOWS\system32\Rtlihvs.dll
I did re-install that .dll, but it made no difference.
Then after that, I sometimes got DNS Client Events (Event 1014)
Name resolution for the name device.auth.xboxlive.com timed out after none of the configured DNS servers responded.
The name changed each time.
As for the driver, that is the latest TP-Link driver for the adapter I am using - TXE70UH(EU) V1.
Hope this helps.
Description
•