A initial test for SyncStateMachine, will add more tests in the
following changes.
Test: atest SyncStateMachineTest
Change-Id: Ie6dbbe22bfef40b1675d50243d14d0a235df1e3a
Currently, Ipv6UpstreamRule is added follows the adding of
Ipv6DownstreamRule when it is the first rule from a downstream
interface to the upstream interface.
This CL changed it to:
1. Upstream interface change updates both IPv6 upstream and downstream
forwarding rules.
2. Neighbor events updates only IPv6 downstream forwarding rules.
Data limit setting on the upstream interface is now depend on the
upstream rules instead of the downstream rules. This CL also updates
corresponding test cases in IpServerTest and BpfCoordinatorTest.
Test: atest TetheringTests
Bug: 261923493
Change-Id: I5b4df64a3d276afb7a24bbef3a0432f53377e8b2
This CL also updates not to use isTetheringFeatureEnabled for
TETHER_FORCE_UPSTREAM_AUTOMATIC_VERSION which is wrongly configured in
Connectivity namespace.
Test: m
Bug: 279108992
Change-Id: If4f3a57c749bbaeb85454c31248c5bc5feaab936
In current code, IpServer will ensure bpf offload is supported before
calling BpfCoordinator's APIs. But those APIs already have the same
checks inside the function. This CL removed duplicated checks in
IpServer.
After this change, the BPF offload support status is only determined
inside BpfCoordinator and it won't change during the life cycle of
Tethering. Tethering initializes mBpfCoordinator just once in the
constructor. After that point, the value of isUsingBpf can never
change, because mIsBpfEnabled is final and
mBpfCoordinatorShim.isInitialized() is either always true (api30) or
can either never change (api31).
Also fixed a bug in IpServerTest upon this change.
Test: atest TetheringTests
Bug: 261923493
Change-Id: I50f231a83bf678b90eae4fd9bfa6035e86978bb3
Replaced startUpstreamIpv6Forwarding and stopUpstreamIpv6Forwarding
with add/remove Ipv6UpstreamRule. This is a preparation for following
CLs which will pass the upstream's prefixes to the bpf map. We might
have more than one upstream rules.
Also renamed Ipv6ForwardingRule to Ipv6DownstreamRule since we have
defined the Ipv6UpstreamRule.
No logic changes are being made in this CL.
Test: atest TetheringTests
Bug: 261923493
Change-Id: I022f97c2daf468bbd4a4279a069ccf498013e7e7
This patch is based on aosp/2535559 from maze@.
Add source prefix into the upstream key such that only packets which
source IPv6 address matches it will be forwarded to the upstream
interface.
In this patch, the source prefix is set to zero so there is no
behavior changes. Next CL in patch series will use the real source
prefixes retrieved from upstream interface.
Test: atest TetheringTests
Bug: 261923493
Change-Id: I43d068a29b937c7dfeb6fab632a8effb47ee2263
NativeHandles shouldn't be closed in OffloadHardwareInterface after
passing them to initOffload() of AIDL service, because their owner
will be changed to ParcelFileDescriptor by libbinder.
Add test cases to verify that NativeHandles are closed correctly.
NativeHandles should be closed after initOffload if:
- Init with HIDL HAL interface
- Has null NativeHandle, any non-null NativeHandles should be closed
Bug: 277834236
Test: atest OffloadHardwareInterfaceTest
Change-Id: Icbe74da73d3bdc582d1816b314fdfce9661465fc
Different network objects with the same network ID should be
treated as the same network.
chooseUpstreamType compares the current upstream and new upstream
by object (comparison operator) instead of network id
(Network#equals). This implies that different objects with the
same network id still trigger upstream changed report.
Since this commit, reportUpstreamChanged is only called when upsteam
has really changed (connected, switched or disconnected) in
chooseUpstreamType. In previous code, reportUpstreamChanged is also
called if EVENT_ON_CAPABILITIES is called when the upstream is the
same but its capabilities changed.
The NotificationUpdater#onUpstreamCapabilitiesChanged method only
needs to be called by chooseUpstreamType when it chooses a new
upstream. If the upstream remains the same but its capabilities
change, the EVENT_ON_CAPABILITIES will call
onUpstreamCapabilitiesChanged.
Bug: 243516306
Test: atest TetheringTest
Change-Id: I009383a61a5fabd249ba78fcffd524a5bbe4602e
Hungming Chenauthored and Markcommited 2023-06-19 06:51:03 +00:00
A test to verify that SAP and LOHS can use different IPv4
addresses if they are both enabled.
Bug: 233175023
Test: atest TetheringTest
Change-Id: I40f0f35221a76e6593cc8d04e9f2b25df8c27c87
A test to confirm that connected clients are updated when SAP
and LOHS are enabled simultaneously.
Bug: 233175023
Test: atest TetheringTest
Change-Id: I920f02e5b2ad137af529776141d51b6c83b8ea5b
Use type + scope as key to build cached address map so that
SAP (key: TETHERING_WIFI + INTERNET) and LOHS
(key: TETHERING_WIFI + LOCAL) can use different address.
Bug: 233175023
Test: atest TetheringTests
Change-Id: I46a4b3ee919628092b7540202a43d79f407b09b6
This change store localOnly wifi clients in its own field so that
tethered and localOnly hotspot clients can exist at the same time.
Currently, there are no tethered and localOnly hotspot clients at
the same time because PrivateAddressCoordinator does not support
SAP + LOHS. A follow-up change will be made to allow this.
When both SAP and LOHS are enabled, the SAP and LOHS clients from
TetheringEventCallback#onClientsChanged are all TETHERING_WIFI.
Currently, there is no way for the listeners to distinguish between
SAP and LOHS clients.
Bug: 233175023
Test: atest TetheringTests
Change-Id: I01b0a6abb084f7135f7825e0c5303e49c16a4c39
Starting with U, only explicit intents will be allowed to
launch non-exported internal components. Set package name
to entitlement recheck intent so that the intent could be
delivered to tethering itself successfully.
Bug: 278482046
Test: atest TetheringTests
manual verify entitlement recheck work in U
Change-Id: Ife30eee13fe39509ccb5786d2a76fbb7baa022a8
This change centralized some common test codes to
verifyHotspotClientUpdate() to facilitate the following
commit for softap+lohs
Bug: 233175023
Test: atest TetheringTests
Change-Id: Iee3905084b244b91abdf7c562d77b5054d58ff6a
Address a TODO in TetheringConfiguration to use a dependency object
instead of static mocking on DeviceConfig.
This avoids TetheringConfiguration dependencies on internal
implementation of DeviceConfigUtils, unblocking changes in
DeviceConfigUtils.
Bug: 279108992
Test: atest TetheringTests
Change-Id: I252eaadff85fa47b894e989b4f2527b00c5dca56
Remi NGUYEN VANauthored and Motomu Utsumicommited 2023-04-28 19:18:43 +09:00
This commit adds two new fields, tx_bytes and rx_bytes, to the
UpstreamEvent message. These fields provide information about the
amount of data transferred during the event, which can be useful for
network performance analysis. The current tx/rx usages are always
zero, but it will be updated in a later change to reflect the actual
usage. No changes were made to the existing fields upstream_type and
duration_millis.
Test: atest TetheringMetricsTest
Change-Id: I9e1043b3fff5aa3f548b8696bac7e5bc4271c77c
Add the AIDL HAL service interface support and abstract the HIDL/AIDL
interface implementations to allow OffloadController to talk to both
interfaces.
Bug: b/205762647
Test: atest com.android.networkstack.tethering
atest ConnectivityCoverageTests
atest ConntrackSocketTest
Change-Id: If7634a298d03668ed70b328f1ad6ca0ac0fe170b
Somewhat surprisingly, HandlerThread#quitSafely is *not* a synchronous
method, so the tearDown() method still needs to wait for the thread to
join.
Test: TH
Change-Id: I0433e2100adf9299a67af5c259a518cf44f4be57
In testUpstreamCapabilitiesChanged, verify that
onUpstreamCapabilitiesChanged is called just after which function
triggered onUpstreamCapabilitiesChanged.
Bug: 243516306
Test: atest TetheringTest
Change-Id: Icd871654455033475092b9e7376b604cb0ba00eb
The duplicated upstream change event on the same network is a bug
which needs to be fixed.
Bug: 243516306
Test: atest TetheringTest
Change-Id: I7c70328d937877ec9832a2764cfb331561ee34b6
UpstreamNetworkMonitor#setCurrentUpstream is going to be removed
because UpstreamNetworkMonitor#mTetheringUpstreamNetwork is unused.
Use tethering event callback to check upstream change.
Bug: 243516306
Test: atest TetheringTest
Change-Id: I5773cfc80190b554a3b63b4f827c220b0e663427
This is a preparation for migrating the upstream change notification.
Changes:
1. Modify testUpstreamNetworkChanged
- Add losing upstream test
- Verify the capabilities on the explicit network
2. Modify testUpstreamCapabilitiesChanged
- Verify the capabilities on the explicit network
3. Add testUpstreamCapabilitiesChanged_stopTethering
- Test that TetherModeAliveState#exit sends the null upstream
notification. Above tests only covers the notifications which
are triggered by chooseUpstreamType or EVENT_ON_CAPABILITIES.
Bug: 243516306
Test: atest TetheringTest
Change-Id: I8f5b23f93c27b8c690b2fd275e3f636fbaeb4973
* changes:
Tethering: deprecate CONNECTIVITY_ACTION on U+ device
Test: add tests to testChooseDunUpstreamByAutomaticMode_*
TetheringTest: separate setup func from chooseDunUpstreamTestCommon
Treehugger Robotauthored and Gerrit Code Reviewcommited 2023-01-13 08:41:20 +00:00
TestTetheringEventCallback may use assertEquals(actual, expected)
but assertEquals(expected, actual).
It is confused while test is failed.
For example:
Code:
callback.expectUpstreamChanged(new Network[] {null} /* expected */);
Before:
java.lang.AssertionError: expected:<100> but was:<null>
After:
java.lang.AssertionError: expected:<null> but was:<100>
Bug: 243516306
Test: atest TetheringTest
Change-Id: I6a987e4dd1cccc5e79da7dda55f194291e0c4a60
This test relies on forceGc to free and finalize the TetheringManager
before perform validation checks. In some test suites, if there were
already too many unused objects accumulated in the system before
running the test, it might take more than 5 seconds to free them.
Increase the maximum retry time to 30 seconds to fix the flakiness.
Bug: 263335396
Test: atest TetheringServiceTest#testTetheringManagerLeak
run the flaky test suite on ABTD with CL
Change-Id: I38bee3d43fbeb278993d113ccbe0645aedc5d75d
Respect the upstream interface mtu instead of always setting
mtu 1500.
Using upstream interface mtu is probably not the best solution
for tether offload pmtu but it at least respects the upstream
interface mtu which may be less than 1500.
Test: manual test
1. Connect to carrier Taiwan Star.
2. Enable tethering and check the mtu 1434 in dumpsys.
IPv4 Upstream: proto [inDstMac] iif(iface) src -> nat ->
dst [outDstMac] pmtu age
udp [02:10:45:32:ef:35] 54(54) 192.168.72.125:39034
-> 15(rmnet1) 100.83.189.11:39034
-> 142.251.43.14:443 [00:00:00:00:00:00] 1434 69657ms
IPv4 Downstream: proto [inDstMac] iif(iface) src -> nat
-> dst [outDstMac] pmtu age
udp [00:00:00:00:00:00] 15(rmnet1) 142.251.43.14:443
-> 54(54) 100.83.189.11:39034
-> 192.168.72.125:39034 [9a:8a:4d:ec:a4:7c] 1434 69633ms
Bug: 262860312
Test: atest BpfCoordinatorTest
Change-Id: Ic6dcb95ed76d5306053e4645b6baebc67ff082cf
Mark
commited 
KH Shi
authored and
Gerrit Code Review
commited 
Motomu Utsumi
commited 
Treehugger Robot
authored and
Xiao Ma
commited 
Hungming Chen
authored and
Remi NGUYEN VAN
authored and
Wayne Ma
commited 
Patrick Rohr
commited 
Treehugger Robot
authored and
Maciej Żenczykowski
authored and