Currently, the MTU tests work on networks that have not yet been
connected. This is not very realistic because most MTU changes
(like most LinkProperties changes in general) happen after the
network has connected. Change these tests to use connected
networks instead.
To avoid losing coverage for setting the MTU before the network
is connected, add a test just for that.
Bug: 143158421
Test: test-only change
Change-Id: I7f808249722924a0b1253e402c5580bb104afd8e
The system polls TCP connections every 2 minutes for the auto
on/off keepalives. For some carriers, the NAT-T keepalive delay
is lower than this, which means it's possible a TCP connection
is opened seconds after the poll. This may cause connections
being disconnected because keepalive timed-out.
The minimal acceptable value should be the same as the keepalive
delay. But the system may take time to restart keepalive. Adjust
the delay of the polling alarm to be lower than the keepalive
delay to preserve some time for the system to restart the
keepalive.
Bug: 273411114
Test: atest FrameworksNetTests
Change-Id: I28f71ceb7b72d83e6e0f8f7d22d3d1e9dbdaa467
The active network LinkProperties are not cleaned up after stop
socket monitoring. Then the apps will have duplicate sockets
to discover on one interface if the interface has been toggled,
because requestSocket will return both the old socket (for the
old netId that is actually gone) and a new socket on the same
interface, for the new netId. Thus, clean up the LinkProperties
when stop monitoring sockets.
Bug: 274063187
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
Change-Id: I3d600169b069a1534bd740e711bc21db107b1201
Somewhat surprisingly, HandlerThread#quitSafely is *not* a synchronous
method, so the tearDown() method still needs to wait for the thread to
join.
Test: TH
Change-Id: I0433e2100adf9299a67af5c259a518cf44f4be57
Apps targeting sdk < U are considered to use a legacy native
daemon as NsdManager backend, but other apps use a
platform-integration mDNS implementation as backend. So add a
CompatChange flag to enable platform backend for non-legacy
apps.
Bug: 270306772
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I7ba58f8a5186fb49ad5f8aeacc8b8234bef1eabe
When the test is very slow (e.g. in coverage tests) it's
possible this test takes > 30 seconds and cell finishes
lingering before the end of the test. This will cause a
disconnection of cell before wifi and fail the test.
Address this by requesting cell.
Bug: 273383734
Test: atest --iterations 100 'FrameworksNetTests:android.net.connectivity.com.android.server.ConnectivityServiceTest#testExplicitlySelected'
Change-Id: I06a7ef82de966b522e58a969c25a4c0335dbc497
after the commit aosp/1948496, both mMobileIfaces and mWifiIfaces
already contain the stacked interfaces. Hence, the method is not
really useful.
Test: TH
Fix: 215633405
Change-Id: Id132a166e9cf94cab711f417a4f7ffc84eab6185
The running task in MdnsServiceTypeClient would be cancel if the
requests using other networks for the same service type start a
new discovery. Besides, the instanceNameToResponse cache would
be incorrect too. The service attributes may be different on
different networks, so there needs to be a different instance
of the cache. Thus, the MdnsServiceTypeClient needs to be
Network-specific.
Bug: 265787401
Test: atest FrameworksNetTests
Change-Id: Id5ac42f3522a774fe9789c0de4d5357501b63868
The required sockets may not have been created yet when
MdnsServiceTypeClient#startSendAndReceive is called on
MdnsDiscoveryManager#registerListener, so the first send would go
nowhere, and only later retries would be sent. Ideally the code
would wait for some sockets to be created before calling
startSendAndReceive.
Bug: 265787401
Bug: 264634275
Test: atest FrameworksNetTests
Change-Id: Id789d564d125c0192e742d7dd246367afdb93413
matchesWifiNetworkKey expects a non-null value of the
wifiNetworkKey, however, it might be null in practice
and the null wifiNetworkKey will be stored into disk.
And then when the matchesWifiNetworkKey is called, the
requireNonNull will crash the system. Thus, remove the
requireNonNull from matchesWifiNetworkKey to avoid
system crash and handle if the wifiNetworkKey is null
then it should not match a template with non-empty
mMatchWifiNetworkKeys.
Check if WifiInfo contains a null network key then skip it
to prevent adding the identity to the network identity set.
Also, add a Log.wtf when setWifiNetworkKey(info.getNetworkKey()),
this might be useful to catch why the wifiNetworkKey is
null.
Bug: 267815242
Bug: 266598304
Test: FrmeworksNetTests
Change-Id: I9c21f7e3dca9482133c7e331741cf808105414e9
API council has requested that the recently added BroadcastOptions
APIs be modified to better match API guidelines.
Bug: 267646347
Test: treehugger
Change-Id: Ia701ae31079476d0cc05079d62cd90ba81279cdd
Although case should not matter when comparing attributes,
converting all keys to lowercase breaks NsdServiceInfo APIs which
provide the original case to the caller.
Use a TreeMap with a case-insensitive comparator to ignore case when
querying keys, while keeping case information in the map.
Bug: 270885892
Test: atest MdnsServiceInfoTest
Change-Id: Id15947b1e8650eb6b59126c5d2dc8624ae4f8100
- Make a method addOrReplaceRecord() that can support point,
inet4Address and inet6Address records adding.
- Also fix some leftover comments in aosp/2431933
Bug: 268586836
Test: atest FrameworksNetTests
Change-Id: I01462a967a04e88f14dcbb92ca207deb4268612c
Now, the multiple addresses is supported in resolution service
with the new java backend. Thus, fill in all resolved addresses
into NsdServiceInfo.
Bug: 268586836
Test: atest FrameworksNetTests
Change-Id: I499a749255429df9fe9fbad678074ad383159240
registerServiceInfoCallback currently only sends updates for
addresses added, but does not handle removes (expiration) and
TXT/SRV record updates. Thus, migrate its backend to
MdnsDiscoveryManager which can support the expiration update.
Bug: 266030646
Test: atest FrameworksNetTests CteNetTestCases
Change-Id: I72add213935dc1beacb6277007868ad30bd89c00
If the mDNS service has multiple IPv4 / IPv6 addresses, only the
last added address will be present on the response. Since the
NsdServiceInfo supports multiple host addresses in Android U, the
MdnsResponse should also support multiple IPv4 / IPv6 addresses
in favor of providing accurate service info to clients.
Check cache flush flag on the response when adding a new address
record. Per RFC6762 10.2, clear all address records if the
cache-flush bit set.
Bug: 268586836
Test: atest FrameworksNetTests
Change-Id: I04548a3f16837939f3131b84c1033377ff81d521
The flags allow enabling MdnsDiscoveryManager or MdnsAdvertiser for
specific service types only. For example:
mdns_type_allowlist_flags = "_type1._tcp:flag1,_type2._tcp:flag2"
mdns_discovery_manager_allowlist_flag1_version = 1234
mdns_advertiser_allowlist_flag2_version = 2345
will enable MdnsDiscoveryManager when discovering/resolving services of
type _type1._tcp, and MdnsAdvertiser when advertising services of type
_type2._tcp.
Test: atest NsdServiceTest
Bug: 270885892
Change-Id: I75c31a28472210bf8777409ea7aff1e3d8bf0a0d
The service type that found from NsdManager#discoverServices()
with old backend(mDnsResponder) has an extra dot at the end. And
the previous API accepted both formats, so we need to keep
backwards compatibility with both formats. Thus, drop that extra
dot when constructing the service type for the new backend.
Bug: 266030646
Test: atest FrameoworksNetTests
Change-Id: I987ab866f6a3a7cff654f96978057fdd93b859d6
* changes:
Return ERROR_NO_ANSWERS for replies with no answer
Allow resolving previously undiscovered services
Use resolveInstanceName in NsdService
Add missing SRV/TXT/address records to responses
Update record TTL in set/add methods
Clear inetaddress fields when removing the record
The resolveService() uses new mdns backend if the
MdnsDiscoveryManager feature is enabled. So the new API
stopServiceResolution() should have new mdns backend
implementation as well.
Test: atest FrameworksNetTests
Change-Id: I73fa9ca71c0afc5db99db9252f4c030d4f2b8066
Previously resolve queries for SRV/TXT/A/AAAA were only sent when there
was a known but incomplete MdnsResponse for the service.
Allow sending the resolve queries when there is no known MdnsResponse,
so no known PTR record, but the client specified the resolveInstanceName
in the MdnsSearchOptions. This is achieved by adding the serviceName as
an additional field in MdnsResponse, as it is always known when
constructing the MdnsResponse. The serviceName can either be set from a
discovered PTR record, or from the client-specified resolveInstanceName.
Bug: 267570781
Test: atest NsdManagerTest#testResolveWhenServerSendsNoAdditionalRecord
(see separate change).
Change-Id: Icb9ed7ae44179a5df5b69a1e6a0486ffc2d8e42c
For resolve requests, specify the resolveInstanceName in
MdnsSearchOptions.
This will cause discovery to send followup queries when TXT/SRV/A/AAAA
records are missing; for example if only a PTR record is returned
following the discovery probes, or if no discovery probe is sent at all.
Test: atest NsdServiceTest
Bug: 267570781
Change-Id: Ib18c3afbd1533ada7a78dd8ccac993adb439d014
MdnsResponses were only updated through
MdnsResponse.mergeRecordsFrom(MndsResponse), meaning that MdnsResponse
cannot be updated unless a MdnsResponse can be built from the update
packet.
Because a PTR record is required to build a MdnsResponse, this means
that it was not possible to add records to a MdnsResponse unless the
update packet contains a PTR record.
Fix this by having MdnsServiceTypeClient augment its current known
responses in addition to creating new responses from incoming
MdnsPackets.
Bug: 267570781
Test: atest NsdManagerTest#testPtrOnlyResponse with
mdns_discovery_manager_version set to 1.
Change-Id: Iba293b4772fcd79e94ee6412c9af8225a3349f12
MdnsResponse would not replace records if the TTL changed, but this is
necessary in particular in case of exit announcements (RFC6762 10.1)
where the TTL is updated to zero.
Update MdnsResponse to update records if the TTL changed. The
receiptTimeMillis is still not considered to update records, but doing
so would generate service change notifications every time a reply is
received, so this is not covered here.
Bug: 267570781
Test: atest MdnsResponseTests
Change-Id: Ied55829cba6b043d13603a8230bda457c07de42f
When calling MdnsResponse.setInet4AddressRecord with null, the record
was removed from the records list, but not from the inet4AddressRecord /
inet6AddressRecord fields.
Fix that, and update the MdnsResponseDecoder test that missed the bug
because it modified the same incomplete MdnsResponse multiple times
(so isComplete keeps returning false), instead of using a copy of
a complete MdnsResponse.
This requires using a copy constructor, which will be useful for future
changes, so add it with a test.
Bug: 267570781
Test: atest
Change-Id: I199a8e4bc9a54a142c1fec1acee2ab6b1baa7efb
