* 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
This fix the code review comment from aosp/2319853 that getXXX functions
should be renamed to makeXXX because it's actually creating the object.
Test: TH
Change-Id: Ife8e1cc3a90b835764a2dd9731388b05d8a5c964
Markauthored and Mark Chiencommited 2023-12-04 09:02:55 +00:00
Currently, PrivateAddressCoordinator always selects the /24 prefix
from the 192.168.x.x/16 range first. If the upstream is also a /24
prefix in the 192.168.x.x/16 range, there's a 1/256 chance of a
conflict (192.168.0.x/24 ~ 192.168.255.x/24). Since 192.168.x.x/16
is a popular range for home and small business networks, we should
randomize the starting prefix range to reduce the chance of a
conflict. The /8, /12, and /16 range selection rates are 0.39%,
5.86%, and 93.7%, respectively (see the inline comments for how
the rates are calculated).
The chance of selecting a /24 prefix is:
- 10.0.0.0/8: 1/(256*256) * 93.7% = 0.001429%
- 172.16.0.0/12: 1/(16*256) * 5.86% = 0.00143%
- 192.168.0.0/16: 1/256 * 0.39% = 0.001523%
Note: This change is currently turned off by the
tether_force_random_prefix_base_selection flag. We'll run experiments
to make sure tethering stays reliable with this change enabled.
Bug: 312647670
Test: atest TetheringTests
Change-Id: Iea03fdcf0fccad95410e79ae87fcb046d75da457
The code currently calls RandomInt twice to generate an address.
For example, if you want to generate the address 192.168.A.B,
RandomInt will be called twice to generate the values for A and B.
To save resources, we can avoid calling RandomInt twice by reusing
the same random value with different masks for A and B.
Before:
- RandomInt() & 0xff00 -> A
- RandomInt() & 0x00ff -> B
After:
- RandomInt() & 0xffff -> A.B
Bug: 312647670
Test: atest TetheringTests
Change-Id: Iee49af3d82781309f78fe66ab07937b8137fa259
Markauthored and Mark Chiencommited 2023-11-24 03:10:11 +00:00
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
Instead of passing state machine to UpstreamNetworkMonitor, wrapped it
by an interface would have two benefits:
1. Easier for testing.
2. Isolate state machine operation in callback.
Test: atest TetheringTests
Change-Id: I2a97fd5cbc8c49df8c3c98428c6570916ab31ea5
TetherUpstream6Key#src64 should be stored in network order. Use
a big-endian ByteBuffer to retrieve a value stored in network order
is actually converts it into native order, which is little-endian in
Android.
In this CL, we changed it to use byte[] instead of long to store the
top 64-bits of the source prefix.
Test: atest TetheringTests
manual test with IPv6-only tethering upstream, check BPF stats.
Bug: 312072637
Change-Id: I79f9282d5eda28328aa6a764ea92b086d6285133
FileDescriptor#getInt$() is a hidden API with the unsupportedApiUsage
annotation on R. Accessing it will cause a NewApi linter check error.
It should be removed from OffloadHalHidlImpl as it is only used for
log messages.
Bug: b/205762647
Test: m
Change-Id: Ie41d12988aee65a066dfb1529e828f4523cc0907
Avoid passing primitive data types into Objects.hash() which will
convert them to their corresponding object wrapper types
automatically.
Test: atest TetheringTests
Bug: 261923493
Change-Id: I2efe7f3e50923ad2e33cfd58ae7e1e1cf7fd34bd
This can be used from S. There is no point in having a
release name in the name of this class.
Test: builds
Change-Id: I301bf032f856dd4c30554e06013f31ee57208c4e
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
This can make it easier to adopt SM shim replacement in follow up change,
as both SyncSM and AsyncSM will process the same message without any
difference.
This change also fix a problem that bring up downstream before it's
IpServer completely disabled.
Previous:
CMD_NOTIFY_PREFIX_CONFLICT -> requestEnableTethering(false) ->
requestEnableTethering(true) -> IpServer stopped ->
reportTetherStateChanged(downstream inactive) -> IpServer started
-> reportTetherStateChanged(downstream active)
New:
CMD_NOTIFY_PREFIX_CONFLICT -> requestEnableTethering(false) ->
IpServer stopped -> reportTetherStateChanged(downstream inactive)
-> requestEnableTethering(true) -> IpServer started
-> reportTetherStateChanged(downstream active)
Test: atest MtsTetheringTestLatestSdk
Change-Id: Ibe22b300c56125359f4fa452bd01a0a2381fda23
After this change, all synchronous state machine functions are
implemented.
There are some intentional limiations:
1. Allow setup states before machine thread started or inside machine
thread but states can only be setup once before calling #start.
2. The behavior of transitionTo is defined so that the destination
state can never change during state transitions. Once a destination
has been specified, it cannot be changed until the previous state
transition is complete. In other words, SyncStateMachine does not
support calling transitionTo in State enter or exit.
3. Support sendSelfMessage in State#processMessage(), #enter() and
#exit(). This allow automaton to decide the follow up action by
itself. For example: if something wrong happens during state
transition, the implementation can enqueue an error message then
process the error message after finishing the current state
transition.
Test: atest SynStateMachineTest
Change-Id: I0790df4eeab2dccdb9f407d9131a62c3c12d123b
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
Implement performTransitions which does state transitions.
1. Determine the common ancestor state of current/destination states
2. Invoke state exit list from current state to common ancestor state.
3. Invoke state enter list from common ancestor state to destState by
going through mEnterStateStack.
The state transition is always defined so that the target can never be
changed mid-way of a state transition. In other words, calling
transitionTo in State enter and exit is not allowed.
Test: atest SyncStateMachineTest
Change-Id: I51e8c5440a8b9ac25715c3d030717421f68c15b3
This change adds SyncStateMachine class and provides the user
interface but doesn't have the details implementation.
Test: m
Change-Id: Ic2fa69b9e6424601fc2df2d07a052f48a6a46370
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
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
DeviceConfigUtils has isFeatureEnabled for NetworkStack and Tethering
which were confusing since the difference was only the arguments.
This CL renames isFeatureEnabled for Tethering module to
isTetheringFeatureEnabled to avoid confusion.
Bug: 279108992
Test: m
Change-Id: I05255bb38619afbe621d29524d7910d206a149f1
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
Yuyang Huang
authored and
Gerrit Code Review
commited 
KH Shi
commited 
Mark
commited 
Treehugger Robot
authored and
Motomu Utsumi
commited 
Chalard Jean
commited 
Maciej Żenczykowski
authored and