Add tests to verify ike session being triggered when data stall.
Bug: 238692379
Test: atest FrameworksNetTests
Change-Id: I656ea0973072b0bbdd54863eccbe105adb02d6ad
* changes:
ethernet: further cleanup updateConfiguration tests
ethernet: add test for updateConfiguration on untracked interface
ethernet: fix updateConfiguration expectations
ethernet: add LinkPropertiesChanged coverage in EthernetManagerTest
ethernet: remove unit test cases that have end-to-end coverage
ethernet: temporary mitigation for test that uses TUNSETCARRIER
This test need a connected enterprise Network before setting
a profile network preferences. If there is no enterprise network
after setting no fallback preference, it will get lost callback
from cell network because it's not matched current preference.
The test fails sometimes because the enterprise network agent is
not fully connected yet. Thus, make sure the agent is fully
connected before settting a profile network preferences.
Fix: 242833379
Test: atest FrameworksNetTests:com.android.server.Connectivity\
ServiceTest#testPreferenceForUserNetworkUpDownWithNo\
FallbackWithAlreadyConnectedWorkAgent \
--rerun-until-failure 100 on cf target
Change-Id: I040b9f31c29834f90f4ca62c512e392141a3244d
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
This replaces testNetworkRequest_linkPropertiesUpdate in
EthernetNetworkFactoryTest.
Test: atest EthernetManagerTest
Change-Id: Ib27b18a153a1866765378753baa9046aff9636f3
Test: FrameworksNetTests
adb shell device_config put connectivity actively_prefer_bad_wifi
+ check that dumpsys updates
Test: at this patchset tests fail with :
Permission denial: reading from settings requires:android.permission.READ_DEVICE_CONFIG
Change-Id: Icfe1e64b8313921ff1dc8e4cbd45f967692e1c4a
The removed test cases already have coverage in EthernetManagerTest and
are therefore removed. The removed tests should all be covered by
testNetworkRequest_withSingleExistingInterface.
Test: atest EthernetManagerTest
Change-Id: I5e23fc17ab10429dfb10477ff9ba546db37727ea
This is necessary so that MultinetworkPolicyTracker can see
DeviceConfig. It will also allow removing reflection from
this file to address a long-standing TODO.
Test: build
Change-Id: I968bf67e0e0189b01515242371599c02bc9e2ca2
ClatCoordinator should not rely on the caller Nat464Xlat to
avoid dumping when clat is not started. It is safer to dump
information after ClatCoordinator has checked its status.
Only dumping ClatCoordinator with clatd started reduces the null
pointer check of dumped elements as well.
Test: atest ClatCoordinatorTest
Change-Id: Ia0be9a593cd75fd34f647230d642b0dcf84aaf3b
This test has been broken for a while. It tested:
- adding a listener triggers an interface state changed callback and an
ethernet state changed callback.
- setEthernetEnabled calls back the correct listeners and removes / adds
the interface.
Interface state listeners are already well covered in
EthernetManagerTest. I am currently working on adding tests for
setEthernetEnabled (there is partial coverage in setUp and tearDown of
EthernetManagerTest).
Bug: 242671512
Test: atest EthernetTrackerTest
Change-Id: Id1325a9056384444affb5c096cbc19d200ae0c4e
If a notification is up and the avoid bad wifi setting
is turned off, the notification should disappear.
This patch also adds some general tests for the bad wifi
notifications.
Test: new tests in this patch
Change-Id: I5bc42afbe0efd93cfb59a759bf0aaba49a4bfc9f
In the previous code, ConnectivityService would mark a network
a captive portal when NetworkMonitor sends it a message to notify
the user for it. Theoretically, this is incorrect ; instead, the
marking should be done upon receiving the message that the network
was tested to be a captive portal.
In practice this hasn't been a problem so far. The captive portal
capability is observable in the app-received callbacks, but for
these purposes the old code and the new code behave the same, in
that in the callbacks, the network used to not have the portal
capability, then later it acquires it.
However, this is only not a problem as long as the captive portal
bit isn't used by network selection, which an upcoming change has
to implement for the "prefer bad wifi" feature. When that is the
case, network selection prefers the wrong result between the time
the network is marked as having been evaluated and the time the
network has been marked a captive portal. It should be marked as
both at the same time to avoid this discrepancy. This is what
this patch is accomplishing.
To do this correctly, this patch also has to disconnect the network
immediately upon it being tested as a captive portal if the old
CAPTIVE_PORTAL_MODE setting is set to CAPTIVE_PORTAL_MODE_AVOID,
instead of keeping it until NM sends the message to notify about
it.
Unfortunately because of the relative timing of the events this
patch has observable impact on what callbacks are sent because of
b/245893397 (the DoubleValidated bug). Before this patch, there
would be an extra useless callback when a captive portal validates
where the capabilities contain both VALIDATED and CAPTIVE_PORTAL,
then a second callback removing CAPTIVE_PORTAL. This patch fixes
this, but unfortunately introduces a symmetrical extra useless
callback when a captive portal network starts matching a callback,
where onCapabilitiesChanged is fired a second time after the
onAvailable sequence with the same capabilities. Fixing this is
very complex ; the best (and simplest) solution is really to
address b/245893397 decisively.
In the mean time, the behavior implemented by this patch is better
than the old one, because there no longer is an observable state
where the network is supposed to be a closed captive portal AND
validated, but instead there is a useless, but correct, caps
callback that mirrors exactly the one from b/245893397. When
b/245893397 is addressed this behavior goes away at the same time,
so this is probably the better behavior.
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I6694db498507860e1d711e2aa0c591dfbfa90be2
* changes:
ethernet: cleanup updateConfiguration tests
ethernet: fix callbacks for running interfaces
ethernet: test callbacks when adding running interface
ethernet: ensure EthernetOutcomeReceiver receives only one result
ethernet: fix enable/disableInterface result
ethernet: remove enable/disable interface unit test
This unit test is not particularly useful and there is already coverage
in EthernetManagerTest.
Test: test only change.
Change-Id: I6f9d19d9603229553f44d562ff0276567cb0e26d
- Fix the wrong MOBIKE value set in
testStartPlatformVpnHandlesNetworkLoss_mobikeEnabled.
- Verify the networkAgent is unregistered when the default
network is lost
Bug: 231749077
Test: atest FrameworksNetTests:VpnTest
Change-Id: Idc6ebd42090eff1135dc5f96af4bc2fb268dd340
Starting to listen on the handler races with the rest of
the constructor. The class already has a #start() method
meant to start listening, so implement better practices
by leveraging this method.
Test: CtsNetTestCases
FrameworksNetIntegrationTests
FrameworksNetTests
Change-Id: I772f761d3ca5f9711b9d988e6330b0878814f491
This converts the key, which is an index in an array, of sConfigurationMap from U32 to S32.
Since the array has exactly 2 elements, there's no real difference.
In addition while the kernel does indeed index arrays with U32s,
it doesn't matter, because you'd need to have over 2 billion
elements in the bpf map (at which point you'd need GBs of ram for
the bpf map itself)...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If17efc25d910af642e519f9ecb6d0e8695c38d42
This converts the key, which is a uid, of sUidOwnerMap & sUidPermissionMap from U32 to S32.
The kernel is actually not consistent in whether uids & gids
are signed or unsigned, and neither is our Java code, which
also commonly uses just 'int' for uid. In practice values
greater or equal to 2**31 often don't quite work right.
For example icmp sockets are enabled via a sysctl that
takes a minimum and maximum gid - and these are signed int32s.
It's worth pointing out that these functions already accept int's
as arguments, so when converting them to U32 (and thus long) they
technically previously did the wrong thing (though it's unlikely
it ever mattered).
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7b389a1cf822c56134b20df5ded269963f5bf69f
The kernel is actually not consistent in whether uids & gids
are signed or unsigned, and neither is our Java code, which
also commonly uses just 'int' for uid. In practice values
greater or equal to 2**31 often don't quite work right.
For example icmp sockets are enabled via a sysctl that
takes a minimum and maximum gid - and these are signed int32s.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia309eb99f71765e30510d6a253c1329c20719f21
