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 saves dozens of warnings every time FrameworkNetTests is
compiled. There is nothing we can do about those warnings because
LegacyTypeTracker's reason for existence is to power deprecated
APIs.
Test: m FrameworksNetTests
Change-Id: I4d65b0aade493e12b56a94247efbf9d1ad7bb4b9
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 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
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)
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
Change-Id: I3e4ff990c0d4825b21c7679be29a482a2d1324ec
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 4d3f871a944d24cd7cbe3aa51a789a71020eafb5)
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 5258b1b82f39bf17e0751bcb94479464250aaec5)
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 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 94e1c08a9ad4b0ff17e0f3a77fff0d3364040ba5)
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
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
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
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
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
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
