| Age | Commit message (Collapse) | Author |
|---|
|
The previous IpClientLinkObserver code could in theory call
mCallback.update with a linkState that came from another update; for
example:
1. onInterfaceAddressUpdated
- mLinkProperties.addLinkAddress
2. onInterfaceLinkStateChanged
- setInterfaceLinkState(false)
1. mCallback.update(false) <- should be true ?
2. mCallback.update(false)
In practice this would not happen because the onFoo methods are all
called in order (same binder token from netd), but IpClientLinkObserver
should not need to make such assumptions.
Bug: 151796056
Test: atest NetworkStackIntegrationTests (see also test-only change)
Change-Id: I60f5a319519069070eb5a07643686bf5ec937665
|
|
When turning wifi off, the interface gets torn down and empty
LinkProperties are received before wifi calls stop(). This causes a loss
of provisioning to be logged, instead of normal termination.
Watch interface link status up/down events, and when provisioning is
lost when the interface is down, consider it a normal termination.
Bug: 151796056
Test: manual: turn wifi off, observe events
Test: atest NetworkStackIntegrationTests (see also test-only change)
Original-Change: https://android-review.googlesource.com/1343236
Merged-In: I9d086a199de0017aa425219d20882211423925e0
Change-Id: I9d086a199de0017aa425219d20882211423925e0
|
|
This provides a better separation of the classes based on their role (an
actual shim, or an interface or utility common to all shims), and forces
the apishim package to import the common classes, which makes it easier
at SDK bump time since the imports do not need to be added at that
point.
Bug: 143586229
Test: atest NetworkStackTests
Original-Change: https://android-review.googlesource.com/1310517
Merged-In: Ie77c17a96a67016f35890afa065bea0a07b09504
Change-Id: Ie77c17a96a67016f35890afa065bea0a07b09504
|
|
Currently the code does not cancel the PREF64 alarm when IpClient
is stopped. If the alarm fires when IpClient has disconnected, it
will call updatePref64 with a null prefix, which will crash.
Ensure that the alarm is cancelled when IpClient is stopped.
Bug: 153694684
Bug: 155559286
Test: new unit tests
Change-Id: I397eb36c1a8ecf1324de33e720577fe2e4e07056
|
|
Add comments and slightly increase test coverage.
Bug: 153694684
Test: new test coverage in IpClientIntegrationTest
Change-Id: I160a0801449cbe9e66976eaacdd3a914adc3d341
|
|
Bug: 153694684
Test: new test coverage in IpClientIntegrationTest
Change-Id: Ie207940d79abbc0d92dd15becee867e72f171786
|
|
This allows IpClient to parse the pref64 RA option and put it
in the LinkProperties to be sent to ConnectivityService.
IpClientLinkObserver is a natural place for this because it is
the part of IpClient that is already tasked with receiving
netlink events and storing the results in IpClient's
LinkProperties.
Instead of using the path used by most attributes, which are
parsed by NetlinkHandler, converted to a string array, then
re-parsed and sent over binder call to the networkstack, simply
open a netlink socket in the networkstack process and read the
netlink messages from there. In the future, we can build on this
to parse other netlink messages (e.g., IP addresses, routes,
RDNSS, etc.) in the networkstack and entirely remove the
dependency on netd's NetlinkHandler, which is crufty, hard to
extend, and does not support interface indices.
This means that the pref64 attribute will not be ordered with
respect to other netlink events. This is acceptable because the
pref64 attribute does not need to be ordered with any other
information and its presence or absence does not cause
provisioning to succeed or fail. Today the pref64 is learned
through an entirely different codepath (DNS lookups) and that is
not ordered in any way either.
This CL does not change the threading model: the netlink updates
are processed on the handler thread like all the other updates
seen by IpClientLinkObserver, and all access to mLinkProperties
is synchronized (this). This synchronization is no longer
necessary because everything is on the handler thread anyway,
but that will be cleaned up in a future CL.
Because netlink events contain interface indices, but IpClient
and netd deal with interface names, IpClientLinkObserver must be
told what the interface index is. This is done when
startProvisioning is called, because that is when IpClient
fetches the interface parameters including the MAC address and
interface index. It cannot be done when IpClientLinkObserver is
started, because at that time the interface might not exist, or
might exist with a previous interface index. The interface index
is cleared when IpClient enters the stopped state and the
LinkProperties are cleared.
Bug: 153694684
Test: atest NetworkStackNextIntegrationTests:IpClientIntegrationTest#testPref64Option --iterations 100
Change-Id: I3f8d2fbf2e203c6f90029947fa55b5e0b3b06d94
|
|
Some routers have been known to use RDNSS lifetimes of 10
seconds(!). This causes APF filters to be set to very low
lifetimes, which substantially impacts battery life.
There are two parts to this:
1. Ignore low RDNSS option lifetimes for the purpose of
calculating APF filter lifetimes.
2. Do not add DNS servers to the repository if their lifetimes
are too low.
If we do #1 without #2, the servers will expire because APF will
drop the RAs that refresh them, potentially causing outages or
disconnections.
The behaviour is enabled by default starting from R and can be
enabled on all builds using a flag.
Bug: 66928272
Test: New unit test passes
Change-Id: Ib2e2555026da3e81ea3d50767a30092413b4e4f5
|
|
When receiving a zero-lifetime RDNSS option for DNS servers that
is already configured, the code first sets the lifetime of the
servers to zero, and then runs code that prunes expired servers.
Because expired servers are pruned only if "expiry < now", if the
pruning happens in the same millisecond as the update, the
servers aren't actually pruned. This can happen multiple times,
so if the code runs fast enough, the server will never expire.
Fix this by using <= instead of <.
Fix: 143806550
Test: makes the new IpClientIntegrationTest#testRaRdnss not flaky
Change-Id: Icf6893efdc028859b178eb234f6f1a42b24e2936
|
|
Use the new NetworkObserverRegistry instead.
Test: atest FrameworksNetTests NetworkStackTests
Test: flashed, WiFi working fine
Bug: 112869080
Change-Id: If16ecfd6489f86afec67c22b4c3692cd68f4edbf
|
