This is only necessary when learning the NAT64 prefix from the
RA, because if the NAT64 prefix is learned from DNS, the DNS
resolver already knows the prefix and automatically enables
DNS64 synthesis.
The DNS resolver needs to be informed of the prefix any time
clat is running on a prefix learned from an RA. This is simple to
implement: just set the prefix when starting clat if prefix
discovery is not running, and clear the prefix when stopping clat
if prefix discovery was not running. This ensures that the prefix
is cleared iff it was set.
Bug: 156914456
Test: new unit test coverage
Original-Change: https://android-review.googlesource.com/1315578
Merged-In: If8ad2d30712a6df3e207c8d3e8a129705242191e
Change-Id: If8ad2d30712a6df3e207c8d3e8a129705242191e
This is not particularly likely to happen unless the pref64 RA is
sent by a different router than the main RA. But more tests are
always good, and this additional coverage will be more useful
in an upcoming change.
Bug: 150648313
Test: test-only change
Original-Change: https://android-review.googlesource.com/1316094
Merged-In: I3316d49d42100800740afadc4edf0a13a4d8377c
Change-Id: I3316d49d42100800740afadc4edf0a13a4d8377c
This CL forwards suspected Data Stall events detected with unknown
detection methods to ConnectivityDiagnostics.
Currently, ConnectivityService drops any data stall events with unknown
detection methods, which leads to false negatives for Connectivity
Diagnostics registrants. This change ensures that registrants will still
be notified as NetworkStack is updated to use new detection methods.
The documentation for ConnectivityDiagnosticsManager#DataStallReport is
also updated to reflect that the detection methods included in the
report are a bit mask of detection methods used. Implicitly, this means
that data stalls detected via unknown methods will have an empty bit
mask (0x00).
Bug: 156294356
Test: atest ConnectivityDiagnosticsManager
Change-Id: I62d0bf91fcc17c7921afd519c72551399906bd6b
Merged-In: I62d0bf91fcc17c7921afd519c72551399906bd6b
(cherry picked from commit a1d9d811a05bf3447ebb90a39343b53eee79f0db)
This change adds a comment to CS#simulateDataStall to explain why the
Data Stall is wrapped in a DataStallReportParcelable before being passed
to the ConnectivityDiagnostics handler. This approach is taken to ensure
that simulated data stalls are handled the exact same as Data Stalls
received directly from NetworkMonitor (including Data Stalls detected by
methods that the platform does not understand).
Bug: 156294356
Test: atest ConnectivityDiagnosticsManager
Change-Id: I751054418bf328c72b977a1cc99c27cb9b8ab7ba
am skip reason: Change-Id Ie2f6a1a2376c5c452750ab417cb5e8c24fc44fc3 with SHA-1 15eb17c2fc is in history
Change-Id: Ibeb7ba515d11c4dcf74b0d8f504adeff007ff444
am skip reason: Change-Id Ie2f6a1a2376c5c452750ab417cb5e8c24fc44fc3 with SHA-1 f5cc4eae9e is in history
Change-Id: I3f89d4dd79935d26629dbd06c06f2784ded317e8
am skip reason: Change-Id Ie2f6a1a2376c5c452750ab417cb5e8c24fc44fc3 with SHA-1 f5cc4eae9e is in history
Change-Id: I376f8021b63cc21393de7eba8f0ad26650eedab5
This is only necessary when learning the NAT64 prefix from the
RA, because if the NAT64 prefix is learned from DNS, the DNS
resolver already knows the prefix and automatically enables
DNS64 synthesis.
The DNS resolver needs to be informed of the prefix any time
clat is running on a prefix learned from an RA. This is simple to
implement: just set the prefix when starting clat if prefix
discovery is not running, and clear the prefix when stopping clat
if prefix discovery was not running. This ensures that the prefix
is cleared iff it was set.
Bug: 156914456
Test: new unit test coverage
Change-Id: If8ad2d30712a6df3e207c8d3e8a129705242191e
This is not particularly likely to happen unless the pref64 RA is
sent by a different router than the main RA. But more tests are
always good, and this additional coverage will be more useful
in an upcoming change.
Bug: 150648313
Test: test-only change
Change-Id: I3316d49d42100800740afadc4edf0a13a4d8377c
am skip reason: Change-Id If5e5439b22f05e08a293fd83da4d54f6a4363ca5 with SHA-1 4a7eb2a5d2 is in history
Change-Id: I68df91460ca23d2ec5336543bbedec0b802d80d0
am skip reason: Change-Id I3e4ff990c0d4825b21c7679be29a482a2d1324ec with SHA-1 ebbece8b22 is in history
Change-Id: I2c65d4269c9774ee850ebaa0c9ee6bc41c9aec62
am skip reason: Change-Id If5e5439b22f05e08a293fd83da4d54f6a4363ca5 with SHA-1 4f8109f638 is in history
Change-Id: I5ad62604060d15c2e802f612eaea80cd75040ff8
am skip reason: Change-Id I3e4ff990c0d4825b21c7679be29a482a2d1324ec with SHA-1 fbd6a2c012 is in history
Change-Id: I9e8f5333444a3eb70d17a3c4077383a8b55815f9
am skip reason: Change-Id Id7d8bba486bada1a7ba5b0f152d2aa02e407f249 with SHA-1 bee5b3f227 is in history
Change-Id: I2dd1178f403d5515f73b3ae2527576b0dd83d4e8
am skip reason: Change-Id Id7d8bba486bada1a7ba5b0f152d2aa02e407f249 with SHA-1 d568791283 is in history
Change-Id: Id070eb419a57aa6c7eddacf8266a40eebdbc415b
am skip reason: Change-Id If5e5439b22f05e08a293fd83da4d54f6a4363ca5 with SHA-1 4f8109f638 is in history
Change-Id: Ifaf50fb9e04b1403cc75d9002e46c6955e111a40
am skip reason: Change-Id I3e4ff990c0d4825b21c7679be29a482a2d1324ec with SHA-1 fbd6a2c012 is in history
Change-Id: I22ecee256894e850f85ab02b299136283ebe9a08
am skip reason: Change-Id Id7d8bba486bada1a7ba5b0f152d2aa02e407f249 with SHA-1 d568791283 is in history
Change-Id: I655cca7c9e1ba6ba4fae95b221b1e46e91da5f6d
As NetworkAgent is in a transition where all agents need
to include the NOT_SUSPENDED capability as part of their
migration to the system API, ConnectivityService adds it
forcefully to all agents that don't have the CELLULAR
transport. This doesn't include VPNs when VPNs have some
cellular network as their underlying network.
The best way to solve this is to make sure the VPN
capabilities reflect those of the underlying networks as
far as the NOT_SUSPENDED capability is concerned. This
is how they work for other similar capabilities.
This also happens to contain a drive-by fix for an issue
with a spurious capabilities callback is triggered when
a VPN connects and it has any underlying network (which
means almost always, because it will take the default
network if it doesn't declare any). Fixing this was
necessary to have a cogent test of this issue, but it
could be moved to another patch or it could stay unfixed
with some minor ajustment to the tests if judged too
dangerous to include in R at this point.
Test: New tests in this patch. Also manually tested with
tcpdump as described in b/150570873.
Bug: 150570873
Original-Change: https://android-review.googlesource.com/1301317
Merged-In: I3e4ff990c0d4825b21c7679be29a482a2d1324ec
Change-Id: I3e4ff990c0d4825b21c7679be29a482a2d1324ec
When a VPN connects and it has any underlying network (which
means almost always, because it will take the default network
if it doesn't declare any), it has default capabilities and
will only take the capabilities of its underlying network
as part of an update happening after making the network
available but before the rematch can take place. This in turn
causes the capabilities callback sent as part of the rematch
to be spuriously sent.
Test: FrameworksNetTests. Also tested together with a
followup that adds tests with drive-by coverage for this.
Bug: 150570873
Original-Change: https://android-review.googlesource.com/1305393
Merged-In: Id7d8bba486bada1a7ba5b0f152d2aa02e407f249
Change-Id: Id7d8bba486bada1a7ba5b0f152d2aa02e407f249
This saves dozens of warnings every time FrameworkNetTests is
compiled. There is nothing we can do about those warnings because
LegacyTypeTracker's reason for existence is to power deprecated
APIs.
Test: m FrameworksNetTests
Change-Id: I4d65b0aade493e12b56a94247efbf9d1ad7bb4b9
