https://bugs.kde.org/show_bug.cgi?id=521261
Bug ID: 521261
Summary: Android KDEConnect ignores discovery packets when in
public subnets
Classification: Applications
Product: kdeconnect
Version First unspecified
Reported In:
Platform: Other
OS: Android 11.x
Status: REPORTED
Severity: normal
Priority: NOR
Component: android-application
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
DESCRIPTION
When connected to a subnet with public addresses Android KDEConnect ignores
discovery packets. As a result, it is unable to pair with a host if that host
has an address not in the private address space (for IPv4 192.168.0.0/16,
10.0.0.0/8, 172.16.0.0/12). This happens even if Trusted Networks is set to
"Trust all networks" or the particular SSID is set as trusted. This is similar
to report #516214, but there no details exist about the address space, so I am
not sure if this is a duplicate. The cause for this is commit #72881f8b and
some subsequent relevant commits. The problem happens even when adding devices
by IP manually.
Some companies/research institutions/universities offer public addresses to
devices connecting to their network. I think those people shouldn't be
precluded from using KDEConnect. In my case, it's Eduroam with 139.91.0.0/16.
PROPOSED SOLUTION
I am conflicted on what the best solution would be. I have come up with 4
proposals:
1. Allow packets from all networks (again), as was the case before commit
#72881f8b.
- Pros: Easy to setup, no user interaction required
- Cons: In theory, in a misconfigured network with no firewall, attackers
might connect from the outside
2. Allow said packets when connected to trusted SSIDs. This could be the same
option as Trusted Networks or a different menu.
- Pros: Easy to setup, very little if any user interaction required
- Cons: By default Trusted Networks is set to "trust all", giving the same
cons as proposal #1
3. Allow configuration of the subnets to accept packets from. This could be
the same option as Trusted Networks or a different menu.
- Pros: Allows fine-grained control, blends easily with the current approach
(private subnets can be configured as acceptable by default)
- Cons: Slightly advanced networking knowledge required, possibly mitigated
by proper tutorial/sensible defaults
4. Accept packets from the same subnet as the phone.
- Pros: Easy to setup
- Cons: Coarse-grained, networks assign different subnets to WiFi/Ethernet
clients. This wouldn't solve the problem 100%.
I am leaning between options 3 or 4, but would love to discuss it. I would love
to make a PR with this to contribute to the KDEConnect project, I use it too
much to not contribute.
STEPS TO REPRODUCE
1. Connect a Linux PC and an Android device to a subnet with public addresses
(e.g. EduRoam at 139.91.0.0/16)
2. Try to connect the devices
3. Each device can ping the other
4. No device discovers the other
OBSERVED RESULT
Neither device offers to pair with the other
EXPECTED RESULT
Devices should pair with each other
SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux KDE Edition, KDE Neon
KDE Plasma Version: 6.6.5
KDE Frameworks Version: 6.26.0
Qt Version: 6.11.1
--
You are receiving this mail because:
You are watching all bug changes.
