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
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
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
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
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
The APK was added to the standard APEX, but is missing in the
in-process APEX.
Bug: 182557971
Merged-In: Ic2491f04880ff66abc3b2d3aaee6168e18f6d68a
Merged-In: Ibf982ceb5f0fd61c822399e3eeeb1ef5e500604d
Change-Id: Ibf982ceb5f0fd61c822399e3eeeb1ef5e500604d
Test: m
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
The resource package is used by service-connectivity to load its own
resources.
Bug: 182125649
Test: atest FrameworksNetTests
Merged-In: I3c7fc6285f10318ecef05a64e1179054bb831d99
Merged-In: Ic2491f04880ff66abc3b2d3aaee6168e18f6d68a
Change-Id: I3c7fc6285f10318ecef05a64e1179054bb831d99
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
framework-tethering-shared-srcs is named to
framework-connectivity-shared-srcs so update
source section to include correct file group.
Ignore-AOSP-First: changes in topic has conflicts in sc-dev
Bug: 177046265
Test: FrameworksNetTests
Change-Id: I81e2af0cc3b37af16b03c1288eb0591b7ed65cc4
Merged-In: I81e2af0cc3b37af16b03c1288eb0591b7ed65cc4
Merged-In: Ic2491f04880ff66abc3b2d3aaee6168e18f6d68a
by marking programs as optional and providing appropriate stub implementations.
Test: TreeHugger
Bug: 181045068
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I021e7bcbfe4236242f517f067f89777fc08ecd8d
This is just a cut'n'paste reordering of programs.
Goal is to put rawip programs above ether ones.
This will enable next change to be easier to read.
Test: TreeHugger
Bug: 181045068
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Icebf4bf0505136e97b7b6950fb0b790582eb495e
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
TetheringTest is only able to build UpstreamNetworkState objects
for mobile Internet networks. Support building wifi and dun
versions as well.
Bug: 173068192
Test: atest TetheringTests
Change-Id: Id46f1e5b65dbe04e84a5f56343821af260e2539e
This allows future tests that want to exercise the interactions
between Tethering and UNM to do so.
Also verify what happens when UNM is initialized, and in setUp,
capture the NetworkCallback it files to track the default
network, so tests can send it NetworkCallbacks. (This callback
is only ever filed once.)
Test: test-only change
Change-Id: Iff9b62120cced41cc61263bfd4fa34f575d0ac00
Currently, this class is a static inner class of
UpstreamNetworkMonitorTest. Extract it to its own top-level class
so it can be used by other tests.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I6bdb090a99781ac2530b3924ac5c4cf78de315b0
It will map device ifindex to itself (but note that internally in the
kernel this is optimized into a map from ifindex to direct device
pointer), but only for xdp transmit capable devices (other devices
will not have an entry).
This will allow the use of bpf_redirect_map() from xdp tethering programs.
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I29684e6761727d1115e9b4d75486eccbca3d5e33
The system API are moved to the connectivity module: add dependency on
the stubs from framework-tethering.
This only allows tethering to depend on system API defined by the
connectivity classes, not on any private code, even if they are
eventually bundled in the same APEX.
Bug: 171540887
Test: m
Merged-In: Iebfb3e01c5d2480e84edcfc76cf489520bd60237
Merged-In: Ic2491f04880ff66abc3b2d3aaee6168e18f6d68a
(clean cherry-pick from internal branch)
Change-Id: Iebfb3e01c5d2480e84edcfc76cf489520bd60237
