This change includes:
1. Refactor the logic in Tethering#dump into utils class.
2. Move the utils class to a common place which could be referenced
from other sub-modules.
3. Add @MonitorThreadLeak annotation to enforce
there is no thread leak problem.
Test: atest FrameworksNetTests NetworkStaticLibTests
Test: atest ConnectivityCoverageTests:com.android.networkstack.tethering.TetheringTest#testDumpTetheringLog
Test: adb shell dumpsys tethering (with hardcoded exception)
Fix: 312669345
Change-Id: Ia6fdfeeec2110afa0ec9e056e9db3843748845c3
The first tethering test case might have a tethering restart when
handling IP conflicts. Currently, we start a hotspot once before
tethering, but the test is still flaky in Cuttlefish because it
doesn't support hotspots. Instead, we'll start ethernet tethering.
Bug: 254183718
Test: atest CtsTetheringTest
Change-Id: I695d4e1b3f961893bc30b3144faf7ad7d2d70574
Markauthored and Mark Chiencommited 2023-12-27 08:57:57 +00:00
Before making enableEthernetTethering a static function, make its
dependency variable static.
Bug: 254183718
Test: atest CtsTetheringTest
Change-Id: Id3781d67b3abc69b146fa704d4795bcfb2431a2a
Markauthored and Mark Chiencommited 2023-12-27 03:50:32 +00:00
This implements a basic border routing test case (ping) and demonstrates a
valid test environment for Thread Border Router test cases.
Later we can add more packet verifications and more test cases.
Bug: 295843010
Test: atest android.net.ThreadBorderRouterTest
Change-Id: Ifb9b6d45539143a227c2bc0ed69b5c3167ef9acd
lintable modules currently pick up files named "lint-baseline.xml" to use as the
lint baseline implicitly. This is confusing because you could end up using the
baseline files in more modules than intended. Lint also has a feature where it
requests you remove unnecessary findings from the baseline file, so something
could be necessary for one module, but unnecessary for another that accidentally
picked up the baseline.
We're removing the implicit detection of the baseline file, which requires
all modules using it to list the baseline file explicitly.
Bug: 272769514
Test: Presubmits
Change-Id: If873a4ea20d73bb6268d83589c4fb3ebe54af664
* 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
Yuyang Huang
authored and
Gerrit Code Review
commited 
Junyu Lai
authored and
Mark
authored and
Handa Wang
commited 
Cole Faust
authored and
KH Shi
commited 
Automerger Merge Worker
commited 
Xin Li
commited 
Motomu Utsumi
authored and
Treehugger Robot
authored and