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
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
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
In the BPF code, per-UID network access (e.g., for doze mode,
standby, etc.) is stored in UidOwnerValue structures. Each of
these stores that UID's rules in a 32-bit bitmask of
UidOwnerMatchType values, so the code can support ~31 match
types.
However, which match types are enabled is stored in
configuration_map at index UID_RULES_CONFIGURATION_KEY, and
configuration_map only stores 8-bit values. So it's not
possible to define more than 7 match types.
Widen configuration_map to from 8 to 32 bits to match the width
of UidOwnerValue.rule. This doesn't impact memory because
configuration_map only has 2 entries.
Bug: 208371987
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7e1eee2daedd66d27965a2dd4ce6b4c3667892f7
Configuration map index 1(CURRENT_STATS_MAP_CONFIGURATION_KEY) can only
have value 0(SELECT_MAP_A) or 1(SELECT_MAP_B). Return error if it is any
other values. Otherwise, read out of array boundary can cause memory
corruption or security issues.
Bug: 231420457
Test: TH
Change-Id: Ia800ad78781f72b8118469c0230cc550796d334e
Currently, even when VPN Lockdown mode is enabled, incoming packets are
not dropped if VPN is not connected.
This commit fixed this issue.
After this commit, If VPN Lockdown mode is enabled, incoming packets
are dropped regardless of the VPN connectivity.
Bug: 206482423
Test: atest TrafficControllerTest ConnectivityServiceTest PermissionMonitorTest
Change-Id: If52ece613c8aac1073355e43b6fb9cb3fcc87d1d
Match type is also used in configuration_map at index
UID_RULES_CONFIGURATION_KEY.
However, this commit does not extend configuration_map and we can
not still use more than 8 match type in configuration_map.
Test: m
Change-Id: I0f20cc8034551806b5cb3da322a0ea7861983095
Two reason for renaming:
1. Avoid module name collision in sc-mainline-prod branch.
2. The libnetdbpf was misnamed before.
Bug: 202086915
Test: atest libnetworkstats_test FrameworksNetTests
ConnectivityCoverageTests FrameworksNetSmokeTests
CtsAppOpsTestCases
Change-Id: I87fcf4b1a9d58780a45743a9aa91b9b936e54266
Tethering module.
Delete tagSocket(), privilegedTagSocket() and untagSocket() since
they are moved out of TrafficController in aosp/1849156.
Bug: 202086915
Test: m; flash; boot;
Change-Id: Ifeaeb060fbf1add9f06748e7846b9e11e0345bda
Delete tagSocket(), privilegedTagSocket() and untagSocket() since
they are moved out of TrafficController in aosp/1849156.
Test: m
Change-Id: I6162c758446f597eb79734e00348dc8b1fe2d422
