Some OEM may have special mobile data icon show up when non-default
(e.g. DUN) mobile connection connected even wifi is also connected.
So always connected DUN may let user hard to distinguish tethering
upstream in those OEM's devices. Also release unused mobile connection
may safe power.
This CL removes unnecessary code from selectPreferredUpstreamType.
In particular:
- When a DUN or HIPRI upstream is selected, calling
registerMobileNetworkRequest is unnecessary. A mobile
NetworkRequest is always registered unless a non-mobile upstream
is selected.
- When a non-mobile upstream is found, releasing the mobile
NetworkRequest is unnecessary in selectPreferredUpstreamType
because it will be done by chooseUpstreamType immediately after
selectPreferredUpstreamType returns.
- When no upstream is found and cellular upstream is not permitted,
it is not necessary to release the mobile NetworkRequest. When
cellular is not permitted, no such NetworkRequest will be filed
because registerMobileNetworkRequest checks with EntitlementManager
before actually requesting the network. If cellular becomes the
upstream and then later becomes not permitted because of an
entitlement failure, all tethering will be stopped by Settings.
Note: currently legacy upstream selection has two known bugs:
1. If mobile has higher priority than non-mobile network, mobile request
should never be released and always prefer use mobile. But in practice,
mobile request would be released when tethering select non-mobile network
as upstream.
2. If mobile has higher priority than wifi network and default network
is wifi but mobile is still connected, tethering would choose mobile as
upstream because it has higher priority. Mobile disconnecting may not
trigger tethering to switch its upstream to wifi because currnetly
tethering rely on CONNECTIVITY_ACTION broadcast to handle upstream
disconnect.
Bug: 173068192
Test: atest TetheringTests
Change-Id: Id5df58af830cc534ecd79041ddf8a04171047e9b
As a temporary measure to get the test to pass, use the
QUERY_ALL_PACKAGES permission when calling getSupportedKeepalives.
This is helps as getSupportedKeepalives obtains the configuration
from resources in the connectivity resources package, which
recently got its own non-platform certificate and is now not
visible from the test anymore.
getSupportedKeepalives is only used by tests and ConnectivityService
which has all permissions.
The actual fix should make sure getSupportedKeepalives does not require
such a permission (although getSupportedKeepalives is not a formal API),
but this will take more time and the test needs to stay green in the
meantime.
Bug: 186093901
Test: atest CtsNetTestCases
Change-Id: I288ec13a6f0840b184f1c919785724733ca56adf
Build NetworkRequest using builder from an existing
NetworkRequest is exposed to API surface, so add a test to
verify its behavior works as expectation.
Also, create a TestUtils in the cts to put the multiple
reference methods(shouldTestSApis) to prevent duplication.
Bug: 186061922
Test: atest CtsNetTestCases:android.net.cts.NetworkRequestTest
in current sdk
Test: atest CtsNetTestCasesLatestSdk:android.net.cts.NetworkRequestTest
in R and current sdk
Test: atest android.net.cts.ConnectivityManagerTest#\
testRegisterNetworkCallback
Change-Id: I46318e212d51e4e13efa86e8b9c3ca7326d62b77
This is useful for OEMs that want to use RNDIS or NCM as a
local-only link that is directly connected to some other host.
This can be used to implement USB tethering using NCM, which
currently only supports local-only mode.
Bug: 175090447
Test: TetheringIntegrationTests:EthernetTetheringTest#testLocalOnlyTethering
Change-Id: I0ffaa46e4640e5b235340a15d25909106ceb0c07
* changes:
Fix CtsNetTestCasesLatestSdk in AOSP.
Use the non-API static UserHandle.getUid method in tests.
Import ConnectivityManager.BLOCKED_REASON_* from ConstantsShim.
This test suite is broken in AOSP due to a number of tests that
depend on S APIs. We attempted to prevent those tests running on
R builds with:
@IgnoreUpTo(Build.VERSION_CODES.R)
but this is not sufficient for them to pass when the test is
compiled against the R SDK (e.g., in CtsNetTestCasesLatestSdk).
This is because when compiling against the R SDK, the test uses
the API 30 shims, which throw UnsupportedApiLevelException even
though the method actually exists on device.
Fix this using:
assumeTrue(shouldTestSApis());
This is not great, but at least it unbreaks the tests for now.
Test: atest CtsNetTestCases:android.net.cts.ConnectivityManagerTest
Test: atest CtsNetTestCasesLatestSdk:android.net.cts.ConnectivityManagerTest
Change-Id: Ifee0aea5afef6bd4bc762a4b1f25fc05e562d49a
The code was updated in AOSP to use the new non-static
UserHandle#getUid(int), which is only available in S or above.
This fails to build in mainline-prod. Instead of defining a shim
for this, simply use an older method that takes a userId.
Bug: 165835257
Test: atest CtsNetTestCases:android.net.cts.ConnectivityManagerTest
Test: CtsNetTestCasesLatestSdk:android.net.cts.ConnectivityManagerTest
Change-Id: Id529f8b201cc871aa3155aef0f44574d88040c2d
This is needed for the tests to compile in mainline-prod.
Bug: 165835257
Test: atest CtsNetTestCases:android.net.ConnectivityManagerTest
Change-Id: I32924824e9968996f379e31f1b28eb6a8f29bc5d
Currently, NetworkCallbackTest gets the capabilities of current
active network to track the network used for the tests. And
construct the request with the capabilities gets from the
network. This causes test fails if the capabilities contain
signal strength, since it requires NETWORK_SIGNAL_STRENGTH_WAKEUP
to be declared.
Thus, this patch null out several fields from capabilities
of the current active network to construct the new request
in order to prevent over-specifying the requirement.
Test: atest CtsHostsideNetworkTests:com.android.cts.net.HostsideNetworkCallbackTests
Bug: 182516128
Change-Id: Ib79b38e63ad2083c29fd71a24b8686b3f6f4e12f
The test config takes longer than 15mins to run. Move it to a dedicated
group for running slow presubmit Test Mapping test.
Some more context is in the referenced bug, e.g, b/174495337
The group will work exactly the same as presubmit for now.
Bug: 174654670
Bug: 174495337
Test: none
Change-Id: I7fe1286ed952a6058c56c36f28b4832947edb69f
When a 464xlat upstream disconnects, onLinkPropertiesChanged is
called after onLost. This breaks an UpstreamNetworkMonitor
assumption that no callback will ever arrive after onLost.
Bug: 173068192
Fix: 185117377
Test: new unit test
Change-Id: I4ff1eca6d5ed1680ff716c71b683891c8a0e5a77
UserHandle.getUid() is updated to a non-static API based on API
review feedback. Update the usage accordingly.
Bug: 184735865
Test: atest VpnTest
Change-Id: I884f427fae85b2b26973a0315b1ccf3d6f0824c6
* changes:
Cleanups to VPN hostside tests.
Ensure the HostsideVpnTests passes with keyguard locked.
Add CTS tests for registerDefaultNetworkCallbackAsUid.
By current wifi design, wifi will report disconnected and
re-connected when changing from non-metered to metered.
However, the cts test app listens for all network, which
will get mobile network as active network when wifi is
changing meteredness. This is not expected. And causes
test failures when DUT has both wifi and mobile connections.
Thus, this change pass request to track currently active
network to the test app and register only for transport
types of currently active network to prevent from getting
unexpected network.
Test: atest CtsHostsideNetworkTests:com.android.cts.net.HostsideNetworkCallbackTests
Bug: 182516128
Merged-In: I2dce6035b13472bbdc2609009d690aac96280033
Change-Id: I2dce6035b13472bbdc2609009d690aac96280033
(cherry-picked from ag/14029457)
Use TestableNetworkCallback instead of a hand-rolled class.
Remove unnecessary runWithShellPermissionIdentity around
unregisterNetworkCallback calls.
Bug: 165835257
Test: test-only change
Change-Id: I4557dfc64136f9c0b4bdaa1248c33b13e96ba3ed
The test app used in CtsHostsideNetworkTests already dismisses
the keyguard for its own activity, but that doesn't work for the
VPN tests. This is because as soon as the VPN dialog appears, the
test activity is no longer in the foreground and the keyguard
comes back. As a result, the test cannot click on the VPN dialog.
Test: test-only change
Change-Id: I7be1d7fb46a2f9547bc5325d75b5bd5546e6dc18
Add separate testing for unicast and multicast RAs.
Make the test more realistic by:
- Enabling forwarding. This ensures that the daemon actually
receives the RS.
- Adding a link-local route. This ensures that the daemon is
actually able to send a unicast response.
Bug: 154669942
Test: atest TetheringPrivilegedTests
Change-Id: Ibb1f51b5b1871657d7feff39335d3c71586cf64f
If a tc ebpf program writes into a packet using direct packet access
then the packet will automatically be uncloned and pulled by
additional prologue inserted by the kernel itself. See
tc_cls_act_prologue() & bpf_unclone_prologue() in kernel sources
(this is how the clat ebpf program works, which does DPA writes).
However in the forwarding programs we only *read* from the packets
using direct packet access, but never write. All writes happen via
kernel bpf helpers (this is mostly an implementation detail: since
we need to use helpers for checksum updates, I decided to also use
checksums for the writes themselves). As such the insert 'automatic
unclone/pull' logic doesn't trigger.
It is thus possible (it depends on the skb layout delivered by the
nic driver) for 0 bytes of the packet to be accessible for read
using direct packet access. We thus need to explicitly try to pull
in the header of the packet so that we can inspect it.
In most cases (on most drivers for most packet types) this will
end up being a no-op (because the headers will already be in
the linear portion of the skb). But on some drivers for some
packet types it ends up mattering.
Test: TreeHugger, makes icmpv6 tether forwarding work on bramble
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4b07e57728ce544ffb908527ea11ecc315e5acec
When forwarding is on, DadProxyTest fails because forwarding
disables optimistic addresses. This results in the DAD proxy
getting EADDRNOTAVAIL.
Forwarding is on quite often on real hardware because many
solutions for wifi calling use forwarding.
Fix the test to retry after two seconds if the packet is not
forwarded on the first attempt.
It would also be possible to make this work more reliably in the
test by simply disabling DAD or disabling forwarding. However,
because DAD does happen in real usage (downstream interfaces
always disable DAD, but upstream interfaces don't), that seems
risky. For example, if the test disabled DAD, it would not catch
bugs where the DAD proxy crashed or stopped forwarding if it got
EADDRNOTAVAIL.
Test: atest TetheringPrivilegedTests on coral, which has forwarding on
Change-Id: I58280ef7c0e40371cd770ead4c8baa7190c288fd
Current upstream selection code suffers from a race where if the
CONNECTIVITY_ACTION broadcast for a given network switch is
received and processed before the NetworkCallbacks for that
network switch, upstream selection just re-selects the same
upstream it had before. The incorrect upstream persists until
another CONNECTIVITY_ACTION is received.
Fix this by defining a new EVENT_DEFAULT_SWITCHED message code
communicated from UpstreamNetworkMonitor to Tethering, and send
that whenever the default network switches.
The message is sent in onLinkPropertiesChanged, because the
tethering code stores all information about networks in an
UpstreamNetworkState structure that contains Network,
LinkProperties and NetworkCapabilities. When a network switch
occurs, onLinkPropertiesChanged always follows onAvailable and
onCapabilitiesChanged, and thus marks the first point in time
when all the information is available.
This CL tries not to change existing codepaths too much, but
it does move the update of mDefaultInternetNetwork from
onCapabilitiesChanged to onLinkPropertiesChanged. This should
not be a problem because the only thing that reads
mDefaultInternetNetwork is getCurrentPreferredUpstream, which,
in the case of a default network switch, will be run by the
onLinkPropertiesChanged which will immediately follow.
Bug: 173068192
Test: changes to existing unit tests show bug is fixed
Change-Id: Ic9196bc92892811b25bda463ffd839ee5c19d294
In the current tethering code, upstream selection is only
triggered by CONNECTIVITY_ACTION. But in automatic mode, the
upstream network is selected by listening to a NetworkCallback
that tracks the default network.
This causes a race where if the CONNECTIVITY_ACTION for a network
switch is received and processed before the callbacks for that
network switch, upstream selection just re-selects the upstream
currently in use.
Make it possible to test this by giving TestConnectivityManager
the ability to choose the ordering between NetworkCallbacks and
CONNECTIVITY_ACTION, and to run an arbitrary Runnable between
calling one and calling the other. TetheringTest passes a
Runnable that calls mLooper.dispatchAll(), which ensures that
the tethering code fully processes the first set of information
it receives (either the broadcast (or the callbacks) before
receiving any more information.
Add test coverage to testAutomaticUpstreamSelection that
exercises various orderings, and make the test pass by expecting
the buggy behaviour of the current code.
An upcoming CL will fix the bug and update the tests.
Bug: 173068192
Test: test-only change
Change-Id: I7805444dcf59f6d5f8517fbcf2f2b1641783d50b
This is needed for forwarding to work, so it should be dumped.
New output:
Forwarding rules:
29(29) -> 14(rmnet2) 86dd 00:00:00:00:00:00 00:00:00:00:00:00
[ap_br_wlan2]: iif(iface) oif(iface) v6addr srcmac dstmac
14(rmnet2) 29(ap_br_wlan2) 2001:240:2423:13fa:3c21:e35a:6a59:ff8a da:17:fd:70:3d:14 26:5b:b2:ee:bc:ba
IPv4: [inDstMac] iif(iface) src -> nat -> dst
[da:17:fd:70:3d:14] 29(29) 192.168.222.151:39208 -> 14(rmnet2) 100.102.14.231:39208 -> 172.217.175.3:80
[da:17:fd:70:3d:14] 29(29) 192.168.222.151:47386 -> 14(rmnet2) 100.102.14.231:47386 -> 216.58.197.196:443
Also add a call to getHostAddress() to remove the / on IPv6
forwarding rules.
Test: manual
Change-Id: I347ea5a3fd88c51f1fae0c76c75dfa30c68a55ad
Add a unit test to verify that BPF coordinator access downstream4
and upstream4 map while the conntrack event was received.
Verify shim API for IPv4:
- tetherOffloadRuleAdd
- tetherOffloadRuleRemove
- tetherOffloadGetAndClearStats
- tetherOffloadSetInterfaceQuota
- isAnyIpv4RuleOnUpstream
Test: atest TetheringCoverageTests
Change-Id: Ia57f07990d8750fd6ff67d7f4a18aa610336024a
