This adds code to resolve the endpoint in the legacy VPN
runner if it was specified as a hostname, and enables the
previously added test that was disabled because this was
broken until this patch. See the linked bug for details.
This patch uses the async DNS API to do the resolution.
This lets the resolution be fully cancellable, though the
code is more complex than with the non-interruptible
getByName.
Test: VpnTest and in particular VpnTest#testStartRacoon
Fixes the test meant to test this
Also manual testing that resolution of a real
hostname works as expected, that failure to resolve
returns correctly, and that cancellation/interruption
will unblock the thread and terminate immediately.
Bug: 158974172
Change-Id: I90bec6d85706fa9b2f9a01f81701138a54347005
Merged-In: I96691f6091c43377f23a00621242ed034fcb0444
(cherry picked from commit 8ab570d9c9eb5e52b2c038818e3e4d1d3b98fda0)
The legacy VPN has, among many parameters, a host to connect to.
This host can be specified as a numeric address, or as a hostname.
When it's a name, resolution is required. Currently, name
resolution is performed by the native VPN daemons racoon and
mtpd. When a hostname is used, the framework does not know the
IP address of the VPN server and does not add a throw route for
the VPN server IP address. On older kernels this does not matter
because the legacy PPP kernel code binds the PPP socket to the
right network, but on newer devices that use the upstream PPP
code, this does not work. See b/133797637.
This patch instruments the legacy VPN code so that it can be
run in tests, and uses this instrumentation to simulate passing
a configuration that contains a host, and verifies that the
arguments passed to the mptd and racoon daemons receive the
expected server address, and that the expected throw route is
correctly installed.
It then adds two tests : one specifying the server as a numeric
address, and one as a hostname. As the resolution is currently
broken, the latter of these tests is added disabled, and the
followup fix to the issue enables it.
This test is basic and very targeted, but it's what we need right
now. Also there are plans to remove this entire code path in S, so
the test being ad-hoc is not much of a problem.
Test: this
Bug: 158974172
Change-Id: I96f4bbb9b109e3e5813d083bed1989d88fb156b8
Merged-In: I3c4a94181bd71df68121fa0f71669fa4fa588bdd
(cherry picked from commit dece7f3f74cb67f2a046f3a2a9757b559abc2aac)
For non-telephony networks, this was always set to 0 before R.
In R, it is currently set to the same value as the network type.
This is incorrect because the two have different namespaces.
or example, currently, any network of type WIFI (==1) will have
a subtype of NETWORK_TYPE_GPRS (==1). Similarly, all ETHERNET
networks will have subtype NETWORK_TYPE_1XRTT, all VPN networks
will have a subtype of NETWORK_TYPE_TD_SCDMA, etd.
Bug: 161653721
Test: builds, boots
Change-Id: I07e111c1762e0021c931cefc27f193f78578748b
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
Original-Change: https://android-review.googlesource.com/1350662
Merged-In: Ic7bc7138c54c47bbfdf56af5811709fde66f8606
Change-Id: Ic7bc7138c54c47bbfdf56af5811709fde66f8606
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
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
This class might be used by some mainline modules.
Bug: 151052811
Test: atest DnsPacketTest
Test: atest DnsResolverTest
Change-Id: I8841d91456952ded5efbf8ea221289aecc7746ad
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
On Android different interfaces usually use different routing tables.
As a result, a change in interface should not be treated as route
update, but rather a remove and an add.
This change fixes a bug in VPN seamless handover where routes
failed to be updated when a new tunnel interface replaces the existing
one within the same network.
Bug: 158696878
Test: atest com.android.cts.net.HostsideVpnTests
Test: atest NetworkStackTests
Test: atest CtsNetTestCases
Test: atest FrameworksNetTests
Original-Change: https://android-review.googlesource.com/1331916
Merged-In: I57987233d42a0253eaee2e1ca5f28728c2354620
Change-Id: I57987233d42a0253eaee2e1ca5f28728c2354620
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 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
Merged-In: Ic979dad73983d722365849fbfb0becfd432b894c
Change-Id: Ic979dad73983d722365849fbfb0becfd432b894c
(cherry picked from commit e29bf99a7fc1067c546d7fa6cbcb9001fb110d16)
The classes should not be picked up from frameworks/base, as they are
part of several mainline modules.
Also refine comments in DhcpResults following feedback in previous
change.
Bug: 151052811
Test: m; manual: flashed, wifi and telephony working
Test: atest NetworkStackCoverageTests
Change-Id: I7074651c6a2a7a6b11bcf13cc4bb03833d7d655f
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
Original-Change: https://android-review.googlesource.com/1313813
Merged-In: I5911d01984695550b6c9afe7a8eb535bf5e320a1
Change-Id: I5911d01984695550b6c9afe7a8eb535bf5e320a1
config_mobile_hotspot_provision_app would be move out of framework and
only private for tethering only.
enforceTetherChangePermission is no longer needed because its only
caller PanService already gate by other privileged permission
(BLUETOOTH_PRIVILEGED).
Bug: 146918263
Test: m
Change-Id: I030871c2bc46bc09c4e52970b4995f98d31bb90e
Merged-In: I030871c2bc46bc09c4e52970b4995f98d31bb90e
Avoid using the "iff" abbreviation in our Javadoc.
Bug: 158092978
Test: m doc-comment-check-docs and check the generated doc
Merged-In: I41bf8a6ddad200f00524d9b2dd1bf169810ee460
Change-Id: I41bf8a6ddad200f00524d9b2dd1bf169810ee460
The extra info is taken into NetworkMonitor from while creating
it. The NetworkMonitor is created when a new agent is registered
but the extra info is not available at that time. Make sure the
field is set in the NetworkInfo when registering.
Bug: 156173829
Test: adb shell dumpsys network and check the apn in the extra
info shown correctly
Test: atest FrameworkNetTests
Merged-In: Ieaad8cbf1a28af3b97c7f98f74358e417fcad661
Change-Id: Ieaad8cbf1a28af3b97c7f98f74358e417fcad661
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
Merged-In: I04d2b7402f892546722fe6868c521afd9534f183
(cherry picked from commit 21a352f761ce558bea6fa9ab2a4e49a164228b56)
