When forwarding is on, DadProxyTest fails because forwarding
disables optimistic addresses. This results in the DAD proxy
getting EADDRNOTAVAIL.
Forwarding is on quite often on real hardware because many
solutions for wifi calling use forwarding.
Fix the test to retry after two seconds if the packet is not
forwarded on the first attempt.
It would also be possible to make this work more reliably in the
test by simply disabling DAD or disabling forwarding. However,
because DAD does happen in real usage (downstream interfaces
always disable DAD, but upstream interfaces don't), that seems
risky. For example, if the test disabled DAD, it would not catch
bugs where the DAD proxy crashed or stopped forwarding if it got
EADDRNOTAVAIL.
Test: atest TetheringPrivilegedTests on coral, which has forwarding on
Change-Id: I58280ef7c0e40371cd770ead4c8baa7190c288fd
Current upstream selection code suffers from a race where if the
CONNECTIVITY_ACTION broadcast for a given network switch is
received and processed before the NetworkCallbacks for that
network switch, upstream selection just re-selects the same
upstream it had before. The incorrect upstream persists until
another CONNECTIVITY_ACTION is received.
Fix this by defining a new EVENT_DEFAULT_SWITCHED message code
communicated from UpstreamNetworkMonitor to Tethering, and send
that whenever the default network switches.
The message is sent in onLinkPropertiesChanged, because the
tethering code stores all information about networks in an
UpstreamNetworkState structure that contains Network,
LinkProperties and NetworkCapabilities. When a network switch
occurs, onLinkPropertiesChanged always follows onAvailable and
onCapabilitiesChanged, and thus marks the first point in time
when all the information is available.
This CL tries not to change existing codepaths too much, but
it does move the update of mDefaultInternetNetwork from
onCapabilitiesChanged to onLinkPropertiesChanged. This should
not be a problem because the only thing that reads
mDefaultInternetNetwork is getCurrentPreferredUpstream, which,
in the case of a default network switch, will be run by the
onLinkPropertiesChanged which will immediately follow.
Bug: 173068192
Test: changes to existing unit tests show bug is fixed
Change-Id: Ic9196bc92892811b25bda463ffd839ee5c19d294
In the current tethering code, upstream selection is only
triggered by CONNECTIVITY_ACTION. But in automatic mode, the
upstream network is selected by listening to a NetworkCallback
that tracks the default network.
This causes a race where if the CONNECTIVITY_ACTION for a network
switch is received and processed before the callbacks for that
network switch, upstream selection just re-selects the upstream
currently in use.
Make it possible to test this by giving TestConnectivityManager
the ability to choose the ordering between NetworkCallbacks and
CONNECTIVITY_ACTION, and to run an arbitrary Runnable between
calling one and calling the other. TetheringTest passes a
Runnable that calls mLooper.dispatchAll(), which ensures that
the tethering code fully processes the first set of information
it receives (either the broadcast (or the callbacks) before
receiving any more information.
Add test coverage to testAutomaticUpstreamSelection that
exercises various orderings, and make the test pass by expecting
the buggy behaviour of the current code.
An upcoming CL will fix the bug and update the tests.
Bug: 173068192
Test: test-only change
Change-Id: I7805444dcf59f6d5f8517fbcf2f2b1641783d50b
This is needed for forwarding to work, so it should be dumped.
New output:
Forwarding rules:
29(29) -> 14(rmnet2) 86dd 00:00:00:00:00:00 00:00:00:00:00:00
[ap_br_wlan2]: iif(iface) oif(iface) v6addr srcmac dstmac
14(rmnet2) 29(ap_br_wlan2) 2001:240:2423:13fa:3c21:e35a:6a59:ff8a da:17:fd:70:3d:14 26:5b:b2:ee:bc:ba
IPv4: [inDstMac] iif(iface) src -> nat -> dst
[da:17:fd:70:3d:14] 29(29) 192.168.222.151:39208 -> 14(rmnet2) 100.102.14.231:39208 -> 172.217.175.3:80
[da:17:fd:70:3d:14] 29(29) 192.168.222.151:47386 -> 14(rmnet2) 100.102.14.231:47386 -> 216.58.197.196:443
Also add a call to getHostAddress() to remove the / on IPv6
forwarding rules.
Test: manual
Change-Id: I347ea5a3fd88c51f1fae0c76c75dfa30c68a55ad
- This will be visible only to apps with the NETWORK_SETTINGS
permissions (signature), and will be redacted for all other callers.
- This string is expected to be the same as set by
VpnService#setSession, and in general, VpnConfig.session. But it
will be a general API that Vpn.java can call when setting the
VpnTransportInfo.
- This string cannot be updated once the VPN NetworkAgent is connected.
Bug: 171872481
Ignore-AOSP-First: needed to prevent automerger race breaking build
Test: atest ConnectivityServiceTest
atest VpnTransportInfoTest
atest NetworkAgentTest
Change-Id: I883035262465238c35c5a931d89707f3e84feef8
Merged-In: I883035262465238c35c5a931d89707f3e84feef8
(cherry-picked from ag/14008230)
These members are public mutable and their names are confusing.
Make them package-private and final.
Bug: 173068192
Test: test-only change
Change-Id: I87131c48f67b6614c25aa99e1cbc53196f49aa7c
Currently, TestConnectivityManager immediately sends all
callbacks and broadcasts to the Tethering code as soon as the
test code makes any change.
This makes it impossible to affect the order in which those
events are delivered to the Tethering code, so it is not possible
to test for races.
Fix some of this as follows:
1. Make TestConnectivityManager post all its callbacks to the
handlers that Tethering registered them with.
2. In TetheringTest, use the existing TestLooper object to
advance time manually. Also use setUseRegisteredHandlers to
ensure that the broadcasts are sent in order. This requires
calling dispatchAll() after sending the broadcast to preserve
the existing synchronous behaviour. Take advantage of that to
remove lots of existing dispatchAll calls.
3. Add a TestLooper to UpstreamNetworkMonitorTest and use it.
Keep the test passing by adding lots of mLooper.dispatchAll(),
which is a bit ugly but probably acceptable given the
additional coverage it provides.
This exposes an existing bug in the code where if upstream
selection is in automatic mode, and all CONNECTIVITY_ACTION
broadcasts are received before all NetworkCallbacks, the code
does not switch upstream.
In order to make the tests pass, re-order the CONNECTIVITY_ACTION
broadcasts with the NetworkCallbacks in TestConnectivityManager
so as not to trigger the bug. A future CL will make the order
configurable.
While I'm at it, switch TestConnectivityManager from HashMap to
ArrayMap, which is generally preferred for maps that do not
contain too many elements.
Bug: 173068192
Test: test-only change
Change-Id: I964f365c691fbc396ab0a87f292bd32b123011fe
Currently, Tethering files NetworkRequests even when
config_tether_upstream_automatic is enabled. This is incorrect:
when the automatic upstream selection is enabled, the tethering
upstream should always follow the default network and there is
no need to file any requests.
These requests are harmful when tethering is not using cellular
as its upstream, because:
- If the device does not use mobile data always on, the request
causes the cellular network to be brought up, causing power
draw.
- Even if the device does use mobile data always on, the request
causes the cellular network to come to the foreground, which
allows all apps to access it, causing potential data usage.
Amend the existing testGetCurrentPreferredUpstream to cover these
changes, by making that test case always set automatic upstream
mode. This does not result in any loss of meaningful test
coverage, because getCurrentPreferredUpstream is only ever called
when chooseUpstreamAutomatically is enabled.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I068a5338699a3ed04f24f97f785ea89ff5890e50
UpstreamNetworkMonitor is the part of tethering that files
NetworkRequests for upstream netwoks, but it currently does not
know all the requirements for upstream selection. For example, it
does not know whether automatic upstream selection is in use.
This forces the upstream selection code to be split between
UpstreamNetworkMonitor and Tethering. This makes it difficult to
follow.
This CL ensures that all information about upstream requirements
(DUN required, automatic upstream selection, tryCell) is passed
to UpstreamNetworkMonitor so it can be aware of it.
This CL also removes the ability for UpstreamNetworkMonitor's
callers to call registerMobileNetworkRequest or
releaseMobileNetworkRequest. In a future CL, this will be
automatically done by UpstreamNetworkMonitor depending on the
upstream requirements.
This CL is a no-op refactoring with no behaviour changes.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I174f765c616e0dbe2aa493c12613e6131cff0666
The parameter of NetworkCapabilities.setUids() and
NetworkRequest.Builder.setUids() are updated to take a set of
integer Range instead of a set of UidRange because of refactor
work for the incoming connectivity mainline module.
The parameter change stops NetworkRequestTest to work in the
different API levels. Replace the usage with shims to work in
both current and stable APIs.
Ignore-AOSP-First: Prevent race in automerger
Bug: 172183305
Test: atest FrameworksNetTests CtsNetTestCasesLatestSdk
(cherry picked from commit 41918d6cd1)
Change-Id: I3ff97b9bbda8839d271151165b8d99a04ae9e1f1
Merged-In: I4bc0daf5ad9e4b4043f4a897ddab16aec8f8a536
The parameter of NetworkCapabilities.setUids() and
NetworkRequest.Builder.setUids() are updated to take a set of
integer Range instead of a set of UidRange because of refactor
work for the incoming connectivity mainline module.
The parameter change stops NetworkRequestTest to work in the
different API levels. Replace the usage with shims to work in
both current and stable APIs.
Bug: 172183305
Test: atest FrameworksNetTests CtsNetTestCasesLatestSdk
Merged-In: I4bc0daf5ad9e4b4043f4a897ddab16aec8f8a536
Merged-In: I2550cb3ddd9c72c12de0dbf9baf32eec6fa3b151
Change-Id: I90b3384d2a78275df9f8717dba9d654eb82036bd
When meteredness of wifi changes during test, wifi disconnects.
Try reconnecting if it automatically connects after this.
Also, change the way we update metereness so that we can
use callback mechanism to wait for the state change instead of
polling for it regularly.
Bug: 181686645
Test: atest ./tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Merged-In: I31fb127ef333d39fe4697043876c7cef15d525e3
Change-Id: Icc0b37730201aebeab2713c6527a3195f6dcf97d
The file name is getting truncated by tradefed and
we are missing the information to actually idenity
the test. So, instead shorten the filename to preserve
the test name.
Test: atest ./tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Ignore-AOSP-First: Submitting internally first to avoid merge conflicts.
Merged-In: Ic0f87b97bb58e115fe81e2d688ce0e633397da42
Change-Id: I6ce3fc662782de82d8cad95414e24204b5f7f130
In S, instant apps can no longer access the system service that
backs the VPN APIs, so these tests started to fail in instant
mode.
Regardless of that change in S, though, instant apps cannot
create VPNs because they cannot access the package manager.
Previously, the tests were only passing because they did not
check that the VPN would actually work, they only checked that
the VPN API calls failed.
Fix: 181575083
Test: atest --instant CtsNetTestCases:VpnServiceTest
Change-Id: Idd35051bd1c908a8b85c02e8d0c54d3dea2dde38
