Currently, the callbacks of stopping were fired when stop procedure
is started, because the upper layer apps only care about the reason
of stopping instead of stopping result. Thus, there is no need to
wait for the result comes back. However, this behavior generates
races if apps want to re-start keepalive immediately since the
resources are not released yet.
Fix: 134891441
Fix: 140305589
Test: atest com.android.server.ConnectivityServiceTest#testPacketKeepalives \
--rerun-until-failure 1000
Change-Id: I987776a9211a50e964c4675b747bc10e203750f1
Add UidNetdPermissionInfo class to store netd permission info of
each uid. Use the bit mask for combining all netd permission into
one value which can update and get the uid permission easily.
Moreover, aosp/1340042 add carryover package info into this class
which centralizes all netd permissions relevant data.
Bug: 132784544
Test: atest FrameworksNetTests
Change-Id: I3b81ea2a5017e8f4d0d603144a33c9b08640d7ba
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)
This patch is still needed and should go in now that the
error is fixed.
The patch was submitted into rvc-dev and is already in
rvc-dev-plus-aosp (patch in in ag/11923559, revert
skipped in ag/12072199). A follow-up will remove the
unused services.net-module-wifi target.
Test: originally tested in aosp/1324109
Test: m; manual: flashed, wifi and telephony working
Test: atest NetworkStackCoverageTests
Change-Id: I1074eedb0b0f156a1135e11210ec102de15ea674
Merged-In: Icd141a992c46290c74929785e261a1cd57bc001b
The semantics of FileDescriptor in AIDL are that the callee must close
the file descriptor it receives manually.
Bug: http://b/157789860
Test: treehugger
Change-Id: Ice9fc9abe2959a84ad138a95c900dff676653665
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)
