NSS needed it for getting VpnInfo[], NetworkState[] and
activeLinkProperties which it used to query via ConnectivityManager.
For VpnInfo[], this was racy as NSS may ignore intermediate changes to a
VPN's underlying networks. See http://b/123961098 for more context.
It may also lead to deadlocks b/w ConnectivityService and
NetworkStatsService. See http://b/126245192 for more info.
This change will ensure that NSS is never contending on any of
ConnectivityService locks.
Bug: 123961098
Bug: 126245192
Bug: 120145746
Test: atest FrameworksNetTests
Change-Id: Id1da446b54d95ee68ed14079107b1a10318bcf8b
Merged-In: I57e117bb4e9efe491b19d6b5a479f2d58d1c58e6
* changes:
Catch ServiceSpecificException instead of IllegalStateException.
Manage NAT64 prefix discovery lifecycle in the framework.
Track NAT64 in the framework and start clatd iff NAT64 detected
Change Nat464Xlat lifecycle.
Minor improvements to verifyTcpBufferSizeChange.
Lorenzo Colittiauthored and Gerrit Code Reviewcommited 2019-02-27 23:37:42 +00:00
The old NetworkManagementService methods to start clatd threw
IllegalStateException, but the new netd methods throw
ServiceSpecificException. Update the catch clauses so that if
starting clatd fails, the system doesn't crash.
Also stop logging stack traces but only include the exception
message itself.
Bug: 65674744
Test: atest FrameworksNetTests
Test: connecting/disconnecting to v6-only wifi in a loop does not crash
Change-Id: I4a9ec7f104712fbbe08f4f67e3288df03e8ed873
Lorenzo Colitticommited 2019-02-27 18:21:22 +09:00
Currently NAT64 prefix discovery, which runs in netd, is started
by netd itself when a network is programmed with all-IPv6 DNS
servers. Unfortunately this is not correct because in many cases
we program DNS servers before the network is connected and it's
actually possible to send packets to them.
In general netd does not have enough visibility into network
lifecycle management to decide when to start and stop prefix
discovery. So move it into the framework with the rest of the
464xlat control plane.
Bug: 65674744
Test: atest FrameworksNetTests
Change-Id: I8fa051a9c216d9c05082bf7d0bbb0cbd56000162
Lorenzo Colitticommited 2019-02-27 00:18:13 +09:00
Currently, both netd and clatd do NAT64 prefix detection, and we
start clatd on all IPv6-only networks regardless of whether netd
has detected a NAT64 prefix or not.
Instead, track the NAT64 prefix in the framework, and only start
clatd if the prefix is detected. This will allow us to remove
DNS64 detection in clatd, and pass the NAT64 prefix and the IPv6
address to clatd on the command line instead of clatd finding it
itself. That way, netd and the framework will always know how
464xlat is configured, and we'll be able to use that information
in netd.
Test: builds, boots
Test: atest FrameworksNetTests
Change-Id: Ida32d5760c5aecf7aeebef08fdb596291b2ce14a
Lorenzo Colitticommited 2019-02-25 11:42:00 +09:00
Currently, NetworkAgentInfo keeps a Nat464Xlat object only on
networks where we're starting clatd (i.e., IPv6-only networks).
Simplify this code by making the Nat464Xlat object final and
always non-null. This allows us to use Nat464Xlat to store
information, such as the NAT64 prefix, even if the clat daemon
has not been started yet.
Also, remove the STOPPING state which waits for the interface to
be removed. Instead, when stop() is called, immediately enter the
IDLE state.
- This is necessary in order to be able to call start() again
before the interface removal notification has arrived.
- It's also arguably more correct than the current code,
because when stop() returns clatd has already terminated
(ClatdController::stopClatd calls waitpid), and thus the tun
fd is already closed and the tun interface is gone.
Also, now that Nat464Xlat objects are reused after stop(), add
test coverage for calling start() after stop, in both cases:
- The notification that the previous interface was removed
arrives before the second start().
- The notification that the previous interface was removed
arrives after the second start() but before the notification
that the second interface was added.
Also fix a couple of lint warnings.
Test: builds, boots
Test: atest FrameworksNetTests
Test: clatd stops when IPv4 address added
Test: clatd restarts after "adb shell killall clatd"
Change-Id: I3dc66d155aa27606681f3473daf2170434d8c6d0
Lorenzo Colitticommited 2019-02-25 11:42:00 +09:00
1. Remove "throws Exception" from the signature so it can be used
in tests that do not already throw Exception.
2. Update comment to reflect the fact that TCP buffer sizes are
set on default network switch, not on connect.
3. Move into the method a class-level static constant that is
only used in that method.
Test: atest ConnectivityServiceTest
Change-Id: Ic2e4fbedc23065efc20e45ea84996b577a8e94b6
Lorenzo Colitticommited 2019-02-25 11:41:50 +09:00
The current logging relies on the system log that may rotate. This is a
problem to investigate bugs where the network stack service is not
started. Add a SharedLog to NetworkStackClient and dump it in
ConnectivityService (for lack of a better place to dump it).
Bug: 124307802
Test: Booted, dumpsys connectivity shows the log
Change-Id: If596451d0613645f68a8a32acb032eea76ea506c
Netd need the list of apps that have permission INTERNET or permission
UPDATE_DEVICE_STATS at run time to make decisions about application
request. To avoid protential deadlock and reduce the traffic between
netd and system server, Use packageManagerServcie to send the list of
apps that have those permissions to netd when device boot and when new
apps get installed.
Bug: 111560570
Bug: 111560739
Test: install and uninstall packages and dumpsys netd trafficcontroller
Change-Id: Idb9905f424557a5c59e35d41f5eafe345aca87e0
am: f6abf78795 -s ours
am skip reason: change_id I421c7487955ee339f88e3957c973375d0f87e2ff with SHA1 95bd7221f6 is in history
Change-Id: Ieb824b633f240abc96ee25f39c68f55f1bd621bd
Xin Liauthored and android-build-mergercommited 2019-02-20 10:17:48 -08:00
* changes:
Fix merge problems with cherry-picking "Add notification settings to backup&restore" change into pi-dev
DO NOT MERGE - Merge PPRL.190205.001 into master
Xin Liauthored and Gerrit Code Reviewcommited 2019-02-20 16:25:58 +00:00
Bug: 122652441
Test: atest com.android.server.connectivity.VpnTest
Test: Establish a IPv4 VPN with minimal routes and check
(dumpsys connectivity) the VPN network does not have INTERNET
capability.
Change-Id: Ic7f19ebb7b7f78a6ffb2a8ec3fc3eca5e5421f57
NetworkStack is only used in services.net or clients of services.net. It
cannot stay in framework.jar because it needs to depend on AIDL
interfaces, which would conflict with app implementations if they were
in framework.jar.
Test: atest FrameworksNetTests NetworkStackTests
Bug: 124033493
Change-Id: Ib1d08a3669983640119d008db7e2990fa798724f
Merged-In: I501b125a388c1100c2182bde4670944c2f0d7a02
ICaptivePortal is used in the framework and cannot be used as a
dependency in NetworkMonitor, as the framework class takes precedence
when linking.
Also fix NetworkMonitorTest that was not verifying the right
startCaptivePortalApp call.
Test: atest FrameworksNetTests NetworkStackTests
Bug: 124033493
Change-Id: I8e7bb79e50650ae182a2e4277fb49abf5fb6d910
Merged-In: Ib6a89e54312628662b130fbeec18d11e139f09fa
Previously, they were only updated when underlying network set was
non-null.
This change also ensures that all the calls b/w ConnectivityService and
Vpn that leads to updating capabilities are on ConnectivityService
handler thread.
Additionally, it also ensures that capabilities are propagated after VPN
enters connected state. This was previously done from establish which
could potentially lead to race between VPN getting connected and
capabilities getting updated.
This change also updates VPN capabilities inline from
ConnectivityService handler thread. Previously, there was an additional
loop where Vpn would update capabilities via NetworkAgent thru
AsyncChannel which posts back to CS handler thread, which could
potentially lead to delays in updating VPN capabilities.
Bug: 119129310
Bug: 118856062
Bug: 124268198
Test: atest FrameworksNetTests
Test: manual - verified VPNs capabilities are getting updated and
DownloadManager is working correctly.
Change-Id: Id0abc4d304bb096e92479a118168690ccce634ed
The test did not wait for the WifiNetworkAgent to disconnect, and there
are reports of flakes where it is still connected in
connectKeepaliveNetwork.
Test: atest FrameworksNetTests
Bug: 124319553
Change-Id: I85968806885c8853ec4f4dbea356366c1af0ea1c
In aosp/861571, it tried to refine the design to prevent the
lingering notification is cleared unexpectedly. However, all
notifications should be cleared when network is disconnected.
Refine the design by clearing all lingering notifications when
network is disconnected.
Bug: 123488640
Bug: 123537643
Test: 1.Build pass
2.atest FrameworksNetTests
3.Connect to a hotspot which doesn't have internet,
after getting "NO_INTERNET" notification, disconnect
the wifi and check if "NO_INTERNET" notification will
be cleared or not.
Change-Id: Iac45ec186cf81915c318dba37f43136609d579f6
lucaslinauthored and Lucas Lincommited 2019-02-13 03:23:10 +00:00
This change adds new network types for testing purposes, signifying a
network with an extremely limited feature set.
Bug: 72950854
Test: Compiles, CTS tests relying on this work correctly.
Change-Id: I06cade6044afd12e0b69ed3c2f160f27f85d43d0
Have the network stack pass its package name in
showProvisioningNotification instead.
Bug: 124033493
Test: flashed, WiFi and captive portal works
Test: atest FrameworksNetTests NetworkStackTests
Change-Id: I1f3312768ba1fb34e99a827e1fcdaf7510e318a8
Varun Anand
authored and
android-build-merger
commited 
Chiachang Wang
authored and
Treehugger Robot
authored and
Gerrit Code Review
commited 
Lorenzo Colitti
authored and
Xin Li
authored and
Android (Google) Code Review
commited 
Remi NGUYEN VAN
authored and
Chenbo Feng
authored and
Rubin Xu
authored and
Benedict Wong
authored and
Lucas Lin
authored and
android-build-team Robot
commited