nsINetworkLinkService.isLinkUp returns true when no network connection is available
Categories
(Core :: Networking, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | verified |
People
(Reporter: michal, Assigned: michal)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(3 files)
IP addresses when no network is usable
Reported at https://github.com/mozilla-mobile/fenix/issues/6356
nsINetworkLinkService.isLinkUp is true when there is at least one link that's up and running, it's not a loopback device and has an address with a global scope. This works in most cases, but there are some Android versions which have a link that always matches this criteria regardless of the status of mobile or wifi network. We correctly detect that the network is unusable when we calculate network ID, because we cannot find a route to host defined by preference network.netlink.route.check.IPv4/6. But given that we want to have separate events for network change and network ID change, we probably don't want nsINetworkLinkService.isLinkUp to depend on network ID. We would easily end up sending network change events when nsINetworkLinkService.isLinkUp is false.
|
Assignee | |
Comment 1•6 years ago
|
||
|
|
Assignee | |
Comment 2•6 years ago
|
||
|
|
Assignee | |
Comment 3•6 years ago
|
||
The two attached images show that status of rmnet1 is always the same regardless of the status of rmnet0 and wlan0 device.
|
|
Assignee | |
Comment 4•6 years ago
|
||
Determining link status from states and addresses of the individual interfaces isn't always reliable. With this patch we assume the link is up when we could find a route for kRouteCheckIPv4 host or kRouteCheckIPv6 host.
|
|
Assignee | |
Comment 5•6 years ago
|
||
I didn't find better way how to find out that devices like rmnet1 mentioned above are not really usable for outgoing traffic. So nsINetworkLinkService.isLinkUp now depends on the result of the route checking. Given that the checking is now needed for basic functionality, IP addresses used for route checking are now hardcoded because there is reason to allow to change them using preferences.
|
||
Updated•6 years ago
|
|
||
Comment 7•6 years ago
|
||
Backed out changeset 755655b3175a (bug 1593693)for causing NetlinkService.cpp build bustages
push that caused the backout: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&selectedJob=275075180&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=755655b3175a22df8ca3938a8c881ecfcb865f5a
backout: https://hg.mozilla.org/integration/autoland/rev/9b7a7c11aa20e95b3e3c198d012a5e3ca0c69777
|
|
Assignee | |
Comment 8•6 years ago
|
||
I left an excessive comma in LOG statement when I changed the comment. It did compile successfully locally :-/
|
||
Comment 10•6 years ago
|
||
| bugherder | ||
|
||
Comment 11•6 years ago
|
||
Hi, verified as fixed on app build Firefox Preview Nightly 191120 (Build #13240608) and Gecko View 72.0a1-20191118093852 with Samsung Galaxy S9 (Android 8.0.0) and Google Pixel 3a (Android 9)
Scenarios checked:
-disable/enable wi-fi -> the "Link is up" data is updated correctly based on the state of the network
-have wi-fi enabled and restart device - the "Link is up" data is updated correctly based on the state of the network
-disable/enable mobile data - the "Link is up" data is updated correctly based on the state of the network
-have mobile data enabled and restart device - the "Link is up" data is updated correctly based on the state of the network
-have both Wi-fi and mobile data enabled and restart device - the "Link is up" data is updated correctly based on the state of the network
I will mark this ticket as verified-fixed.
Description
•