Closed
Bug 1284378
Opened 8 years ago
Closed 7 years ago
Kill all keepalive connections when detected NIC change
Categories
(Core :: Networking, defect, P2)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: timdream, Assigned: bagder)
References
Details
(Keywords: feature, Whiteboard: [necko-triaged])
Attachments
(1 file)
(deleted),
application/x-gzip
|
Details |
For me, the one and only use case (as an user) for "work offline" is to reset the connections when I connect/disconnect VPN. We should not remove that feature before this use case is fulfilled:
STR:
1. Go to some website and find it geoip-blocks me
2. Connect to Mozilla External VPN
3. Reload that website
Expected:
1. Website thinks I am in SJC and I can continue browse it
Actual:
1. When I hit reload, The tab hangs at "Connecting..." and the website can't be reloaded in the instant.
Workaround:
3a. Go to File -> Work offline to turn it on.
3b. Go to File -> Work offline to turn it back off.
3c. Reload the website.
Note:
My other use case (as a developer) is to test AppCache w/o disconnect the Wi-Fi as people often do, but that a separate use case)
Comment 1•8 years ago
|
||
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #0)
> For me, the one and only use case (as an user) for "work offline" is to
> reset the connections when I connect/disconnect VPN. We should not remove
> that feature before this use case is fulfilled:
so this should actually work automatically for you without work offline. bagder did that work and is ni'd here.
can you please attach
1] https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
showing a case where you detach and reload and the new network config is not reflected
2] your Operating System information
thanks
Flags: needinfo?(daniel)
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(timdream)
Reporter | ||
Comment 2•8 years ago
|
||
I've failed to reproduce this bug in the Taipei office and connecting to Mozilla VPN. I don't have a non-Mozilla VPN to simulate what I have encounter at home. Will attempt to reproduce some time later...
Reporter | ||
Comment 3•8 years ago
|
||
This is tested against latest Nightly:
1. Launch Nightly per instruction on MDN
2. Go to hulu.com
-> Websites loads but with a geo-blocked warning.
3. Connect to Mozilla External VPN
4. Hit reload
-> Getting a Connection timeout page
5. Hit reload again
-> Eventually reloads but it takes a lot of time to show the first page.
6. Hit reload again
-> Websites loads but slower, not sure if there is a problem or because of the VPN latency.
(I had to gzip the files first because the raw file size exceeds Bugzilla file size limit)
Flags: needinfo?(timdream)
Updated•8 years ago
|
Assignee: nobody → daniel
Flags: needinfo?(daniel)
Whiteboard: [necko-active]
Reporter | ||
Comment 4•8 years ago
|
||
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #3)
> 6. Hit reload again
> -> Websites loads but slower, not sure if there is a problem or because of
> the VPN latency.
I might have flipped the "Work offline" menu before this reload. Nonetheless, the problem happens at step 4 and 5 so the log is still valid.
Assignee | ||
Updated•8 years ago
|
Comment 5•7 years ago
|
||
Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Comment 6•7 years ago
|
||
I expect this will move to P2 (ie not 57), but if there's a chance this is simple fix it's conceivable it could get uplifted. Worth having a quick look?
Flags: needinfo?(daniel)
Whiteboard: [necko-active]
Updated•7 years ago
|
Priority: P1 → P2
Whiteboard: [necko-triaged]
Assignee | ||
Comment 7•7 years ago
|
||
I figure this bug can still be triggered? I'm curious on details on step "2. Connect to Mozilla External VPN". Did you already have the VPN/network interface up before you connected there or did you setup the interface as part of step 2 while Firefox was running?
Also, can you switch on network logging for the "nsNotifyAddr" component as well as the others, as that's the one that'll tell if it detects a network change or not and that's a very useful clue here. I'm puzzled by the lack of network change related log output (like for example there's no "PruneNoTraffic" long entries). It could indicate that Firefox doesn't see any "network change" and that could explain things a bit.
Flags: needinfo?(daniel) → needinfo?(timdream)
Reporter | ||
Comment 8•7 years ago
|
||
(In reply to Daniel Stenberg [:bagder] from comment #7)
> I figure this bug can still be triggered? I'm curious on details on step "2.
> Connect to Mozilla External VPN". Did you already have the VPN/network
> interface up before you connected there or did you setup the interface as
> part of step 2 while Firefox was running?
I already have Tunnelblink running. I simply start the connection at this step.
> Also, can you switch on network logging for the "nsNotifyAddr" component as
> well as the others, as that's the one that'll tell if it detects a network
> change or not and that's a very useful clue here. I'm puzzled by the lack of
> network change related log output (like for example there's no
> "PruneNoTraffic" long entries). It could indicate that Firefox doesn't see
> any "network change" and that could explain things a bit.
I've try to produce the log again but unfortunately Mozilla VPN seens to have some problem today (Tunnelblink complains there are no outbound connection). Keeping ni and maybe I will test this out soon after a reboot.
Reporter | ||
Comment 9•7 years ago
|
||
I've tested on the latest Nightly and it works, though the first reload took some time.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(timdream)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•