This CL removes four methods in MockVpn by slightly changing the
test code to leverage the actual methods implemented by the
(production) Vpn superclass.
This works because setting mInterface results in
isRunningLocked() returning true, which makes a number of methods
behave as if the VPN is connected (which is what the test
expects).
The more realistic behaviour exposes a minor bug in the treatment
of underlying networks. Add a TODO to fix it.
Bug: 172870110
Test: test-only change
Change-Id: I49421183538ba61ca790af71e309ece36b653bf9
Merged-In: I49421183538ba61ca790af71e309ece36b653bf9
This test checks that if a VPN declares an underlying network
that does not exist, the capabilities of that network are applied
to the VPN as soon as the network starts to exist.
Bug: 172870110
Test: test-only change
Change-Id: Icc0701cb4cea7d91f7738c1e426e94cd26686b74
Merged-In: Icc0701cb4cea7d91f7738c1e426e94cd26686b74
Check one more parameter enforceDnsUid in ResolverOptionsParcel in
DnsManagerTest.
Bug: 159587277
Test: atest
com.android.server.connectivity.DnsManagerTest#testSendDnsConfiguration
Change-Id: Ic53f42b968626294c851dac252a70769846ba427
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
Original-Change: https://android-review.googlesource.com/1011670
Merged-In: I1b54abed0e931ca4b8a97149459cde54da1c3d6f
Change-Id: I1b54abed0e931ca4b8a97149459cde54da1c3d6f
This is a Client-only solution.
- Add to NetdClient a per-process std::atomic_boolean
similar to netIdForProcess and netIdForResolv.
- The boolean says whether the process should be
allowed Internet connectivity.
- Add an @hide method to NetUtils.java to set the boolean;
call it from the initialization code of the new
process just after forking from zygote.
- Make netdClientSocket and dnsOpenProxy check the
boolean. If the boolean is false, return EPERM from
socket calls.
Bug: 150028556
Test: atest NetworkUtilsTest
Test: atest CtsAppSecurityHostTestCases:UseProcessTest
Change-Id: If002280fbad493dfc2db3d9d505c0257d49a9056
Exempt-From-Owner-Approval: OWNERS already approved identical patchset 5
Test extra info sent to NetworkMonitor correctly if network
agent is created through new NetworkAgent constructor without
legacy network info taken as parameter.
Bug: 156173829
Test: atest FrameworkNetTests
Merged-In: I4f827664c528bea30cc957a0a617dd37693f4460
Change-Id: I4f827664c528bea30cc957a0a617dd37693f4460
This change adds the @RequiresFeature annotation to Ikev2VpnProfile
Builder methods, and checks before provisioning VPN profiles.
Bug: 156681625
Test: New tests added, passing.
Change-Id: I125d8fbe5d67fb877ad7d0636c007cb3e1a9f59b
Merged-In: I125d8fbe5d67fb877ad7d0636c007cb3e1a9f59b
(cherry picked from commit e84a17dd1706f4c8373047b2023a1ec4b7cf4bf3)
No clat app uid 0 rx stats on base iface due to ip6tables raw prerouting drop
(so just copy over the rx stats from the before file)
Test: atest NetworkStatsTest NetworkStatsFactoryTest
Bug: 150738490
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie73ba0586dafde67bc2726db26e07f7268c18be3
Merged-In: Ie73ba0586dafde67bc2726db26e07f7268c18be3
No clat app uid 0 rx stats on base iface due to ip6tables raw prerouting drop
Test: atest NetworkStatsFactoryTest
Bug: 150738490
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4393afcbe8e1bb886ecf4f5c1573f6ac8a0e29f5
Merged-In: I4393afcbe8e1bb886ecf4f5c1573f6ac8a0e29f5
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
Original-Change: https://android-review.googlesource.com/1315578
Merged-In: If8ad2d30712a6df3e207c8d3e8a129705242191e
Change-Id: If8ad2d30712a6df3e207c8d3e8a129705242191e
This is not particularly likely to happen unless the pref64 RA is
sent by a different router than the main RA. But more tests are
always good, and this additional coverage will be more useful
in an upcoming change.
Bug: 150648313
Test: test-only change
Original-Change: https://android-review.googlesource.com/1316094
Merged-In: I3316d49d42100800740afadc4edf0a13a4d8377c
Change-Id: I3316d49d42100800740afadc4edf0a13a4d8377c
As NetworkAgent is in a transition where all agents need
to include the NOT_SUSPENDED capability as part of their
migration to the system API, ConnectivityService adds it
forcefully to all agents that don't have the CELLULAR
transport. This doesn't include VPNs when VPNs have some
cellular network as their underlying network.
The best way to solve this is to make sure the VPN
capabilities reflect those of the underlying networks as
far as the NOT_SUSPENDED capability is concerned. This
is how they work for other similar capabilities.
This also happens to contain a drive-by fix for an issue
with a spurious capabilities callback is triggered 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). Fixing this was
necessary to have a cogent test of this issue, but it
could be moved to another patch or it could stay unfixed
with some minor ajustment to the tests if judged too
dangerous to include in R at this point.
Test: New tests in this patch. Also manually tested with
tcpdump as described in b/150570873.
Bug: 150570873
Original-Change: https://android-review.googlesource.com/1301317
Merged-In: I3e4ff990c0d4825b21c7679be29a482a2d1324ec
Change-Id: I3e4ff990c0d4825b21c7679be29a482a2d1324ec
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
Original-Change: https://android-review.googlesource.com/1305393
Merged-In: Id7d8bba486bada1a7ba5b0f152d2aa02e407f249
Change-Id: Id7d8bba486bada1a7ba5b0f152d2aa02e407f249
This change adds the ability for IKEv2/IPsec VPN profiles to run on Test
Networks. If enabled, the IKEv2/IPsec VPN profiles will request ONLY
test networks.
Bug: 148582947
Test: FrameworksNetTests passing
Test: Added for testing
Change-Id: I2511b39b27a1e29ae97907cdb12728d13fb1628f
Merged-In: I2511b39b27a1e29ae97907cdb12728d13fb1628f
(cherry picked from commit 9e18eeb4a676ef3afc4bc510f18f81213b8edc55)
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
Merged-In: I3a974700aa1d83cb285295ed1de0aa263e2e5b58
(cherry picked from commit 35782280a2adceec96b8e03c217788afa05894a0)
This change adds tests to validate that both transport and tunnel mode
transforms continue to work even after the SPI resource has been
released. Specifically, since SPI resources are effectively subsumed by
the creation of a Transform, the SPI resource is still "alive", but
removed from the user-tracking sparse arrays.
Bug: 142072071
Test: Added these new tests. Failing prior to aosp/1133555, passes with.
Change-Id: I37dd459d08b57b14f72f3b28ea80fa231b152f10
Merged-In: I37dd459d08b57b14f72f3b28ea80fa231b152f10
(cherry picked from commit d06d390b20)
IpSecService.applyTunnelModeTransform() currently does not take an
SpiRecord instance, yet implicitly requires that the SpiRecord instance
is still alive based on the stored SpiRecord resourceId in
the TransformRecord's IpSecConfig.
This check is unnecessary, as the SpiRecord has been subsumed into the
TransformRecord, and the kernel resources are kept alive whether or
not the SpiRecord is still held by the user.
This allows users of the IpSecManager API to allocate short-lived SPIs
during the creation of an IpSecTransform, without having to keep track
of both of them (even though the SPI is no longer usable).
The TransformRecord.getSpiRecord() call is already used in
multiple other places in the same method.
Bug: 142072071
Test: New tests added, passing.
Change-Id: I1959f3080946267243564459ff4207647922566e
Merged-In: I1959f3080946267243564459ff4207647922566e
(cherry picked from commit 1425cf5655)
This commit adds support for validating and filtering IPsec algorithms.
Without a public API exposing IKEv2 algorithms (and their respective
public APIs), the allowedAlgorithms can only filter the proposals for
IPsec (Child) SA algorithms.
Additionally, this removes the HMAC_SHA1 from the IKE SA's integrity
algorithm proposals due to insecurity
Bug: 153701879
Test: FrameworksNetTests passing, new tests added
Change-Id: I7e61a1612692db275b751330af5bacbf86836a8c
Merged-In: I7e61a1612692db275b751330af5bacbf86836a8c
(cherry picked from commit a435ff8bf8)
NetworkStats calculation needs to filter out debug entries to
prevent over counting. While NetworkStatsFactory migrates data
usage over a VPN to the TUN network, NetworkStatsFactory does
not filter out debug entries per vpn which will cause debug
entries left and cause exception.
Bug: 152678151
Test: atest com.android.server.net.NetworkStatsFactoryTest
and verify no exception
Change-Id: I3525edc385b07858b48c7add2d331c4b5a2e84ad
Merged-In: I3525edc385b07858b48c7add2d331c4b5a2e84ad
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
Merged-In: Id9b71784e5f6294d203230e57737979e063ff0f8
Change-Id: Id9b71784e5f6294d203230e57737979e063ff0f8
TelephonyNetworkSpecifier will now treat null as matching nothing. When
the request specifies a TelephonyNetworkSpecifier while the network does
not, this should not be treated as a match.
Bug: 154703135
Test: atest android.net.TelephonyNetworkSpecifierTest
Change-Id: I329110e929995c9eae6c6ce33b5414777acea1e1
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
Merged-In: I3803fa3d9806848b331c35ee8bac256934bd1f21
(cherry picked from commit c7c6f76402a989f91b02c37574b6a9de592cf1af)
464xlat will never be started on a network that is not connected,
or on a network that has no IPv6 address.
This is a no-op test-only change but it is necessary for an
upcoming change that violates some of the invalid assumptions
currently made by this test and causes it to fail.
Bug: 150648313
Test: test-only change
Change-Id: I41766e9adaa7c24454648b371e6e3cc647693be5
Merged-In: I41766e9adaa7c24454648b371e6e3cc647693be5
(cherry picked from commit df0c522d18ee73c1d20cff1a1dc955b383e6c355)
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
Merged-In: Ic7452431d2d9aea1ae59b67a9d8383c6cc5b3902
Change-Id: Ic7452431d2d9aea1ae59b67a9d8383c6cc5b3902
A test that ensures that NetworkCapabilities.TRANSPORT_* is eaual
to IDnsResolver.TRANSPORT_* for every possible value of each.
Bug: 153267602
Test: atest FrameworksNetTests
Merged-In: I6b23ccc6ce1659fdfd9573dfcd895f2c20fa9417
Change-Id: I3dd4ed0d1fcceca9c8aec9b3e6769603e4fa913b
(cherry picked from commit 5f28e6f881e0ea52e8e96c1207654ce44b0d05a1)
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
Merged-In: I789fe9d46d3ac5d074ae697d23013f24a9e0246d
Change-Id: I789fe9d46d3ac5d074ae697d23013f24a9e0246d
Commit has to on top of aosp/1281921 to skip whole test in Q
device since CaptivePortalData class is introduced in R.
Result in Q will be:
[1/1] android.net.CaptivePortalDataTest#skippedClassForDevSdkMismatch: IGNORED
Bug: 152280218
Bug: 150640683
Test: atest CtsNetTestCasesLatestSdk:CaptivePortalDataTest on
both Q and R device
Merged-In: Iddd00e1c85abe767b1a41a1761d3266ba322dba6
Change-Id: Iddd00e1c85abe767b1a41a1761d3266ba322dba6
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
Change-Id: I6527cde0e177ba08c886576131b35fc769c2bb53
Currently, TestableNetworkStatsProvider is a subclass of
INetworkStatsProvider. This is not very accurate naming after
API council review feedback since now we have
NetworkStatsProvider as a system api interface.
This is the counter-part change of actual renaming CL in
NetworkStack.
Test: atest FrameworksNetTests TetheringTests
Bug: 150643374
Change-Id: Ifa8175dc4e2fe2b907ec13b3bd2eca12974f5ea7
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
Merged-In: Ia9a09a708870827b1e4cf068f930fa9542dd116c
Change-Id: Ia9a09a708870827b1e4cf068f930fa9542dd116c
In current design, entries with zeros are preserved after
addition/subtraction. These entries are not very useful
and lead to difficulty of verifying the result of
addition/subtraction.
However, change the behavior in the original NetworkStats
is considered risky in current stage.
Thus, this change provide a function that could remove these
empty entries in tests.
Test: atest FrameworksNetTests
Bug: 152827872
Bug: 150644692
Change-Id: I40a76935d55712b8083ee1e17e137a8a4ef5e029
Merged-In: I40a76935d55712b8083ee1e17e137a8a4ef5e029
(cherry picked from commit 6c7bef3064dbe949b7b213036b8e70c125ddd343)
