Bug 435167

Summary:	IPv6: file browsing freezes on IPv4/IPv6 hydrid network due to nonsensical address passed to ssh
Product:	[Applications] kdeconnect	Reporter:	Thiago Macieira <thiago>
Component:	common	Assignee:	Albert Vaca Cintora <albertvaka>
Status:	ASSIGNED ---
Severity:	normal	CC:	nate
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Thiago Macieira 2021-03-30 22:21:47 UTC

SUMMARY
On a network with both IPv4 and IPv6, KDE Connect does find my Android phone, as shown by the system tray applet and the device itself (unlike bug 427310). Most functions work. File browsing does not and causes Dolphin and Plasma to freeze.

STEPS TO REPRODUCE
1. Connect both the computer and Android phone to a network with both IPv4 and IPv6
2. Ensure that KDE connect connects
3. Attempt to browse files on the phone

OBSERVED RESULT
Dolphin and Plasma freeze for a time. After some time (a minute?), Dolphin displays a message in red at the top like "The file or folder /run/user/1000/xxxxxxxxx/primary does not exist" (it really doesn't).

EXPECTED RESULT
KDE Connect browses my files.

SOFTWARE/OS VERSIONS
openSUSE Tumbleweed
KDE Plasma Version: 5.21.3
KDE Frameworks Version:  5.80.0
Qt Version: 5.12.2
KDE Connect Version: 20.12.3

ADDITIONAL INFORMATION
When the freeze is active, ssh can be seen in ps to run with the following arguments:

ssh -x -a -oClearAllForwardings=yes -oPort=1740 -F/dev/null -oIdentityFile=/home/tjmaciei/.config/kdeconnect/privateKey.pem -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oHostKeyAlgorithms=+ssh-dss -oServerAliveInterval=30 -oNumberOfPasswordPrompts=1 -2 kdeconnect@2601 -s sftp

That "2601" is nonsensical. It's causing ssh to attempt to connect to IP 0.0.10.41. That "2601" is the first part of my IPv6 network address (as a Comcast subscriber, I'm given a network in the prefix 2601:1c0::/26).

Comment 1 Thiago Macieira 2021-03-30 22:33:16 UTC

sshfs command-line seems to be:

/usr/bin/sshfs kdeconnect@2601:1c0:xxxx:yyyy:4501:635c:ccfc:6576:1c93:dd1d:/ /run/user/1000/2f299915d02c5133 -p 1743 -s -f -F /dev/null -o IdentityFile=/home/tjmaciei/.config/kdeconnect/privateKey.pem -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o HostKeyAlgorithms=+ssh-dss -o uid=1000 -o gid=100 -o reconnect -o ServerAliveInterval=30 -o password_stdin

Which is also incorrect.

Comment 2 Bug Janitor Service 2021-03-31 02:43:08 UTC

A possibly relevant merge request was started @ https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/389

Comment 3 Thiago Macieira 2021-03-31 15:55:43 UTC

(In reply to Bug Janitor Service from comment #2)
> A possibly relevant merge request was started @
> https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/389

I have a similar change that I was going to push to MR, but I can't test it. After updating kdeconnect with my change, it starts sshfs with the IPv4 of my phone.

How does the discovery decide what address(es) to try?

Comment 4 2wxsy58236r3 2021-04-01 00:44:29 UTC

My network is also IPv4/IPv6 hybrid, and it seems that if I unpair and pair the devices again, and then browse the device via Dolphin, IPv6 will be used.

But after a period of time, it will fallback to IPv4 again. It seems that IPv4 is preferred most of the times.

Comment 5 Thiago Macieira 2021-04-01 03:00:46 UTC

(In reply to 2wxsy58236r3 from comment #4)
> My network is also IPv4/IPv6 hybrid, and it seems that if I unpair and pair
> the devices again, and then browse the device via Dolphin, IPv6 will be used.
> 
> But after a period of time, it will fallback to IPv4 again. It seems that
> IPv4 is preferred most of the times.

That's not good. The selection should be deterministic, preferably using established RFCs (3484 and 6724 come to mind, but I don't think they are correct for this purpose). Since they are always intra-network (link-local) addresses, I suppose we should prefer the local addresses to avoid accidentally trafficking over routers and over the Internet, in which case the order should be:

1) IPv6 link-local addresses, if possible (fe80::/64) - not always possible because they need a scope identifier in the address and some tools will not like that
2) IPv4 link-local addresses (169.254.0.0/16)
3) IPv6 realm-local addresses (you can probably ignore this)
4) IPv6 site-local addresses (fec0::/8 [deprecated], you can probably ignore this)
5) IPv6 unique local addresses (fc00::/7)
6) IPv4 addresses reserved by RFC 1918 and 6598 (10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12, 192.168.0.0/16)
7) IPv6 global addresses
8) IPv4 global addresses

Or, alternatively speaking, sort addresses by ascending scope by grouping the IPv6 local addresses with IPv4 private-use and shared-use ones, and IPv6 preferred over IPv4 in each scope. See https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml#ipv6-scope for the full list.

IPv6 v4-compat (::/96), Teredo (2001:0::/32) and 6to4 (2002::/16) addresses should be excluded. IPv6 v4-mapped addresses (::ffff:0.0.0.0/32) should be treated like IPv4.