This CL splits requestDownstreamAddress into two methods: requestStickyDownstreamAddress and requestDownstreamAddress.
- The requestStickyDownstreamAddress is equivalent to the former requestDownstreamAddress when useLastAddress=true.
- The new requestDownstreamAddress method allows allocating an address without providing the interface type and scope, which is Thread NAT64's use case.
Bug: 369282577
Change-Id: Ib839d121c7b46c492f2c4c1c61b52b5d017fa055
API
This CL refactors IpServer to allocate IPv4 address via RoutingCoordinatorManager
instead of directly talking to PrivateAddressCoordinator class.
Bug: 350699020
Change-Id: I5c68620626a3668c079234da232f0ef2beb46628
* changes:
Remove unused method TetheringConfiguration#isRandomPrefixBaseEnabled()
PrivateAddressCoordinator: introduce Dependencies class
PrivateAddressCoordinator: move the special handling of WiFi P2P dedicated IP to IpServer
Treehugger Robotauthored and Gerrit Code Reviewcommited 2024-10-08 17:07:29 +00:00
dedicated IP to IpServer
The source of
TetheringConfiguration#shouldEnableWifiP2pDedicatedIp is in the
Tethering's resources. As refactoring the code, we noticed that it will
be simpler to handle this at IpServer (constructed using
TetheringConfiguration) instead of at PrivateAddressCoordinator
(will require reflection to read the Tethering's resources).
Bug: 369282577
Change-Id: I7b766ef6a769043c2a4ca11741db5c16c5c57071
Technically, UnavailableState should not handle any messages at all (and
shouldn't exist). As the IpServer has already been removed from
mTetherStates. However, sendInterfaceState() cleans up IPv6 tethering
which eventually triggers a CMD_IPV6_TETHER_UPDATE. Instead of
preventing the CMD_IPV6_TETHER_UPDATE, ignore it for now and remove this
state entirely once we have rolled out SyncStateMachine.
Bug: 368713124
Test: TH
Change-Id: I32ae9583aa01411fa1fc299a0fc91138557b7ae2
The break is missing when processing CMD_SERVICE_FAILED_TO_START
in BaseServingState.
Test: atest TetheringTests
Change-Id: I1699da251f90ec447466266b704df24d081c40b3
On Android R, IpServer uses netd to set up tethering while on S+ it uses
RoutingCoordinator.
This CL lets Tethering own a RoutingCoordinatorService when the SDK
version <= R so IpServer can always use RoutingCoordinator instead of
netd.
Bug: 350699020
Test: CI
Change-Id: I0ed33fb050260c26be87079bed0e189716cd8782
- This CL puts RoutingCoordinator into staticlibs to make it usable by
both Tethering and ConnectivityService on R.
- This CL also changes the return type of
ConnectivityInternalApi#getRoutingCoordinatorManager() to IBinder so
it has fewer dependencies.
Bug: 350699020
Test: CI
Change-Id: Iba096e940795cd33e61c5141721394ad39e5ce6d
Replace TetheringRequestParcel with TetheringRequest in the service
code. This makes future changes easier since TetheringRequest is a
proper class and not an AIDL object.
Bug: 216524590
Test: atest TetheringTest TetheringManagerTest
Change-Id: I0cdee597d393e53feb9fe9aff4d6c67330c88599
Quang Anh Luongcommited 2024-06-26 16:25:13 +09:00
* changes:
Clean up BpfCoordinatorTest after refactors
Move upstream interface BPF support check to BpfCoordinator
Refactor BPF map update logic of upstream interface change
Centralize IP neighbor monitoring in BpfCoordinator
Get rid of BpfCoordinator#mPollingStarted
KH Shiauthored and Gerrit Code Reviewcommited 2024-06-22 12:34:34 +00:00
Removed upstream interface BPF support check from IpServer and moved
it to BpfCoordinator. The support check can be performed directly in
BpfCoordinator using the interface name.
Test: atest TetheringTests
Bug: 294025403
Change-Id: Ia51bc3ab18dd21afdca9db9199fa060aab68f768
This CL centralizes IP neighbor monitoring in the BpfCoordinator,
eliminating the need for redundant monitors in each IpServer.
Test: atest TetheringTests
Bug: 294025403
Change-Id: Ie6fbc3eeaa0ed4a34a6680714f44678e2d5b633a
Refactor IpServer/BpfCoordinator to remove mPollingStarted, and just
maintain the invariant that "data usage polling and conntrack
monitoring are running iff at least one IpServer is serving".
Test: atest TetheringTests
Bug: 294025403
Change-Id: I55064ee78e1cda12ad76b7c31496d760dcffdd76
Check out #isLoggable from frameworks/base/core/java/android/util/Log.java to
learn how to enable the log.
Bug: 329552689
Change-Id: I86ce0dae947cf56da069dfe3145ef074de11217e
Test: TH
This reverts commit cf11be9eb2.
Reason for revert: avoid some IpServer(s) running the new sync state machine while others use the async state machine.
Bug: 319212113
Change-Id: Ib086a7ccd102f38e579c79f94aceae9971f1853a
Mark Chienauthored and Markcommited 2024-01-22 11:34:14 +00:00
* changes:
Revert "Refactor RouterAdvertisementDaemon with FdEventsReader"
Revert "Refactor RouterAdvertisementDaemon to build new RA in HandlerThread"
Yuyang Huangauthored and Gerrit Code Reviewcommited 2023-12-20 08:14:12 +00:00
This reverts commit bdcd7db9d8.
Reason for revert: Design changes, don't use extra Handler in RouterAdvertisementDaemon.
Change-Id: I4888f8f22aea2cadbb6064e63f872c605025930f
This reverts commit 23a2158c38.
Reason for revert: Design changes, don't use extra Handler in RouterAdvertisementDaemon.
Change-Id: Iba829ec028e887b6625f4f972e936ca5757a7614
KH Shiauthored and Gerrit Code Reviewcommited 2023-12-20 06:25:54 +00:00
The logic is currently disabled by default, adding a flag so
that we can compare result with A/B rollout.
Test: atest TetheringTests
Change-Id: If640b9a172b97aa67c49b2976cdef118218f1e0f
HandlerThread was introduced in aosp/2493357. This patch moves the
code originally located in buildNewRa() into the HandlerThread.
Bug: 246928127
Test: atest TetheringPrivilegedTests TetheringIntegrationTests \
TetheringTests
Change-Id: I5f6df0a3a79d7f4a865cfec7f88bc28816b1db95
This patch changes the implementation of UnicastResponder in the
RouterAdvertisementDaemon with FdEventsReader. The change includes
replacing Thread with HandlerThread, create socket in non-blocking
mode (required by FdEventsReader) and use FdEventsReader to listen
to the solicited RS packets. Two commands (CMD_START & CMD_STOP)
were added to control the lifecycle of the FdEventsReader.
Bug: 246928127
Test: atest TetheringPrivilegedTests TetheringIntegrationTests \
TetheringTests
Test: Enable WiFi hotspot and connected with another Pixel client:
1. Tcpdump on the Pixel client, checking the RA packets
2. Verify IPv6 addresses were configured
3. ping6 2001:4860:4860::64
Change-Id: I6e89903df90864e3bb34d498e353d6f87193e9d6
ArraySet is designed to be more memory afficient than HashSet. It is
suitable to store small numbers of items.
Test: atest TetheringPrivilegedTests TetheringIntegrationTests \
TetheringTests
Bug: 261923493
Change-Id: I2bd2eded801cc05ce53ef9f9486b13faf1772d22
This reverts commit 55ccfe19e2.
Reason for revert: this must be introducing some sort of race
it appears to cause
atest EthernetTetheringTest 'NetdBinderTest#TetherForwardAddRemove'
to no longer reliably pass.
Change-Id: I5281ab3f42c5ce268d97a12db24a6768db3f4354
Maciej Żenczykowskiauthored and Gerrit Code Reviewcommited 2023-10-28 02:10:52 +00:00
BPF needs upstream prefixes information to filter spoofing IPv6 source
addresses carried in downstream traffic.
We retrieve prefixes from upstream interface's LinkProperties and pass
it to the BpfCoordinator. Forwarding rules will also be updated when
upstream interface's IPv6 link addresses change.
Test: atest TetheringTests
Bug: 261923493
Change-Id: If8cfc3b191e520ca838654d1b5211ab9e9ec021d
As state transitions always occur after a message has been processed,
calling transitionTo only under processMessage makes the flow easier
to understand and less error-prone.
The risk of this change is very minimal since it is only about
handling the error, but tethering will stop regardless.
Test: atest TetheringTests
Change-Id: I56c6cf6cc989464ee84a8333ac131afc808a3d95
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
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
The original code requires updating mLastIPv6LinkProperties before
calling updateIpv6ForwardingRules because mLastIPv6LinkProperties will
be used inside an internal function later. Remove this unnecessary
dependency by passing the interface name into the function.
Bug: 294025403
Test: atest TetheringTests
Change-Id: I5699fba3d7caf3314d102b643b02da2b2797dd66
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
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
As the suggestion from:
https://android-review.git.corp.google.com/c/platform/packages/modules/Connectivity/+/2489359/9/Tethering/src/android/net/ip/IpServer.java#b1176
Make BaseServingState an abstract class to prevent it from being used
directly. Additionally, move the handleNewPrefixRequest method into
BaseServingState because it is the only class that uses it.
To avoid TetheredState and LocalHotspotState from having to implement
their own enter function, add the mDesiredInterfaceState field to
BaseServingState.
Bug: 233175023
Test: atest TetheringTests
Change-Id: I03269c37e666345efb0c61039a2bb213f223a5a2
Markauthored and Mark Chiencommited 2023-05-24 17:00:41 +00:00
The TODO is used to track to dynamically pass down the TTL from the
upstream interface. Remove it as it was already done in IpServer.
Test: No code changes
Change-Id: Idb12f82023315661f1bf4c767b9b7744a151e821
Currently we have 300s..600s RA interval, so ~450 seconds,
and a 6 * 600s, ie. 3600s (1h) lifetime.
This means on average about 8 RAs during the lifetime.
APF's FRACTION_OF_LIFETIME_TO_FILTER is 6, so the first
3600s / 6 = 600s of RAs are filtered out by a hotspot client
Android device. This means we really only get 3600s - 600s = 3000s
worth of RAs (after the initial one).
Hence, the client will get approximately 3000s / 450s = 6.666 RAs.
Thus, assuming a clientside DTIM multiplier of just 2, the client
phone only needs to fail a 50/50 coin toss 6 times in a row to
lose all 6 of those RAs.
That's a 1 in 2**6 = 64 chance, and it gets rerolled every ~450s.
Per https://www.codechef.com/wiki/tutorial-expectation
expected number of coin flips for getting N consecutive heads is:
2**(N+1) - 2
N=6 --> 2**7-2 = 126
126 * ~450s = 56700s = 15.75h
This means failure is expected roughly on the order of 16 hours.
By doubling the lifetime from 1h to 2h, we effectively double
the number of RAs, and lower the failure chance from 1 in 2**6,
to 1 in 2**13, which is 1 in 8K and thus much less failure prone.
N=13 -> 2**14-2 = 16382 --> failure expected after ~85 days
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I70db3096db5666bca0c248f2d49f801f333514b3
Maciej Żenczykowskicommited 2023-02-16 22:56:25 +00:00
Handa Wang
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Patrick Rohr
commited 
Paul Hu
commited 
Quang Anh Luong
commited 
KH Shi
authored and
Mark Chien
commited 
Yuyang Huang
authored and
Motomu Utsumi
commited 
Chalard Jean
commited 
Maciej Żenczykowski
authored and
Xiao Ma
commited 
Chiachang Wang
authored and