Device linking - broadcast-based host discovery

[pheldal]

I'm struggling to get device-linking to work for android devices. I've been looking at the available tips and related posts on the forum, but can't seem to be able to establish a working connection between android hosts. One device may be able to connect to another, but not vice versa. However, there is nothing happening after the initial connection is made. I do unfortunately not have a wireless AP with packet-capture so that leaves me wondering how the link mechanism/protocol works. The recommendations for router-configuration does indicate that the selection of addresses for bandhelper hosts within the subnet may have something to do with how quick a broadcasting node can be discovered. For network applications this is often an indication of SYN-scan across the local subnet. I see no devices appearing in the list of available nodes to connect to even after scanning for 8-10 minutes in a /24-network where the DHCP-range is in the upper half of the available addresses. One has to enter the device-id manually to establish a connection. A more efficient broadcast-based handshake-mechanism seem to be sorely needed.

Higher-level developer-libraries on iOS and android unfortunately offer incompatible mechanisms to handle broadcast and handshaking between nodes on a subnet. It would thus be preferable to implement device scanning as a UDP broadcast-listener on broadcasting bandhelper-hosts that respond to clients asking for broadcasters to identify themselves. This low-level (BSD-socket) approach is device-independent and would make it possible execute a complete scan for available nodes on any size subnet in a fraction of a second.  In android it is relatively simple to access the socket-library from java (example: https://gist.github.com/finnjohnsen/3654994) and set up a broadcast listener in an app.

[arlo]

I'm struggling to get device-linking to work for android devices. I've been looking at the available tips and related posts on the forum, but can't seem to be able to establish a working connection between android hosts. One device may be able to connect to another, but not vice versa. However, there is nothing happening after the initial connection is made.

If you want me to troubleshoot that, please tell me what you are using device linking for (screen sharing or remote control) and what actions you are taking after making the connection.

A more efficient broadcast-based handshake-mechanism seem to be sorely needed.

Optimizing the peer discovery process is on my wish list.

[pheldal]

I've been testing device-linking for both screen sharing and remote control. What threw me off at first was that some devices seem unable to act as a broadcaster. Remote control and screen-sharing work fine once a connection is established and the client is configured to act on events received.

There are occasional crashes for which system and debugging-information is gathered and passed via Google Play.

An older Nexus 7 tablet (192.168.0.104/24) with Android 5.1.1 (Cyanogenmod 12.1) works quite reliably as a broadcaster of remote control events or screens. It occasionally fails to respond to connection-attempts after broadcasting has been enabled, but toggling broadcasting off and back on fixes that.

A Samsung Galaxy S4-Active smartphone (192.168.0.106/24) with the official android from Samsung (android 5.0.1) works as a remote client, but is unable to act as a broadcaster. It simply does not respond to anything when clients try to connect. I'm looking for differences to explain why this unit doesn't work, but have not yet discovered anything beyond the slightly older android-version.

I also tried an Android-emulator (bluestacks) on OS X (192.168.0.199/24), but the emulator implements networking through a virtual network interface (10.0.2.15) on a separate subnet (10.0.2.0/24) and NAT. This will not work for any kind of incoming connection. I do NOT expect remote-control to work in this scenario.

A borrowed newer Nexus 7 (192.168.0.101/24) with the official android distribution (android 6.0) works fine both as client and server.

I will investigate further once I have the time to do some testing in my home-network where there are multiple APs (sharing the same IP subnet) on a wired network that I can connect a protocol-analyser to.

[arlo]

I've been testing device-linking for both screen sharing and remote control. What threw me off at first was that some devices seem unable to act as a broadcaster.

There should be no difference in a device's ability to broadcast or receive device linking data, but I have occasionally heard about a device that simply doesn't respond to a connection request. I suspect this has more to do with the state of the app getting hung up somehow, rather than the device itself, but I can't reproduce the problem. If you can figure out a specific series of actions that triggers the problem, or fixes the problem after it is triggered, that would be helpful. Something like turning off the broadcast option and turning it on again, or force-quitting and restarting the app. This report would need to specifically say exactly what buttons you were pressing, rather than a summary like "I connected as a remote client."

There are occasional crashes for which system and debugging-information is gathered and passed via Google Play.

Those crash logs can be useful if you send me a step-by-step description of what action triggered the crash, and also put your name into the crash log description when sending it to Google so I can look it up in their database.

[arlo]

I just released new app versions with a more efficient device discovery function. More info is here:

http://forum.arlomedia.com/index.php/topic,1600.0.html