Allows SdkExtensions to inspect its version to decide what the extension
sdk version is on-device.
Bug: 188787081
Test: m com.android.tethering and inspect
Merged-In: If2d28b02be871594fed1fbb40b7aad284b553afb
Change-Id: If2d28b02be871594fed1fbb40b7aad284b553afb
The migration will merge history in downstream branches,
so changes should not be submitted in the meantime.
Bug: 189375701
Change-Id: I32d4c6a2d7344b1baf92eeac27b3cbbecd549c2d
Test: TH
Fix memory access violation in com_android_networkstack_tethering_BpfUtils.cpp
caused by invalid format string in com_android_networkstack_tethering_BpfUtils_isEthernet.
If rv is not valid, jniThrowException will format a string using
"Unknown hardware address type %s on interface %s". However, rv is an int but here
"%s" is used in fmt string, thus causing access violation of memory.
Use "%d" instead of "%s" for int.
Bug: 188757793
Change-Id: I9d8ec0708efd747e24b3b3ffed5336434d4f64a7
tryCell configuration would not be force disabled UpstreamMonitor stop.
If tethering stop with using mobile upstream and swap with SIM fron no
dun to dun supported, dun request would be filed even tethering is not
active.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I5505655f52da9fdca2fd43a58e043a9ab727741d
- Move Tethering TEST_MAPPING up one level to merge with the general
Connectivity TEST_MAPPING. This allows running the tethering tests
on any connectivity change.
- Move TetheringIntegrationTests from postsubmit to presubmit
- Add TetheringCoverageTests to mainline-postsubmit, so it can be
added to mainline-presubmit later.
- Import NetworkStack tests so that they are run on any connectivity
change.
TetheringIntegrationTests were continuously green in postsubmit.
Bug: 187946226
Change-Id: Ibf05ad64b02c563930ba0f01eb91331b295fe505
Test: Treehugger needed to test TEST_MAPPING files
The change aosp/1708088 break tethering unit test in R.
Bug: 187946226
Test: atest TetheringTests in R and S
Change-Id: I4eb4b757f6d7cd3458964c81310dcf0687a4f091
startTrackDefaultNetwork was allowed to called multiple times
before even though there is no one actually do it. However,
in the TetheringTest#verifyDefaultNetworkRequestFiled, a
manual invocation is used to ensure that function supports
multiple entrance.
But with aosp/1697371, startTrackDefaultNetwork is no longer
allowed to be called multiple times, it would lead to log.wtf
and crash system in eng build.
Since the manual invocation of startTrackDefaultNetwork is not
realistic and no longer valid anymore, remove the invocation
that caused the trouble.
Test: atest TetheringCoverageTests
Bug: 188613493
Change-Id: I61f6088783d521fd17ae1e87370842b4239fbe75
Replace the isFeatureEnabled function which is check with apex version.
Bug: 187946226
Test: Set device config flag and check the result
Change-Id: Iba44a01e2fdd0698dcb338ea4a8fe8147cbaa7dd
While the actual part that track default request is inside
UpstreamNetworkMonitor, instead of passing it from Tethering,
move it into counter-part CL and use it from
UpstreamNetworkMonitor.
Since the current code is replaced by registerSystemDefaultCallback
in Android S, implement it inside the api30 shim implementation
to provide an unified interface to tethering.
Test: atest TetheringCoverageTests
Bug: 185952829
Change-Id: Iaf21b6b662aa6aba79c2b75379128b8523f81f02
Note that the contents of the bootclasspath_fragment are added as
dependencies to an apex, so there is no need to duplicate them in
java_libs.
Bug: 180105615
Test: atest CtsClasspathsTestCases
Change-Id: Ia19ed0d5e13676882239dd5a1456c97549119994
Merged-In: Ia19ed0d5e13676882239dd5a1456c97549119994
1. Fix no ACCESS_NETWORK_STATE permission problem when accessing
EthernetManager#getAvailableInterfaces API from S.
2. Fix some wrong jarjar rules.
Bug: 187371740
Test: atest TetheringCoverageTest on R platform
Change-Id: I203db6c4ea2e13d8fb5bc2db7ee877ccbb97b761
Create *LatestSdk variant build target which have target sdk specify
to allow test apk install to released platform.
Bug: 182211575
Test: test S MtsTetheringTest in R device
Change-Id: I4d5c5e8c3d74993a67380e0211da31884cbf8792
This is no longer necessary as all the methods that take it are
running on on the handler thread, either in Tethering itself or
on the state machine thread in IpServer, which runs on the same
thread as Tethering.
Specifically:
- interfaceStatusChanged, interfaceAdded, interfaceRemoved,
interfaceLinkStateChanged: run from mNetdCallback, which always
posts them to mHandler.
- setWifiTethering: only called by enableTetheringInternal, which
is called by the following:
- startTethering, stopTethering: via lambda posted to mHandler
- IpServerCallback#requestEnableTethering: called by IpServer
while processing a command.
- setEthernetTethering: only called by enableTetheringInternal.
- EthernetCallback: runs on mExecutor, which posts to mHandler.
- getLastTetherError: only used by the test. Renamed to
getLastErrorForTest to ensure no other callers.
- sendTetherStateChangedBroadcast: called only by
notifyInterfaceStateChange, which is called only by
- IpServerCallback#updateInterfaceState, which is called only
by sendInterfaceState, which is called by various IpServer
state enter methods.
- notifyLinkPropertiesChanged: called only by
IpServerCallback#updateLinkProperties, which is only called by
IpServer#sendLinkProperties, which is only called by:
- Code that processes CMD_IPV6_TETHER_UPDATE
- IpServer#handleNewPrefixRequest: only called when processing
CMD_NEW_PREFIX_REQUEST.
- IpServer#sendInterfaceState (see above)
- handleWifiApAction, handleWifiP2pAction: only called by
mStateReceiver, which runs on the handler thread
- tether(String, int): called by:
- tether(String, IIntResultListener): posted to mHandler
- changeInterfaceState: called by:
- EthernetCallback (see above)
- enableWifiIpServingLocked: called by handleWifiApAction and
handleWifiP2pAction (see above)
- tetherMatchingInterfaces: only called by handleUsbAction,
which is run from mStateReceiver on the handler thread.
- untether(String): called by:
- untether(String, IIntResultListener): posted to mHandler
- changeInterfaceState (see above)
- setUsbTethering: called by:
- setUsbTethering(boolean, IIntResultListener): posted to mHandler
- enableTetheringInternal (see above)
- setNcmTethering: called by enableTetheringInternal (see above)
- getTetheredIfaces: called only by TetheringTest. Renamed to
getTetheredIfacesForTest to ensure no other callers.
- getErroredIfaces: unused, deleted in this CL
- getTetheredIfaces: called by:
- isTetheringActive: called by onUserRestrictionsChanged, which
is only called by mStateReceiver
- TetheringTest
- dump(): changed to run on handler thread
- upstreamWanted: called by
- TetherModeAliveState#enter
- TetherModeAliveState#updateUpstreamWanted, which is called
only by TetherModeAliveState#processMessage.
Test: atest TetheringCoverageTests
Test: enabled/disabled hotspot, USB tethering
Change-Id: Id49d33f027b8df4c97fda480ff239c0ba90bb96a
This is in preparation for removing mPublicSync.
Test: m
Test: adb shell dumpsys tethering
Test: atest TetheringTests TetheringIntegrationTests
Change-Id: Ib2c9d0bff23614f76c8e075d32cb03412d3d21f7
Attach BPF program may be failed with the netlink error message
"Invalid argument". Per debug kernel trace, it is failed in
comparing the kind name in tc_new_tfilter.
Log:
05-05 19:44:42.329 1073 2332 2332 W tc_new_tfilter:
Specified filter kind does not match existing one
Test: enable usb tethering and check the follows
$ adb shell tc filter show dev <upstream, downstream> ingress
filter protocol ipv6 pref 1 bpf chain 0
filter protocol ipv6 pref 1 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_upstream6_ether:[*fsobj]
direct-action not_in_hw id 3 tag 94ca9b12972fdea8
filter protocol ip pref 2 bpf chain 0
filter protocol ip pref 2 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_upstream4_ether:[*fsobj]
direct-action not_in_hw id 9 tag 992aa9bfd0503457
filter protocol ipv6 pref 1 bpf chain 0
filter protocol ipv6 pref 1 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_downstream6_rawip:[*fsobj]
direct-action not_in_hw id 4 tag 7fb60e556b8f3be7
filter protocol ip pref 2 bpf chain 0
filter protocol ip pref 2 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_downstream4_rawip:[*fsobj]
direct-action not_in_hw id 6 tag e41426095404fb64
Change-Id: I471a2e34c626a3737cbd2754e4d1b3000bcf6ba6
This is necessary change for minimize the code size when
repeatedly restarting OffloadController in subsequent
patches.
Test: atest TetheringTests
Bug: 149467454
Merged-In: I0b02d01cd8749d81c9d020dee7fdb4f80e18ae98
Change-Id: I0b02d01cd8749d81c9d020dee7fdb4f80e18ae98
(cherry-picked from ag/14234078)
This allows the coverage tests to manually trigger native coverage
collection, as a workaround for collection not being triggered
automatically by the coverage infrastructure.
Bug: 185202279
Test: atest TetheringCoverageTests
Change-Id: I619fc267cf1743dd2218e3dd42546b0d4e9da193
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
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
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
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
