.toList() was only introduced to android in api level 34, which is newer than
this module's min_sdk_version. Replace it with .collect().
This was found while updating android lint.
Flag: EXEMPT refactor
Bug: 394096385
Test: Presubmits
Change-Id: I472bff7749aebb21bd8681ecf4235ce7a6cfc7de
most of these are spammy and/or not useful.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iab101ce7de076ef025a046d5e3e9007e091b271f
Maciej Żenczykowskicommited 2025-01-31 12:53:11 -08:00
This commit adds CtsTetheringTestLatestSdk to the postsubmit
configuration. This is a preparatory step towards moving the test to
presubmit, ensuring it runs regularly and catches issues earlier in the
development cycle.
Test: TH
Change-Id: I6932b0b660a675a20102d2683119f689557d8590
Add a basic implementation of stopTetheringRequest that simply stops
tethering for that specific type if it is active, or fail with
TETHER_ERROR_UNKNOWN_REQUEST if not. In the future, we will do fuzzy
matching to ensure the correct request is removed.
Bug: 216524590
Test: atest TetheringManagerTest#testStopTetheringRequest
Change-Id: Ib4a660aacdb83e645e39ceb61b7cda45bb24d89d
Quang Anh Luongcommited 2025-01-31 16:23:04 +09:00
Linux Kernel documentation states:
* u64 bpf_get_netns_cookie(void *ctx)
Description
Retrieve the cookie (generated by the kernel) of the network
namespace the input *ctx* is associated with. The network
namespace cookie remains stable for its lifetime and provides
a global identifier that can be assumed unique. If *ctx* is
NULL, then the helper returns the cookie for the initial
network namespace. The cookie itself is very similar to that
of **bpf_get_socket_cookie**\ () helper, but for network
namespaces instead of sockets.
Return
A 8-byte long opaque number.
This was introduced in Linux 5.7, see get_netns_cookie in
https://elixir.bootlin.com/linux/v5.7/source/net/core/filter.c
vs
https://elixir.bootlin.com/linux/v5.6/source/net/core/filter.c
But only for sock & sock_addr, while sock_ops & sk_msg were
added later (present in 6.12)
Test: N/A
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Idccb7191552be8048a02fff2358e7d7898123dd9
Maciej Żenczykowskiauthored and Patrick Rohrcommited 2025-01-30 18:48:51 -08:00
Adding this to make sure we have 'unprivileged_bpf_disabled = 0'
This is currently set by NetBpfLoad, but if we remove that things currently work.
However with this change the device then fails to boot:
$ adbz logcat -s -d *:* | egrep -i -C10 bpf
I NetdUpdatable: libnetd_updatable_init: Initializing
I NetdUpdatable: BPF programs are loaded
I NetdUpdatable: initMaps successfully
E NetdUpdatable: libnetd_updatable_init: Failed: (1) [Operation not permitted] : map create failed
This is because even though system/netd/server/netd.rc has:
service netd /system/bin/netd
class main
capabilities CHOWN DAC_OVERRIDE DAC_READ_SEARCH FOWNER IPC_LOCK KILL NET_ADMIN NET_BIND_SERVICE NET_RAW SETUID SETGID
user root
group root net_admin
and we thus run as root/root with CAP_NET_ADMIN, but we do *NOT* have CAP_BPF nor CAP_SYS_ADMIN.
This means netd is considered 'unprivileged' from the point of view of that sysctl.
Creating maps from outside the bpfloader (ie. netd/system server/network stack)
is required for map-in-map.
While the sepolicy for netd.te map_create is in V, there is no real
need for this test on V atm, doing this to prevent *future* regressions.
A rollout purely to the not yet existing 25Q2+ is safer.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia39c74cfb1707e88b0aa534ddf42139b1698d5d6
Maciej Żenczykowskicommited 2025-01-30 14:58:07 -08:00
These are convenience macros which do
(const|volatile) cast for atomic operations.
I've run into a case where two 32-bit writes get optimized
by the compiler into a single 64-bit write, which then fails
verification. WRITE_ONCE() avoids that by virtue of the volatile annotation.
Technically I think the same thing could happen on read,
so add READ_ONCE too.
Test: N/A
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iade089aab3522916bd7b431d4064f89a21bc78b0
Maciej Żenczykowskicommited 2025-01-30 14:43:45 -08:00
* changes:
Remove redundant requestedState from IpServer#enable
Log tethering started with placeholder request
no-op: Make TetheringRequest @NonNull in enableIpServing
Quang Luongauthored and Gerrit Code Reviewcommited 2025-01-30 00:44:35 -08:00
IpServer#enable is called with both a non-null TetheringRequest and the
requestedState, but the requestedState is derived from the
TetheringRequest's connectivity scope. Remove this requestedState arg
and simply have IpServer read the connectivity scope itself.
Bug: 216524590
Test: covered by existing tests
Change-Id: I73227f5053da3a2ab35563268fc416b6dd9b1801
Quang Anh Luongcommited 2025-01-30 14:30:51 +09:00
Currently the enableIpServing->tetherInternal call stack may have a
tethering request alongside a redundant tethering type and requested
state. The redundant arguments were necessary since there may be cases
where the active request is null (e.g. back-to-back start/stop, which
removes the active request before the link layer event enables ip
serving).
This change gets rid of the redundant arguments and makes the call stack
take a non-null TetheringRequest. In case the active request is not
found, we will create a placeholder request with just the type and
connectivity scope (i.e. requested state). This should be equivalent to
the old code of sending a null request (since none of the other fields
in TetheringRequest are used), making this a no-op change.
Bug: 216524590
Test: covered by existing tests
Change-Id: I5ac83c74f5bc4aec2fe85daa9477740749d95c63
Quang Anh Luongcommited 2025-01-30 14:30:49 +09:00
Avoids:
android.net.cts.DnsTest#testDnsWorks: FAILED (4.993s)
STACKTRACE:
java.lang.AssertionError: Default network did not provide IPv6 connectivity after 5000ms. Please connect to an IPv6-capable network.
lp={InterfaceName: wlan0 LinkAddresses: [ fe80::6c1f:76ff:fe50:2c84/64,192.168.99.115/25 ] DnsAddresses: [ /192.168.99.1 ] Domains: l
an MTU: 0 ServerAddress: /192.168.99.1 TcpBufferSizes: 524288,1048576,2097152,262144,524288,1048576 Routes: [ fe80::/64 -> :: wlan0 m
tu 0,192.168.99.0/25 -> 0.0.0.0 wlan0 mtu 0,0.0.0.0/0 -> 192.168.99.1 wlan0 mtu 0 ]}
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.assertTrue(Assert.java:42)
at android.net.cts.DnsTest.ensureIpv6Connectivity(DnsTest.java:319)
at android.net.cts.DnsTest.testDnsWorks(DnsTest.java:90)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4b94edae6d196ca02858702dec40ee2bad1db494
Maciej Żenczykowskicommited 2025-01-29 19:56:31 -08:00
due to:
android.net.cts.ConnectivityManagerTest#testOpenConnection: FAILED (277ms)
STACKTRACE:
java.lang.AssertionError: Same address '104.135.180.196' on two different networks (153, 143)
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertFalse(Assert.java:65)
at android.net.cts.ConnectivityManagerTest.testOpenConnection(ConnectivityManagerTest.java:934)
This would possibly be fixed by cuttlefish having IPv6 connectivity, but it doesn't atm.
@RequiresDevice doesn't work right with atest.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I5bd4189ed6297a2491dc0ab7b251ffd19d1ecb5d
Maciej Żenczykowskicommited 2025-01-29 19:54:48 -08:00
* changes:
Rename mActiveTetheringRequests to mPendingTetheringRequests
Give the two variants of ensureIpServerStarted different names.
Move the TetheringRequest further up the stack.
Un-nest legacyTether by moving lambda contents to new method.
Quang Luongauthored and Gerrit Code Reviewcommited 2025-01-29 13:48:17 -08:00
When setIncludeTestInterfaces(false) is called, any RTM_DELLINK
callback for a testtap interface is ignored, since the interface is no
longer considered to be a valid ethernet interface.
Change setIncludeTestInterfaces to go through all interfaces, and stop
tracking the ones which are no longer valid. Otherwise, they will
stick around forever (and break subsequent tests).
Bug: 390722214
Test: TH
Change-Id: Ied73e86c0452831f4d6b00f67908c51201af8bbd
mActiveTetheringRequests is a misnomer because the requests aren't
actually active yet. Rename this to mPendingTetheringRequests since
they're pending a link layer event that the iface is ready to start IP
serving.
Bug: 216524590
Test: covered by existing tests
Change-Id: Ib0c4a52e0aa72fc27b67bce25187124b20082c05
Quang Anh Luongauthored and Lorenzo Colitticommited 2025-01-29 17:15:53 +09:00
The fact that the two overloads have the same name is confusing
because one of them fetches the type and one of them has it
passed in. This means it's not obvious whether they behave
identically or not.
This is a no-op refactor.
Bug: 216524590
Test: covered by existing tests
Change-Id: Iff7d2981cb5835831f00117166035d48b44a61a4
Lorenzo Colitticommited 2025-01-29 17:11:37 +09:00
Currently, the active TetheringRequest (if any) is fetched at the
very bottom of the stack, just before enabling the IpServer.
Have the callers pass it in instead.
This CL is a no-op refactor. In particular, it ignores the fact
that the TetheringRequest can be null, and that the connectivity
scope in the request might not match the requested state, etc. -
it just documents the current behaviour (bugs included) and
leaves it unchanged. It exists only to make future changes
easier.
Bug: 216524590
Test: covered by existing tests
Change-Id: Ie8af8b718a9de1f1d5adde0ac589060dce112a27
Lorenzo Colitticommited 2025-01-29 17:11:37 +09:00
Cole Faust
authored and
Automerger Merge Worker
commited 
Maciej Żenczykowski
authored and
Treehugger Robot
authored and
Gerrit Code Review
commited 
Yuyang Huang
commited 
Quang Anh Luong
commited 
Patrick Rohr
commited 
Lorenzo Colitti
commited