If either enableNat() or startInterfaceForwarding() fail, be sure
to cleanup any commands that might have succeeded.
Most of this change is a refactoring of cleanupUpstreamIface() into
two methods, one of which (cleanupUpstreamInterface()) is reused
in error handling scenarios.
Test: as follows
- built (bullhead)
- flashed
- booted
- runtest -x .../tethering/TetherInterfaceStateMachineTest.java passes
Bug: 32031803
Bug: 32163131
Change-Id: Ia4d56e03beeab1908d8b8c2202e94992f1aa58a4
The test calls that need to pass but do not currently are commented out.
Test: as follows
- built (bullhead)
- flashed
- booted
- runtest -x .../tethering/TetherInterfaceStateMachineTest.java passes
Bug: 32031803
Bug: 32163131
Change-Id: I68ed476920bef882f353d8e8a54c72120bc27002
This static method returns a NetworkCapabilities instance with
transports and capabilities set according to the given legacy type.
Also:
- add NetworkRequest.Builder.setCapabilities(), to be able to use
the NetworkCapabilities instances returned from the above
- update UpstreamNetworkMonitor to make immediate use of this
Test: as follows
- build (bullhead)
- flashed
- booted
- runtest frameworks-net passes
- WiFi to DUN upstream tethering works
Bug: 32163131
Change-Id: Idfe1ddd2815c355cbf27cf29eb0e3de177de84e9
This allows an application that knows how to provide seamless
network connectivity (e.g., using QUIC multipath) to find out if
doing so is desired.
Test: builds, boots, runtest frameworks-net passes.
Bug: 34630278
Change-Id: Ic7fd0b9e1cd879fdfaf84009d7125391895e9087
All the tests are now asynchronous. The only remaining uses of
Thread.sleep() are in the tests that check for NetworkRequest
timeouts.
Test: ConnectivityServiceTest passes 100 times in a row
Bug: 32561414
Change-Id: If420bd66c692a90d5031ee06a888a8cc3b4398a8
The calls in testAvoidBadWifi are no longer necessary now that
waitForIdle is reliable, and the calls in testPacketKeepalives
are replaced with a wait for the NetworkAgent to disconnect.
Test: ConnectivityServiceTest passes 100 times in a row.
Bug: 32561414
Change-Id: Icbb161ca6e343bd14764a1c9ccfdd14b6cd6803f
Rename the class and ensure that all code related to bad wifi
avoidance has names that reflect its purpose. This will allow us
to reuse most of the the code for other purposes in future CLs.
Test: runtest frameworks-net passes
Bug: 34630278
Change-Id: Ida190e5a79e7a12f4eec07e1a3e4d9d138e83bcd
The current implementation of IdleableHandlerThread is based on
the assumption that MessageQueue#isIdle will return true iff the
message loop has finished processing its messages.
Unfortunately, this is incorrect: isIdle returns true iff are no
more messages waiting in the queue; thus, it will also return
true while it is processing the last message before going idle.
Instead of using idle handlers, take the simpler approach of
posting a runnable to the message loop and waiting for it to
be processed.
Test: see other CLs in this patch series
Bug: 31479480
Change-Id: Iae75781f067b762c8653a488a5e4d5ee0c789e01
testApfFilterRa is failing with probabiliy 1/10 ~ 1/15 on the following
assert: assertDrop(program, packet, lifetime/6), for lifetime values
that are multiple of 6, where 6 is the hardcoded fraction of RA lifetime
to filter in ApfFilter.java.
When the lifetime is not a multiple of 6, the remainder of 1 to 5
seconds gives enough margin so that when the APF program is simulated
the faked lifetime of the program is less than lifetime/6 away and the
packet is dropped.
However for lifetimes which are exact multiples of 6, this margin is
always 0s and that result in nondeterminism in the result. This is
consistent with the obervation that the only failed assert was for a
lifetime of 300s, the only multiple of 6.
This can be observed by detecting the age limit at which the filter
stops dropping packet oscillating between lifetime/6 and lifetime/6 + 1
for lifetimes which are multiple of 6.
This patch fixes the flakyness by freezing the flow of time in tests so
that the expected filter age threshold is consistent and stable.
Test: no failure observed in 1000 runs.
Bug: 32561414
Change-Id: I5251d047039f34b82ce8a5d20ae46563e1e0cce8
