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
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
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
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
TrafficStatsConstants.TAG_SYSTEM_NEIGHBOR is moved to
NetworkStackConstants so update the import class name for it.
Bug: 182349970
Test: FrameworksNetTests
NetworkStackTests
TetheringTests
Change-Id: I8fcd2772ed873d318233d3029184e4352245d4cd
Merged-In: I8fcd2772ed873d318233d3029184e4352245d4cd
Starting conntrack event monitor on R devices is unnecessary because
no code uses them.
Bug: 177884581
Test: atest TetheringCoverageTests
Change-Id: I036cb8e29b32a4e220da9a52849b978a6ab821e4
TrafficStatsConstants.TAG_SYSTEM_NEIGHBOR is moved to
NetworkStackConstants so update the import class name for it.
Bug: 182349970
Test: FrameworksNetTests
NetworkStackTests
TetheringTests
Ignore-AOSP-First: this topic needs to be cherry-picked manually
to AOSP to avoid automerging differences.
Change-Id: I8fcd2772ed873d318233d3029184e4352245d4cd
Opening the maps on R devices is unnecessary (because no code
uses them) and unsafe (because the maps might actually be in a
different format than expected by the module).
Always return null when opening the maps, so the code will safely
fall back to using netd for anything.
This only affects dump(). The production code never opens the
maps except via the shim, and only the S shim opens the maps.
Also check isAtLeastS in dumpCounters, because it opens the map
directly.
Bug: 177884581
Test: builds, boots, "dumpsys tethering" shows expected output
Change-Id: I5884490a5cc40fc529a12100ae5baaeae6a18f30
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
