This is supported by:
1. Utilize the new API from both NetworkStatsProvider
and IOffloadControl to send data warning quota to hardware.
And pass the warning reached notification back to NPMS.
2. Disable software solution introduced in R release for
V1.1+ hardware, since now we can fully offload data warning
and limit notification to hardware.
Test: atest TetheringTests
Fix: 149467454
Ignore-AOSP-First: avoid long automerger delay
Change-Id: Ie49461694d77ab7f25a549433b01b5b0167bd489
This is a no-op change that just adapt new API from
NetworkStatsProvider to get warning and limit bytes at the same
time. This change also stores them locally for subsequent
patches to set warning bytes to hardware.
Test: Will be included in the subsequent patch.
Bug: 149467454
Ignore-AOSP-First: avoid long automerger delay
Change-Id: Iec01cb01fd1ce481ce0bd736762baddde1e38084
This is a no-op change that redirect both V1.0 and V1.1 callback
events to the same handling function. Since the V1.1 callback
is extended from V1.0 callback, we can safely use V1.1
callback for both V1.0 and V1.1 control.
The change also provides interface for subsequent
OffloadController changes to set warning and limit at the
same time.
Test: atest TetheringTests
Bug: 149467454
Ignore-AOSP-First: avoid long automerger delay
Change-Id: I6505a04de8c57357dd1fa9ce898c13395e497816
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 a no-op change that try to use 1.1 HAL if available.
Otherwise, fallback to 1.0 HAL. The change also provides version
information for subsequent patches to determine what to do for
specific version.
Test: atest TetheringTests
Bug: 149467454
Ignore-AOSP-First: avoid long automerger delay
Change-Id: I6a3ce877cdff2496087b97b191a9bfd5b0792827
This is necessary change for minimize the code size when
repeatedly restarting OffloadController in subsequent
patches.
Test: atest TetheringTests
Bug: 149467454
Ignore-AOSP-First: avoid long automerger delay
Change-Id: I0b02d01cd8749d81c9d020dee7fdb4f80e18ae98
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
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
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
Required because XDP offload needs input interface mac address
to be a part of the key. The mac address is used for checking
packets which are received from exceped input interface.
Test: atest TetheringCoverageTests, TetheringPrivilegedTests
Change-Id: Ied159454b516c0d70efe0a85744d1bb606892f2d
Currently, BpfCoordinator only sets the data limit on a given
upstream whenever the first IPv6 rule is created on that
upstream, and clears it whenever the last rule is deleted on that
upstream. It never does this when adding or removing IPv4 rules.
This makes it impossible to offload traffic on IPv4-only
networks.
Fix this by setting the limit when IPv4 rules are created or
deleted as well.
Test: atest TetheringCoverageTests
Manual tests as the follows
Test {add, clear} limit with IPv6-only network [OK]
Test {add} limit with IPv4-only upstream [OK]
TODO:
Test {clear} limit with IPv4-only network. blocked by aosp/1579873
because the IPv4 rules have never deleted.
Change-Id: I5a29bdd18e564318759f617023163e23fb5a3ed0
The tests have been building against hidden APIs to provide additional
coverage.
Test: m TetheringCoverageTests CtsNetTestCases
Bug: 182859030
Ignore-AOSP-First: needs manual cherry-picks
Change-Id: I37d748411a34f25834214a2412c49aed1423e526
These members are public mutable and their names are confusing.
Make them package-private and final.
Bug: 173068192
Test: test-only change
Change-Id: I87131c48f67b6614c25aa99e1cbc53196f49aa7c
Currently, TestConnectivityManager immediately sends all
callbacks and broadcasts to the Tethering code as soon as the
test code makes any change.
This makes it impossible to affect the order in which those
events are delivered to the Tethering code, so it is not possible
to test for races.
Fix some of this as follows:
1. Make TestConnectivityManager post all its callbacks to the
handlers that Tethering registered them with.
2. In TetheringTest, use the existing TestLooper object to
advance time manually. Also use setUseRegisteredHandlers to
ensure that the broadcasts are sent in order. This requires
calling dispatchAll() after sending the broadcast to preserve
the existing synchronous behaviour. Take advantage of that to
remove lots of existing dispatchAll calls.
3. Add a TestLooper to UpstreamNetworkMonitorTest and use it.
Keep the test passing by adding lots of mLooper.dispatchAll(),
which is a bit ugly but probably acceptable given the
additional coverage it provides.
This exposes an existing bug in the code where if upstream
selection is in automatic mode, and all CONNECTIVITY_ACTION
broadcasts are received before all NetworkCallbacks, the code
does not switch upstream.
In order to make the tests pass, re-order the CONNECTIVITY_ACTION
broadcasts with the NetworkCallbacks in TestConnectivityManager
so as not to trigger the bug. A future CL will make the order
configurable.
While I'm at it, switch TestConnectivityManager from HashMap to
ArrayMap, which is generally preferred for maps that do not
contain too many elements.
Bug: 173068192
Test: test-only change
Change-Id: I964f365c691fbc396ab0a87f292bd32b123011fe
Currently, Tethering files NetworkRequests even when
config_tether_upstream_automatic is enabled. This is incorrect:
when the automatic upstream selection is enabled, the tethering
upstream should always follow the default network and there is
no need to file any requests.
These requests are harmful when tethering is not using cellular
as its upstream, because:
- If the device does not use mobile data always on, the request
causes the cellular network to be brought up, causing power
draw.
- Even if the device does use mobile data always on, the request
causes the cellular network to come to the foreground, which
allows all apps to access it, causing potential data usage.
Amend the existing testGetCurrentPreferredUpstream to cover these
changes, by making that test case always set automatic upstream
mode. This does not result in any loss of meaningful test
coverage, because getCurrentPreferredUpstream is only ever called
when chooseUpstreamAutomatically is enabled.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I068a5338699a3ed04f24f97f785ea89ff5890e50
UpstreamNetworkMonitor is the part of tethering that files
NetworkRequests for upstream netwoks, but it currently does not
know all the requirements for upstream selection. For example, it
does not know whether automatic upstream selection is in use.
This forces the upstream selection code to be split between
UpstreamNetworkMonitor and Tethering. This makes it difficult to
follow.
This CL ensures that all information about upstream requirements
(DUN required, automatic upstream selection, tryCell) is passed
to UpstreamNetworkMonitor so it can be aware of it.
This CL also removes the ability for UpstreamNetworkMonitor's
callers to call registerMobileNetworkRequest or
releaseMobileNetworkRequest. In a future CL, this will be
automatically done by UpstreamNetworkMonitor depending on the
upstream requirements.
This CL is a no-op refactoring with no behaviour changes.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I174f765c616e0dbe2aa493c12613e6131cff0666
This is necessary for tethering tests to build against hidden
framework-connectivity APIs after it is moved out of
framework-minus-apex.
Bug: 179229316
Test: atest TetheringTests
Ignore-AOSP-First: Need manual cherry-picks
Change-Id: I912fcd19bacb75a5944409b07d8e014032657d4a
Should not {start, stop} conntrack event monitor on R because
it is used by S feature.
Test: atest TetheringCoverageTests
Change-Id: I57a0a84d46e973660b24fc10d314820ada0d45b9
Starting conntrack event monitor on R devices is unnecessary because
no code uses them.
Bug: 177884581
Test: atest TetheringCoverageTests
Change-Id: I036cb8e29b32a4e220da9a52849b978a6ab821e4
Because most of the tethering tests are unprivileged, we cannot
test this code on real sockets. So use an AF_UNIX socketpair.
Bug: 154669942
Bug: 182785371
Test: test-only change
Change-Id: I843fddb3aaeab33628438f3bcd6a4166062de962
Currently, upstream selection is split between the Tethering and
UpstreamNetworkMonitor classes. The UpstreamNetworkMonitor bits
are unit tested, but there are no tests for the interaction of
the two. Add a simple test.
In order to do this, remove the code that controls the
UpstreamNetworkMonitor spy from prepareUsbTethering. This is so
that the new test can call prepareUsbTethering but still rely on
the behaviour of the actual UpstreamNetworkMonitor.
Bug: 173068192
Test: atest TetheringTests
Change-Id: If2ef9af82bc0cbff9172e575ad3d7686e5b492da
Migrate Maze's BPF program attaching and detaching functions from
system/netd/server/OffloadUtils.{c, h} to tethering module.
Test: atest TetheringCoverageTests
Test case #1:
Enable WiFi hotspot and check tc filters are added or removed on both
wlan1 and rmnet_data#.
$ adb shell tc filter show dev wlan1 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 2 tag 7cf020cc09a7c982
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 7 tag 2f87d55b636c082c
$ adb shell tc filter show dev rmnet_data2 ingress;
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 3 tag 8b3885b75bd261de
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 b1c9478c91f8df9a
Test case #2:
Enable USB tethering and check tc filters are added or removed on both
rndis0 and rmnet_data#.
Test case #3:
Enable WiFi and USB tethering and check tc filter are added or removed
on rndis0, wlan1 and rmnet_data#.
Change-Id: I3f9a65043271bc8f5bf1b82ae505c471625ca9de
The tethering code still depends on CONNECTIVITY_ACTION for
upstream selection. Make TestConnectivityManager send these
broadcasts.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I6a32e99fafef9d6d2abec438ffc68164ab4c5bdf
The changes required are:
- Change all usages of when(mCm.method()).thenReturn(...) to
doReturn(...).when(mCm).method() because spies must use the
latter syntax.
- In setDataSaverEnabled, set the mocked return value before
sending the broadcast. Otherwise, the first time the method is
called, the spy will attempt to send the broadcast, and will
crash because it does not have permission to do so.
This does not do anything useful yet, but it will be used in
future CLs.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I968bfa76ead25b2d45ed1c0e8ede32df81401579
