packages/modules/Connectivity/service/native/TrafficController.cpp:58:18: error: using decl 'DumpWriter' is unused [misc-unused-using-decls,-warnings-as-errors]
using netdutils::DumpWriter;
^
packages/modules/Connectivity/service/native/TrafficController.cpp:58:18: note: remove the using
using netdutils::DumpWriter;
~~~~~~~~~~~~~~~~^~~~~~~~~~~
packages/modules/Connectivity/service/native/TrafficController.cpp:61:18: error: using decl 'ScopedIndent' is unused [misc-unused-using-decls,-warnings-as-errors]
using netdutils::ScopedIndent;
^
packages/modules/Connectivity/service/native/TrafficController.cpp:61:18: note: remove the using
using netdutils::ScopedIndent;
~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
Test: presubmit
Change-Id: I1871139fed31c57a5c15a8ab4f88aa7c695ff360
The goal is to be able to remove getMap() from BpfMap.h,
as it effectively leaks (what should be an) internal fd.
In practice the dump() operation isn't useful,
as initMaps() and thus native_init() already
guarantee all these maps have valid file descriptors.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If89c28923d3ae030dfac0b3b0ab8b15117db3f30
This switches incoming packets from L3 to L2,
ie. they now include the ethernet header for non-rawip cases
(like wifi)
Note: depends on userspace clatd change to offset packet
processing index by tpacket_auxdata->tp_net L3 header offset,
an increase in the read buffer size, and on change to use
IPv6 header relative cBPF for ingress packet filtering!
Test: TreeHugger, atest libclat_test, ping 1.1.1.1 on v6-only wifi
Bug: 265591307
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie5893d18b0dd796751f95150680a0d4cd5f64c3c
Needed to support AF_PACKET/SOCK_RAW sockets
Test: TreeHugger, ping on ipv6-only wifi works
Bug: 265591307
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If324ee1e97a90b1a0a2ee0fabe1d91ef0603fdac
Setting SO_MARK to MARK_UNSET, ie. 0, is harmless,
since the default for a brand new socket is already 0.
See ClatCoordinator.java getFwMark() for the mark we actually pass in,
which is guaranteed to have at least 4 bits (16,17,18,19) set.
See also:
https://android-review.git.corp.google.com/c/platform/packages/modules/Connectivity/+/2392272
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I3b4eebc0a5ad20390a13efcc58cecf94868686ba
kernel's net/packet/af_packet.c packet_rcv() does (paraphrased):
unsigned int snaplen = skb->len;
unsigned int res = run_filter(skb, sk, snaplen);
if (!res) goto drop_n_restore;
if (snaplen > res) snaplen = res;
which makes it clear that cbpf filter returning 0 means drop,
while any other unsigned int (ie. u32) value means capture that
many bytes - but no more than packet length.
Might as well just use the maximum u32 as the snaplen,
since it will be truncated to skb->len as needed.
Of course additionally IPv6 packets can have a payload size of 65535
(which does not include the IPv6 header itself, and assumes we
don't bother with IPv6 jumbograms, which we can't translate to IPv4
anyways), so the L3 mtu should actually be 65535 + 40.
Except that is also too large to translate to ipv4,
so instead the max L3 mtu should be 65535 - 20 + 40 + 8
(which is the max IPv4 packet size - sizeof ipv4 header + sizeof
ipv6 header + sizeof ipv6 fragmentation extension header).
Since the cBPF currently deals with L3 packets it should return
an L3 length (ie. not including L2 headers), but this will change
when we switch to using L2 af_packet sockets (this change will
mean we will not need to change this code at that point in time).
Furthermore, this should have always returned MAXMTU, and not
PACKETLEN, as it does not care about the tun_pi extra header
(which is added later).
ie. this *should* have always been:
#define MAXMTU (0xFFFF + 28)
BPF_STMT(BPF_RET | BPF_K, MAXMTU)
but:
BPF_STMT(BPF_RET | BPF_K, 0xFFFFFFFFu)
is even simpler.
Bug: 259872525
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2cc4960f0092720b5ee196e8716f07826bd7f362
This allows clat to initialize properly when VPNs are configured
with "Block connections without VPN", rather than to error out with
"no IPv6 addresses were available for clat".
This issue primarily affects particular mobile networks configured
with NAT64 (without direct IPv4 connectivity).
Bug: 255040839
Change-Id: I4a8ee0295e0f5d1e330f7529856347b8bd10360c
Information in the dump does not change
....
current ownerMatch configuration: 516 DOZABLE_MATCH OEM_DENY_1_MATCH
....
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I5f7b56e4ba03256414f49d0e82d65477fb97f05a
Information in the dump does not change
....
current statsMap configuration: 0 SELECT_MAP_A
....
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I42a844227f258b91ba5b368d8e8abf82a773a801
Also remove the dump of mPrivilegedUser because this is not used now and
the information is duplicated with uidPermissionMap dump.
Before this CL
....
mUidPermissionMap:
10049 PERMISSION_NONE
10027 BPF_PERMISSION_INTERNET BPF_PERMISSION_UPDATE_DEVICE_STATS
1041 BPF_PERMISSION_UPDATE_DEVICE_STATS
....
After this CL
....
sUidPermissionMap:
10049 PERMISSION_NONE
10027 PERMISSION_INTERNET PERMISSION_UPDATE_DEVICE_STATS
1041 PERMISSION_UPDATE_DEVICE_STATS
....
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I416501d5a28a5443f954f9c8c58ea255e5cdc897
Map status dump will do access check if map is null.
This could show different message from the current dump output.
Information in map content dump does not change
$ dumpsys connectivity trafficcontroller
....
mIfaceIndexNameMap:
ifaceIndex=5 ifaceName=ip6_vti0
ifaceIndex=19 ifaceName=r_rmnet_data3
ifaceIndex=17 ifaceName=r_rmnet_data1
ifaceIndex=18 ifaceName=r_rmnet_data2
ifaceIndex=23 ifaceName=wifi-aware0
....
$ dumpsys netstats
....
BPF map content:
ifaceIndex=5 ifaceName=ip6_vti0
ifaceIndex=19 ifaceName=r_rmnet_data3
ifaceIndex=17 ifaceName=r_rmnet_data1
ifaceIndex=18 ifaceName=r_rmnet_data2
ifaceIndex=8 ifaceName=rmnet_ipa0
....
Bug: 217624062
Test: dumpsys netstats, atest
com.android.server.net.BpfInterfaceMapUpdaterTest
Change-Id: If182bd97f72713b6347028668cf7bd4676b8aea4
This CL prepares for upcoming CL.
Upcoming CL will add SkDestroyListener with Java BpfMap and switch
current C SkDestroyListener and new Java SkDestroyListener based on the
experiment flag.
Bug: 217624062
Test: atest SkDestroyListenerTest
Change-Id: I5ebb319d1b2262199d4ef6a3549894fee24c4ccf
netd makes sure netd can open all bpf programs at startup and exit if it
fails.
So, program status is always OK if netd starts successflly.
Bug: 241787285
Bug: 217624062
Test: atest TrafficControllerTest, dumpsys connectivityservice
trafficcontroller
Change-Id: Ida29dcbb2612e84f7030389050e2a3d2830c73ff
status dump was removed in aosp/2167962 and aosp/2165825.
But TrafficController still open these maps in init and hold them, so
dump should show the status of them.
Bug: 217624062
Bug: 241787285
Test: atest TrafficControllerTest, dumpsys connectivityservice
trafficcontroller
Change-Id: Icc1f255a619b22174abb2a7d323b7e3c4d42909f
aosp/2167063 moved mCookieTagMap dump from TrafficController to
NetworkStatsService.
But this dump was used from Cts TagSocketTest.
So, this CL re-adds mCookieTagMap dump to TrafficController to avoid
failure of released Cts.
Upcoming CL will update Cts test to check dump both from
TrafficController and NetworkStatsService.
And after the old Cts support period is over, mCookieTagMap dump in
TrafficController can be removed.
Bug: 241787285
Test: atest TagSocketTest TrafficControllerTest
Change-Id: Ie2ef09fa7d91cf96f56c5efcbe9d863dd68a1020
Map status dump will do access check if map is null.
This could show different message from the current dump output.
Information in map content dump does not change
$ dumpsys connectivity trafficcontroller
....
mUidCounterSetMap:
10093 1
10060 1
1073 1
1001 1
10089 1
....
$ dumpsys netstats
....
mUidCounterSetMap:
uid=10093 set=1
uid=10090 set=1
uid=1073 set=1
uid=10089 set=1
uid=1000 set=1
....
Bug: 217624062
Test: dumpsys netstats, dumpstate, atest NetworkStatsServiceTest
Change-Id: Ia70379a3cee820f3f05d1f036947b357d9da4bd7
Map status dump will do access check if map is null.
This could show different message from the current dump output.
Information in map content dump does not change
$ dumpsys connectivity trafficcontroller
....
mCookieTagMap:
cookie=1398 tag=0x0 uid=1029
cookie=1433 tag=0xffffff82 uid=1051
cookie=1166 tag=0xfffffe01 uid=1073
$ dumpsys netstats
....
mCookieTagMap:
cookie=1144 tag=0xfffffe01 uid=1073
cookie=1376 tag=0x0 uid=1029
cookie=1408 tag=0xffffff82 uid=1051
Bug: 217624062
Test: dumpsys netstats, dumpstate, atest NetworkStatsServiceTest
Change-Id: I14dd6f969a0b5eb24ace62361ce2484cf18b7470
This reverts commit b1144d7671.
Reason for revert: We decided to have experiment and switch old code path and new code path based on a flag. So the codes removed by this CL is needed.
Bug: 217624062
Test: m
Change-Id: Icb8a353a74935ed97f8e102ba54020825676b817
Previous commit update BpfNetMaps#setChildChain to use Java BpfMap.
This commit remove the code that is no longer used due to the previous
commit.
Bug: 217624062
Test: atest BpfNetMapsTest android.net.cts.ConnectivityManagerTest#testFirewallBlocking
Change-Id: I02656096c8752daf20d3578f209778c5adae9b0c
This eliminates the need for netd_updatable BpfHandler.cpp
to initialize the hash map with a zero.
On startup the map will be freshly initialized and thus zero.
On restart it might not be empty, but it doesn't matter to netd.
Furthermore the mainline component of the system server will
re-initialize it again anyway:
see service/native/TrafficController.cpp initMaps()
This does remove the ability to call deleteValue on a key,
since that would always return -EINVAL, but since we don't
currently do that, that's really a feature.
(It does suggest though that we should have a BpfMapNonNullable
class which is writeable, but without a deleteValue() function)
Additionally BpfMap arrays are more efficient for the kernel bpf jit
compiler, as - on newer kernels - it can optimize the read/write
into a simple memory access (as opposed to a bpf helper call).
Before:
$ adb shell ls -l /sys/fs/bpf/netd_shared/map_netd_configuration_map
-rw-rw---- 1 root net_bw_acct 0 2022-06-11 08:20 /sys/fs/bpf/netd_shared/ map_netd_configuration_map
After:
$ adbz shell ls -l /sys/fs/bpf/netd_shared/map_netd_configuration_map
-r--rw---- 1 root net_bw_acct 0 2022-06-16 15:03 /sys/fs/bpf/netd_shared/map_netd_configuration_map
Bug: 235590615
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I21730e4fa22fbf0c94ab0ca5c5db03aa000b7680
addInterface and hasUpdateDeviceStatsPermission are not used
Test: m & flush & boot
Bug: 217624062
Change-Id: I8a0f84f607a4f35512bc72e732df8f689b8ed1c9
LOCKDOWN_VPN was in the FirewallChain IntDef but this was not a right
place because LOCKDOWN_VPN was not a valid value for Connectivity APIs
that take an argument annotated with @FirewallChain(setUidFirewallRule,
setFirewallChainEnabled, replaceFirewallChain).
LOCKDOWN_VPN was in the FirewallChain IntDef because
BpfNetMaps#setUidRule was used to add/remove LOCKDOWN_VPN entries.
This commit adds BpfNetMaps#updateUidLockdownRule and uses this to
add/remove LOCKDOWN_VPN entries instead of BpfNetMaps#setUidRule and
removes LOCKDOWN from FirewallChain.
Bug: 206482423
Test: atest TrafficControllerTest ConnectivityServiceTest
PermissionMonitorTest HostsideVpnTests#testBlockIncomingPacket
Change-Id: Iff9b9792fc0f208f153e10e396c6d5034b412d7c
dump function has no enough code coverage for error handling.
Add a simple unit test so that code lines can be executed and counted.
Test: atest TrafficControllerTest
Change-Id: I65a322cc93d559896f0b481ca849b39315432df3
uidMatchTypeToString function has no enough line coverage currently.
Add a simple unit test so that code lines can be executed and counted.
NO_MATCH(0) can't be verified because match type flag is added by OR
operator. See TrafficController::addRule.
Bug: N/A
Test: atest
Change-Id: I6178d4a8cc21430882fae3c1f53f7bc1cebb6c01
