This change updates ConnectivityService to notify the
ConnectivityDiagnosticsHandler of app-reported connectivity before
attempting to revalidate the network. This change forces an ordering on
Connectivity Diagnostics events in the case that the reported
connectivity does not match the known connectivity for the network -
this leads to the network being revalidated and the
ConnectivityDiagnostics event onConnectivityReportAvailable. Passing the
onNetworkConnectivityReported event to the
ConnectivityDiagnosticsHandler first ensures that it is passed to
callbacks before any potential ConnectivityReports are.
Bug: 159718782
Test: android.net.cts.ConnectivityDiagnosticsManagerTest
Change-Id: Ic7bc7138c54c47bbfdf56af5811709fde66f8606
There are two methods to handle package added/removed from
two differnt listeners. It can use one of listener to handle the
changes. Thus, keep PackageManagerInternal#PackageListObserver
but remove the listening from ConnectivityService.
Bug: 132784544
Test: atests FrameworksNetTests
Change-Id: Ib2db85e4108f9fda731bf6667d0af0610fc79fea
ConnectivityService puts up some notifications with pending
intents, but these pending intents are mutable that content can
be changed by someone. So make these pending intents to be
immutable.
Some OEMs have their own Settings package. Thus, need to get the
current using Settings package name instead of just use default
name "com.android.settings".
Bug: 154928507
Test: atest FrameworksNetTests
Change-Id: I02e3277358623400aa03dc8996af3d7c46a8ce76
Merged-In: I02e3277358623400aa03dc8996af3d7c46a8ce76
Probe DNS servers to see they support DNS-over-TLS. Use system
CAs to verify whether the certificates sent by DNS servers are
trusted or not. An error is thrown to cause the probe failed if
DNS servers send untrusted certificates.
Unlike the DnsResolver which doesn't verify the certificates
in opportunistic mode, all of the DoT probes from NetworkDiagnostics
check certificates.
DoT probes apply to the DNS servers gotten from LinkProperties
and the DoT servers gotten from PrivateDnsConfig whatever private
DNS mode is.
A common example in DNS strict mode:
. DNS TLS dst{8.8.8.8} hostname{dns.google} src{192.168.43.2:48436} qtype{1} qname{815149-android-ds.metric.gstatic.com}: SUCCEEDED: 1/1 NOERROR (432ms)
F DNS TLS dst{192.168.43.144} hostname{}: FAILED: java.net.ConnectException: failed to connect to /192.168.43.144 (port 853) from /192.168.43.2 (port 41770) after 2500ms: isConnected failed: ECONNREFUSED (Connection refused) (172ms)
. DNS TLS dst{8.8.4.4} hostname{dns.google} src{192.168.43.2:37598} qtype{1} qname{759312-android-ds.metric.gstatic.com}: SUCCEEDED: 1/1 NOERROR (427ms)
An example when the CA is not trusted:
F DNS TLS dst{8.8.8.8} hostname{dns.google}: FAILED: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. (16ms)
An example when TCP/TLS handshake timeout:
F DNS TLS dst{8.8.8.8} hostname{dns.google}: FAILED: java.net.SocketTimeoutException: failed to connect to /8.8.8.8 (port 853) from /192.168.2.108 (port 45680) after 2500ms (2514ms)
Bug: 132925257
Bug: 118369977
Test: atest FrameworksNetTests
Change-Id: I1b54abed0e931ca4b8a97149459cde54da1c3d6f
Some developers have been surprised by this limitation and had trouble
figuring out what the issue was. Add documentation to address this.
This also includes a drive-by removal of a duplicate check.
Bug: 149867479
Test: doc-only change
Change-Id: I5911d01984695550b6c9afe7a8eb535bf5e320a1
This commit changes agentConnect to set the owner UID as the mOwnerUid
field instead of the Binder.getCallingUid().
Binder.getCallingUid() can return incorrect results for platform VPNs,
as agentConnect() is called under a clean calling UID.
Additionally, this relaxes the ownerUid sanitization check to allow a
VPN network's owner to see it's own ownership information.
Vpn.mOwnerUid is guaranteed to be correct, as all VPNs MUST have called
prepareInternal() at some previous point, which sets mOwnerUid as the
package's UID (or SYSTEM_UID if this is legacy VPN).
Bug: 150135470
Test: CTS tests showing ownership information
Change-Id: Ic979dad73983d722365849fbfb0becfd432b894c
This consumes ~3.5% system logs, however it is not very useful
when debugging since similar information could be obtained from
dumpsys {connectivity|netpolicy}. Thus, remove the log.
Test: manual
Bug: 135504481
Change-Id: I04d2b7402f892546722fe6868c521afd9534f183
This change adds a comment to CS#simulateDataStall to explain why the
Data Stall is wrapped in a DataStallReportParcelable before being passed
to the ConnectivityDiagnostics handler. This approach is taken to ensure
that simulated data stalls are handled the exact same as Data Stalls
received directly from NetworkMonitor (including Data Stalls detected by
methods that the platform does not understand).
Bug: 156294356
Test: atest ConnectivityDiagnosticsManager
Change-Id: I751054418bf328c72b977a1cc99c27cb9b8ab7ba
This is only necessary when learning the NAT64 prefix from the
RA, because if the NAT64 prefix is learned from DNS, the DNS
resolver already knows the prefix and automatically enables
DNS64 synthesis.
The DNS resolver needs to be informed of the prefix any time
clat is running on a prefix learned from an RA. This is simple to
implement: just set the prefix when starting clat if prefix
discovery is not running, and clear the prefix when stopping clat
if prefix discovery was not running. This ensures that the prefix
is cleared iff it was set.
Bug: 156914456
Test: new unit test coverage
Change-Id: If8ad2d30712a6df3e207c8d3e8a129705242191e
This CL forwards suspected Data Stall events detected with unknown
detection methods to ConnectivityDiagnostics.
Currently, ConnectivityService drops any data stall events with unknown
detection methods, which leads to false negatives for Connectivity
Diagnostics registrants. This change ensures that registrants will still
be notified as NetworkStack is updated to use new detection methods.
The documentation for ConnectivityDiagnosticsManager#DataStallReport is
also updated to reflect that the detection methods included in the
report are a bit mask of detection methods used. Implicitly, this means
that data stalls detected via unknown methods will have an empty bit
mask (0x00).
Bug: 156294356
Test: atest ConnectivityDiagnosticsManager
Change-Id: I62d0bf91fcc17c7921afd519c72551399906bd6b
This change moves the logic for handling Data Stall notifications from
NetworkMonitorCallbacks to ConnectivityService. This avoids duplicate
logic for managing data stall simulation requests from
ConnectivityManager. This also puts all of the logic for proxying Data
Stall notifications to the ConnectivityDiagnosticsHandler into one
place.
Bug: 148032944
Test: atest ConnectivityDiagnosticsManagerTest
Change-Id: Ie2f6a1a2376c5c452750ab417cb5e8c24fc44fc3
Set the parcelSensitiveFields bit when sending LinkProperties to
NetworkMonitor, so that the captive portal API URL is not lost.
Test: atest ConnectivityServiceIntegrationTest (see followup change)
Bug: 156062304
Change-Id: Ifd4e9c02a6b9a2b2b8b254fc4da7bfb9e0a84550
When a VPN connects and it has any underlying network (which
means almost always, because it will take the default network
if it doesn't declare any), it has default capabilities and
will only take the capabilities of its underlying network
as part of an update happening after making the network
available but before the rematch can take place. This in turn
causes the capabilities callback sent as part of the rematch
to be spuriously sent.
Test: FrameworksNetTests. Also tested together with a
followup that adds tests with drive-by coverage for this.
Bug: 150570873
Change-Id: Id7d8bba486bada1a7ba5b0f152d2aa02e407f249
This change adds a TestApi for simulating a Data Stall to
ConnectivityService. This allows for Data Stalls to be triggered without
having to manipulate the signals used by NetworkMonitor . This also
allows NetworkMonitor to update the ways it detects Data Stalls without
affecting CTS tests for ConnectivityDiagnosticsManager.
Bug: 148032944
Test: atest ConnectivityDiagnosticsManagerTest
Change-Id: Icad439efa2ab4c872c21d3ee6ceaae8c5b49f18d
This change sets the owner and administrator UIDs for test networks when
their initial values match the UID for the app creating the test
network. This ensures that apps registering test networks can only make
themselves owners / administrators of the network.
Bug: 153449964
Test: atest NetworkAgentTest
Change-Id: I3a974700aa1d83cb285295ed1de0aa263e2e5b58
Add a comment explaining the ordering of messages sent to the tracker
and connectivity diagnostics handlers.
Add a Slog.wtf call in case the deprecated notifyNetworkTested callback
is called.
Bug: 153500847
Test: atest ConnectivityServiceTest
Change-Id: I2dbfc9bf7b2f785ea4594851bd354e9fd0fc0bd1
Address issues found during AIDL review:
- Rename clientAddr to singleClientAddr
- Do not use a ParcelableBundle for notifyNetworkTested or
notifyDataStallSuspected; instead use AIDL parcelables for stronger
backwards compatibility guarantees.
Test: atest NetworkMonitorTest ConnectivityServiceTest
ConnectivityServiceIntegrationTest, manual
Bug: 153500847
Change-Id: Id9b71784e5f6294d203230e57737979e063ff0f8
Currently, if a prefix is learned from an RA while prefix
discovery is running, clatd will be correctly started, but
prefix discovery will be stopped.
In order to fix this, make it possible to call
stopPrefixDiscovery without transitioning to IDLE state (which
is obviously necessary in this case), by moving the assignment of
the next state from that method to its callers. For consistency,
do the same for startPrefixDiscovery.
Bug: 150648313
Test: new test coverage
Change-Id: I3803fa3d9806848b331c35ee8bac256934bd1f21
The NAT64 prefix from the RA always takes precedence over the
NAT64 prefix from DNS discovery, because it is detected faster,
and detecting it does not require sending any packets.
Bug: 150648313
Test: new unit test
Change-Id: Ic7452431d2d9aea1ae59b67a9d8383c6cc5b3902
There are tasks that need to be performed when receiving
LinkProperties directly from a NetworkAgent (either at
registration time or in subsequent updates).
Currently, the only example of such a task is calling
ensureDirectlyConnectedRoutes. This is currently done in
handleUpdateLinkProperties, which is often unnecessary,
because that method iscalled in many other cases than when
receiving properties directly from an agent. Ensuring directly
connected routes only needs to be done when receiving
LinkProperties from the agent, because ConnectivityService does
not directly manipulate routes.
This CL does not do much except remove these superfluous calls
and add the method. A future CL will add more code to the method.
Bug: 150648313
Test: atest ConnectivityServiceTest
Change-Id: Ibeeb5f79e8afd3350c935934713d7882f2e0281f
- Allow an app holds NETWORK_SETTINGS to acess registerNetworkProvier()
and unregisterNetworkProvider().
- To access declareNetworkRequestUnfulfillable(), allow an app holds
MANAGE_TEST_NETWORKS to declare a unfulfillable request that contains
TRANSPORT_TEST transport.
This makes easier to write cts to test.
Bug: 153612373
Bug: 153614605
Test: atest FrameworksNetTests
atest CtsNetTestCases:android.net.NetworkProviderTest
Change-Id: Ic9809e731aa811a51c2f82d189372169d99a5ed9
This cannot (currently) happen with DNS64 detection, but it can
happen with the PREF64 option.
Bug: 150648313
Test: atest ConnectivityServiceTest Nat464XlatTest --rerun-until-failure 100
Change-Id: I789fe9d46d3ac5d074ae697d23013f24a9e0246d
- Let any process with NETWORK_SETTINGS register for signal strength
wakeup.
- Allow agents registering test networks to assign them a signal
strength.
Test: NetworkAgentTest
Bug: 139268426
Change-Id: I2b4b89be3e69f4853fd6978d2c8f5c8eb4271f21
For a given network, resolver doesn't know what transport types are.
Therefore, when a new network is created or transport types are changed
in a give network, transport types will be updated and sent by calling
setResolverConfiguration(). In the same time, if link properties or
transport types are null, setResolverConfiguration() won't be called.
The original behaviors of setResolverConfiguration() aren't changed.
Only increasing one new behavior that when a given network has transport
type change, calling setResolverConfiguration() directly and resolver
updates the transport types for that given network.
Bug: 143732914
Test: atest FrameworksNetTests
atest FrameworksNetIntegrationTests
Merged-In: I03fc5c62dfd9a51a78a720860531df282fdecc20
Change-Id: I6527cde0e177ba08c886576131b35fc769c2bb53
This makes the code easier to understand by making state
transitions more explicit. It also makes it easier to address a
TODO to turn the class into a StateMachine.
This should be an exact no-op refactoring. The current cases
covered by the code (all mutually exclusive) are:
1. requiresClat && !isPrefixDiscoveryStarted
Action: startPrefixDiscovery()
Equivalent to IDLE && requiresClat, because
isPrefixDiscoveryStarted returns true for every state except
IDLE.
2. requiresClat && isPrefixDiscoveryStarted && shouldStartClat
Action: start()
Equivalent to DISCOVERING && shouldStartClat,
because isPrefixDiscoveryStarted is true in DISCOVERING,
STARTING, and RUNNING, but start() does nothing if mState is
STARTING or RUNNING.
3. requiresClat && isPrefixDiscoveryStarted && !shouldStartClat
Action: stop()
Equivalent to (STARTING or RUNNING) && !shouldStartClat,
because isPrefixDiscoveryStarted is true in DISCOVERING,
STARTING, and RUNNING, but stop() does nothing if mState is
not STARTING or RUNNING.
4. !requiresClat && isStarted
Action: stop()
Equivalent to (STARTING or RUNNING) && !requiresClat,
because isStarted() is only true in STARTING and RUNNING.
5. !requiresClat && !isStarted && isPrefixDiscoveryStarted
Action: leaveStartedState()
Equivalent to DISCOVERING && !requiresClat, because
the only state with isPrefixDiscoveryStarted and !isStarted
is DISCOVERING.
Also, simplify case #5. In this case, calling leaveStartedState
is superfluous, because in the DISCOVERING state:
- There is no need to call unregisterObserver, since the observer
is only registered when entering STARTING and is unregistered
when going back to DISCOVERING or IDLE.
- mIface and mBaseIface don't need to be set to null because they
are only set to non-null when entering STARTING and nulled out
when going back to DISCOVERING or IDLE.
Bug: 126113090
Bug: 150648313
Test: covered by existing ConnectivityServiceTest and Nat464XlatTest
Change-Id: Ice536bcb269cc8b040c6e7a72c15d0bc8b5bd235
This just a rename with no functional changes at all. It is
preparation for supporting getting the NAT64 prefix from the
RA.
Bug: 150648313
Test: covered by existing ConnectivityServiceTest and Nat464XlatTest
Change-Id: Ia9a09a708870827b1e4cf068f930fa9542dd116c
VPN is considered fully routed if both IPv4 and IPv6 have
either a default route or a prohibit route.
Bug: 145332510
Test: atest FrameworksNetTests
Change-Id: I59cf48552bca98092d1212e3d718fd420add5458
NetworkCapabilities needs to have its UIDs cleared (UID ranges, owner
UID, and administrator UIDs) before it can be shared with apps via
ConnectivityDiagnosticsCallback invocations. The previous helper used
for clearing these values mutated the provided NetworkCapabilities. This
is updated to instead return a sanitized copy of the provided
NetworkCapabilities
Bug: 148942124
Test: atest FrameworksNetTests
Change-Id: I2431a6d273d0d73432919baf41b4f66397f4b7dc
