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: I714985f3c7919dad9c1854830c50f29c1f94a21e
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: I420b63db03a58e8c67a98a85c9f4c2d6ed7ad078
(cherry picked from commit 45846a03051a13d667732288e457eab4336a691e)
This package is using some common utilities from
a library that used to live in the network stack.
A better home for these utilities is frameworks/libs,
so this topic moves the files ther and also changes
the package of some utilities.
See aosp/1350222 and aosp/1350182 for a detailed
description of the specific files that moved.
Test: checkbuild
Change-Id: I76a9b7790f3997e3e6b3c2f75ba6308286457cde
There are two parts in hasRestrictedNetworkPermission method.
One is carryover package check and one is uid permission
check. Seperate carryover package check part to another method
to be clearer the usage of hasRestrictedNetworkPermission method.
Bug: 132784544
Test: atest FrameworksNetTests
Change-Id: Iab0609fcaa52acb0dfcb31ca957f22bfe8d62392
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
(cherry picked from commit a40ff70cad00a6c298e07c2c38e95d58074a7157)
PermissionMonitor check permission by each package name but only
update the uid permission to netd. It's better to check
permission by uid directly. Thus, use
ActivityManager#checkUidPermission to check permissions for each
uid.
Bug: 132784544
Test: atest FrameworksNetTests
Change-Id: I057d34383b4dc408b2773e4c6b146774ba0c5eb2
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
Avoid recording negative data by doing integer-based
math as much as possible, but switch to double-based
math if we detect that we'd end up causing an overflow.
Test :
- Builds, Boots
- High data throughput scenarios
- NetworkStatsHistoryTest, NetworkStatsCollectionTest,
NetworkStatsTest
Bug: 119527458
Change-Id: I55d4aa649bea3ae201ad513074ff2b71cb918dad
