Initial investigations: LAN peer discovery
Port the LAN peer discovery code from the Disco app to the public mesh testbed, bring it up to date, wire it up to the UI, and see whether we can use wake locks, wifi locks and/or multicast locks to solve the issues reported here with the success rate dropping when the screen is turned off. We also need to test on newer API levels and work out what permissions are required on each API level.
It would be useful to know whether LAN peer discovery typically works for devices connected to a wifi hotspot (created manually via the system settings app) and/or a Wi-Fi Direct legacy mode hotspot (we could use the Offline Hotspot app for testing this).
Subtask of #1 (closed). Related to briar#28.
Activity
marked this issue as related to #1 (closed)
marked this issue as related to briar#28
assigned to @akwizgran
This PhD thesis has some useful information about IP multicast over wifi: https://aaltodoc.aalto.fi/bitstream/handle/123456789/108563/isbn9789526403229.pdf?sequence=1&isAllowed=y (section 3.1, page 87 of the PDF onward)
Edited by akwizgran-
Two devices (Huawei P8 Lite 2015 and P8 Lite 2017) don't seem to receive LSD multicast advertisements, even when the screen is turned on. Both devices can send LSD advertisements. The Huawei Y6P and Alcatel A3 XL can send and receive.
When using NSD (with DNS service discovery rather than UPnP), all four devices can send and receive advertisements. However, the P8 Lite 2015 doesn't receive the attributes map in the advertisement.
The P8 Lite 2015 does however send an attributes map, which is received by the other three devices.
Edited by akwizgran -
It's probably worth noting that NSD is also a special case for Android apps running on ChromeOS: apps can't generally make or receive connections via the LAN, except in the case of outgoing connections to services discovered via NSD. See briar#1362.
-
To do: Test whether NSD works over WFD groups, and specifically whether a device providing a legacy mode hotspot can discover clients via NSD. This comment suggests that NSD service resolution will fail for network interfaces that don't have an associated Network instance:
-
Tested with the wifi-direct-and-nsd branch.
When discovering services via NSD, one needs to resolve each service found to find out IP address, port etc.
NsdManagerhas a methodresolveService()for this. Only one service can be resolved at a time, an error with codeFAILURE_ALREADY_ACTIVEwill appear when a second simultaneous resolve request is submitted. Hence it is important not to call that method right away when new services have been discovered, instead a queue needs to be maintained and worked on one by one. Resolving a service can succeed or fail and after both events, it should be possible to resolve the next service. It seems however, that sometimes resolving neither succeeds nor fails, but instead we receive a service lost event. We don't get any updates on the resolving request afterwards, but we also cannot submit a new resolve request afterwards, they will still fail with aFAILURE_ALREADY_ACTIVEerror. Even restarting the service discovery entirely did not seem to help.-
It looks to me like the only way to remove the NsdService's ClientInfo instance, which holds state relating to the client (i.e. our app), is for the service to receive an UNREGISTER_CLIENT message.
This message is only sent by NsdService.NsdServiceConnector#binderDied(), which overrides IBinder.DeathRecipent#binderDied().
The IBinder javadoc says this:
If this binder object unexpectedly goes away (typically because its hosting process has been killed), then the given IBinder.DeathRecipient's DeathRecipient.binderDied() method will be called.
You will only receive death notifications for remote binders, as local binders by definition can't die without you dying as well.
So it seems that the UNREGISTER_CLIENT message is only meant to be used when the remote process (i.e. our app) dies. I can't see any way for us to remove the ClientInfo instance, which contains the mResolvedService field that prevents any further resolutions from starting, short of exiting our app process.
Edited by akwizgran
-
The issue with the P8 Lite seeing an empty attributes map is probably this one:
-
The lan-service-discovery-nsd-no-resolution branch encodes the IP address in the NSD service name, allowing us to skip the buggy resolution step.
This means we can't advertise attributes, unless we encode them in the service name along with the address or fetch them separately via unicast. This (abandoned) library implements the latter approach to work around the empty attributes map issue mentioned above:
https://github.com/youviewtv/tinydnssd
Alternatively we could implement our own unicast protocol for fetching attributes, while still using NSD for the multicast part, to benefit from the special treatment it seems to get on some devices.
Edited by akwizgran changed milestone to %Public mesh research
-
TODO: Modify the LSD branch to use broadcast rather than multicast (following the approach used by KDE Connect). Test whether this affects which devices can discover each other over which LANs.
removed Sponsor 6 label
