Create Task
Maniphest T15164

Notify user when automatic device discovery is disabled on the current network
Open, LowPublic
Actions

Description

(aka UDP broadcasting is disabled on the network):

The current Objective-C network backend already contains a check that lets the host device ignore its own ID packet when it is received (so it doesn't try to discover itself). However, on a network environment with UDP broadcasting disabled, the host's own ID packet will never be received by the host itself.

Perhaps this same check can be used to determine wether the host device is on a network environment with UDP broadcasting disabled, and then prompt the user to add devices directly by IP, since automatic discovery would be non-functional?

Perhaps the IP address of the host device can also be included in this prompt to save the user the trouble of going into settings can digging it out?

lucaswzx created this task.Jan 2 2022, 6:19 AM
lucaswzx renamed this task from Add pop-up notification when device didn’t receive its own ID packet to Prompt user when device didn’t receive its own ID packet.
lucaswzx renamed this task from Prompt user when device didn’t receive its own ID packet to Prompt user when automatic device discovery is disabled on current network.
lucaswzx renamed this task from Prompt user when automatic device discovery is disabled on current network to Notify user when automatic device discovery is disabled on current network.
lucaswzx updated the task description. (Show Details)
lucaswzx renamed this task from Notify user when automatic device discovery is disabled on current network to Notify user when automatic device discovery is disabled on the current network.Jan 2 2022, 6:24 AM
lucaswzx triaged this task as Low priority.Jan 2 2022, 6:56 AM
turx claimed this task.Jan 15 2022, 5:54 AM
turx added a subscriber: turx.

I am happy to help solve this problem, and I have macOS/iOS devices with the latest software. Could you please provide me a hint that how to set up a UDP-broadcast-disabled network environment for a connected iOS device or an Xcode simulator?

turx added a comment.Jan 15 2022, 10:01 AM

I have implemented a rough version.

turx added a comment.EditedJan 15 2022, 10:25 AM

Here is my patch based on the most recent commit b2b8673fc301d4fd4d69fef620484efa9daecbdf:

turx-210115-0418.patch7 KBDownload

lucaswzx added a comment.EditedJan 15 2022, 8:51 PM

Hi turx! I took a look through the diff of the patch and it seems like the idea behind the implementation is sound. Though I'm not sure what potential problems the hard-coded 1 second wait would be.

Have you tested this in an actual broadcasting disabled environment yet? I'm curious how you did it. For your first question, I had some ideas but I haven't tried them out:

  • The most realistic approach: go into your router settings (usually 192.168.1.xxx) and literally turn off the broadcast feature. This will test as intended: pop-up shows up, and then adding the remote device's LAN address manually will allow discovery.
  • Simulated approach: block UDP port 1716 on the device running KDE Connect/Simulator to prevent it from receiving (or sending) the ID packet. This will test the pop-up properly, but unlike the previous method, adding addresses directly WILL NOT allow discovery since 1716 is just blocked no matter what.

Plz do note that doing either could potentially affect other processes running on your network, so keep in mind of that.

apollozhu moved this task from Ideas to In progress on the KDE Connect board.Jan 15 2022, 9:06 PM
apollozhu added a subscriber: apollozhu.Jan 15 2022, 9:11 PM

Hi turx, thanks for taking an initiative in solving this! Since we only use Phabricator to keep track of tasks, it would be great if you can start a merge request on KDE Invent GitLab https://invent.kde.org/network/kdeconnect-ios so it's easier for us to review and merge your contribution.

turx added a comment.Jan 15 2022, 10:20 PM
In T15164#269734, @lucaswzx wrote:

Hi turx! I took a look through the diff of the patch and it seems like the idea behind the implementation is sound. Though I'm not sure what potential problems the hard-coded 1 second wait would be.

Have you tested this in an actual broadcasting disabled environment yet? I'm curious how you did it. For your first question, I had some ideas but I haven't tried them out:

  • The most realistic approach: go into your router settings (usually 192.168.1.xxx) and literally turn off the broadcast feature. This will test as intended: pop-up shows up, and then adding the remote device's LAN address manually will allow discovery.
  • Simulated approach: block UDP port 1716 on the device running KDE Connect/Simulator to prevent it from receiving (or sending) the ID packet. This will test the pop-up properly, but unlike the previous method, adding addresses directly WILL NOT allow discovery since 1716 is just blocked no matter what.

    Plz do note that doing either could potentially affect other processes running on your network, so keep in mind of that.

I am not able to disable the UDP broadcast on my OpenWRT router as there is no option for me to set it, and my set of iptables rules does not take effect. Instead, I managed to block all inbound traffic through macOS firewall, and the pop-up shows up, and the pop-up disappears as expected when I turn off the firewall. However, in this way, I cannot test the effect of manually added IP which could be reachable.

I am not able to run KDE Connect on my real iOS device as I do not have a full Apple Developer certificate (i.e., enrolled in Apple Developer Program), so I am encountering the error Provisioning profile "iOS Team Provisioning Profile: org.kde.kdeconnect.turx" doesn't include the com.apple.developer.networking.multicast entitlement. when I try to build it for a real iOS device. Consequently, I can only run it on an Xcode simulator.

For the hard-coded 1-second wait, the design of the computer network does not guarantee when could the broadcast package be received by the broadcaster itself, and it is not feasible to leave the program waiting for the package forever (It has an analogy to the halting problem, I think). The wait assumes a worst-case two-way LAN responding time with the gateway to be 1 second.

turx added a comment.Jan 15 2022, 10:35 PM
In T15164#269736, @apollozhu wrote:

Hi turx, thanks for taking an initiative in solving this! Since we only use Phabricator to keep track of tasks, it would be great if you can start a merge request on KDE Invent GitLab https://invent.kde.org/network/kdeconnect-ios so it's easier for us to review and merge your contribution.

I have created a merge request.

apollozhu added a comment.Apr 12 2023, 10:40 PM

I feel like there's no reliable that we can do this. Do you think we can just change this to a won't fix and close https://invent.kde.org/network/kdeconnect-ios/-/merge_requests/37?