No DHCPACK received in DHCP process. Because previous DISCOVER/OFFER
steps have done, it implies that DHCP server is launched and
client/server can transmit data to each other. Assume that DHCP server
can reply DHCPACK and CF may need more than 100ms.
Extend the timeout from 100ms to 500ms. Monitor if receiving DHCPACK
timeout is found.
Bug: 243314243
Test: atest EthernetTetheringTest
Change-Id: Id8bb0e03ae1e853beb6242a1c35b977ace9ca190
The tracking interface of EthernetTracker(mTetheringInterface) is
stopped to track only when it is removed. There is race condition in
EthernetTetheringTest that the new test start ethernet tethering with
previous test interface name because EthernetTracker still tracking
previous test interface.
Destroy test interface then listen untether callback without calling
stopTethering. If EthernetTracker stop tracking test interface, it would
call onUnavailable callback to stop tethering. So the test can check
whether tethering is stopped to ensure the test interface is not tracked
anymore before test finish.
Bug: 191826409
Bug: 243222655
Test: atest TetheringIntegrationTests
Change-Id: I618983d981cd3a707dcb7723cdbb20ba5bf8bd2e
* changes:
ethernet: disable ipv6 provisioning delays
ethernet: improve test failure readability
ethernet: wait for the interface listener to be registered
ethernet: read running flag before bringing up interface
ethernet: remove buggy test expectations for compatibility
Disabling RS delay and DAD speeds up tests and makes them more reliable.
Test: atest EthernetManagerTest
Change-Id: I1239e7974e9b62be4f43f009a24d752c51371270
If an interface is created before the interface state listener is
registered with the ethernet service, callbacks can get missed.
Specifically, createInterface() expects a down before an up callback. If
the listener registration executes after the event, the listener only
receives the final state event (up in this case).
This was a common source of flakiness in the EthernetManagerTests.
Test: EthernetManagerTest
Change-Id: Iefccc9318a9ea2f929d34a52b7b275bf7a23f443
gen_jarjar supported multi-valued arguments via space-separated lists,
like "--apistubs foo bar". This is unusual, as "bar" would generally be
interpreted as a positional argument instead.
Change the usage to "--apistubs foo --apistubs bar", which is more
conventional. Also remove the "--jars" switch to have the jars be
positional arguments instead, and change the "--unsupportedapi"
arguments to be a column-separated list (like java classpath), instead
of space-separated. For --unsupportedapi, this allows providing a list
of files via minimal modifications in the genrule usage.
Test: m
Change-Id: Id67ad16de2ea6682fee402540f464ed3b5b0cca9
This would be needed for subsequent patches that synthesizing DNS
packets for testing purpose.
Bug: 139774492
Test: atest DnsPacketTest DnsResolverTest
Change-Id: I5e58f99b09b693f167178e56f008be8b42d9417a
Previously, the "running" flag was checked right after calling
setInterfaceUp(), which caused an updateInterfaceState(UP) event to be
generated at the end of addInterface(). This "artificial" link up
notification is only needed for interfaces that already had link before
being added (as in this case, no RTM_NEWLINK callbacks are received, and
link state needs to "manually" be set to UP to start configuring the
interface). This could happen when system server crashes and gets
restarted, or when ethernet is temporarily disabled via the
EthernetManager API.
Reading the running flag before bringing up the interface ensures the
updateInterfaceState(UP) event is not generated for interfaces that were
just brought up.
This fix gets rid of the up/up/down/up callback when a new interface is
added.
Test: atest EthernetManagerTest
Change-Id: I122dc886a94222c575f44182b943e64b435c03e8
EthernetManagerTest#testCallbacks() should not enforce up/up/down/up
callbacks, so this bug can be fixed in mainline without breaking CTS13.
Test: atest EthernetManagerTest
Change-Id: I1650bbc2a5883a874b92ecf2bcc7a56d01f4a905
* changes:
ethernet: remove callback from factory updateInterfaceLinkState
ethernet: updateConfiguration result should not rely on ip provisioning
ethernet: remove callback boilerplate from EthernetNetworkFactory
ethernet: add EthernetCallback class to wrap OutcomeReceiver
Currently, production code uses BpfMap type and TestBpfMap extends
BpfMap but this makes it diffcult to test because TestBpfMap loads the
JNI.
This CL updates to use IBpfMap type in the production code.
Upcoming CL updates TestBpfMap to implement IBpfMap instead of extending
BpfMap so that test can still use TestBpfMap but tests do not need to
load JNI.
Bug: 217624062
Test: atest BpfCoordinatorTest BpfNetMapsTest
Change-Id: Ie67e14bf5519fb4427474ecc0fda441877a9555f
Currently, NetworkAgentInfo#satisfies determines whether a
network exists (and should satisfy requests) based on
|created|, not |everConnected|. This is theoretically incorrect
because networks in CONNECTING state or similar must never
satisfy requests or call callbacks.
This cannot happen for requests. New requests are only added to
networks by NetworkAgentInfo#addRequest, which is only called by
computeNetworkReassignment via updateSatisfiersForRematchRequest,
which skips any network with everConnected = false. It can
potentially happen to listens though.
Also, this cannot ever happen for physical networks, because for
physical networks, created is set at the same time as
everConnected, the first time they enter CONNECTED state.
In theory, this can happen for VPNs since ag/988402 , which
changed the code to create VPN networks as soon as they enter
CONNECTING state. That CL added the everConnected boolean to
NetworkAgentInfo but did not update the satisfies and
satisfiesImmutableCapabilitiesOf checks to use everConnected.
In practice, even for VPNs this is very unlikely, since VPNs
advance from CONNECTING to CONNECTED essentially immediately.
Even if they didn't, sending callbacks before they enter
CONNECTED state would be incorrect because the app receiving
the callback would have no way of knowing that the network is
actually not yet connected.
With this change, some checks for everConnected become spurious,
because a network with everConnected=false cannot satisfy either
requests or listens. Remove these checks.
Test: extensively tested by existing ConnectivityServiceTest
Change-Id: I024bb2b85bc57228d53e69a7707c7ce7ac756259
updateInterfaceLinkState already returns true / false depending on the
success, so the EthernetCallback can be removed and sent from
EthernetTracker instead.
Test: atest EthernetManagerTest
Bug: 225317892
Change-Id: Id6ae7929097840ac5c9a4d244fdf669a06b94ed5
In addition, the result should always be success if the new
configuration is stored. This allows updating interfaces that are not
currently registered with ethernet service.
Bug: 236312641
Test: atest EthernetManagerTest
Change-Id: I70474ef5f046c65a6f74161137e25debd8dfe612
The internal issue of nullness suppression for mdns files has
been addressed. Update the bug number to track AOSP only work.
Bug: 242631897
Test: m
Change-Id: I41c072a4313a9668fe509f796ba2956d74397e5c
Now that everything uses EthernetCallback, there is no need for the
boilerplate code in EthernetNetworkFactory anymore.
The next step will be to pull the callbacks out of
EthernetNetworkFactory entirely.
Bug: 225317892
Test: atest EthernetNetworkFactory
Change-Id: I4958df658f7d5852660a5c03a8c9220532e42d3c
The OutcomeReceiver that gets passed into the EthernetServiceImpl is
hard to use (it is nullable and both onError and onResult can throw
RemoteExceptions).
Note: This is an intermediary state.
The next step will be to completely tear EthernetCallback out of
EthernetNetworkFactory, which will remove a lot of boilerplate code.
Bug: 225317892
Test: atest EthernetManagerTest
Change-Id: Ifc0e1ba29ded933c418e4b335cb731c3496d7e44
This change fixed two things:
1. start wifi tethering after airplane mode enabled.
2. run ConnectivityManager#factoryReset with TETHER_PRIVILEGED
permission, so it can sucessfully stop tethering.
Orignally testFactoryReset don't actually test stop tethering.
Tethering already be stopped while airplane mode enabled, but
enable airplane mode then doing factory reset would have race in
wifi stack which caused airplane mode don't take effect in wifi
side.
Bug: 240677322
Test: atest ConnectivityManagerTest#testFactoryReset --iterations 50
Change-Id: I3185401b10b798af744df5c3c7c21fee3d418939
- Enlarge the time out for waiting callback.
- Ensure the agent disconnected completely after running each
test.
Test: atest android.net.cts.NsdManagerTest --iteration 100
Change-Id: Icb04641ad5e4cb826995b99679313b12e96e9879
This reverts commit daf5cb64cc.
Reason for revert: dumpstate has the same information
Bug: 243313712
Change-Id: Ie8283cd942bff6ef9dbb66e5926bf650bd56997f
