I am trying to set up KDE Connect between a machine running Linux Mint and my Android-device. It does not show up, and it turns out I don’t receive any response if I ping it, and I have the same issue trying to ping the machine from my Android device (from Termux). I’ve tried two different Android devices, but no luck.
This is not an issue with two other machines I have. Both have KDE Connect setup and I can ping the phone just fine, and I can also ping from the phone. They’re all connected to the same VLAN. I can also ping from this machine to the other machines. ufw is disabled.
What could be the issue here?
EDIT: Connection established suddenly after installing and running iptraf.
I fixed this on my EndeavourOS machine by enabling kdeconnect in the firewall settings.
ufw is disabled, so it shouldn’t matter if it is set up or not, right? As far as I can tell I don’t have any other firewall software running - I’ve not installed anything, so it would be the default Linux Mint-stuff that I would have installed and enabled in that case.
if you decide to turn ufw back on:
sudo ufw allow 1714:1764/udp
sudo ufw allow 1714:1764/tcp
This. And check that no device uses a VPN
Related, but just hanging this on here. As the default (as installed) security of distributions has improved, so have the amount of headaches when trying to use tools like this increased. For decades, when I’ve had issues like this is not been because of a LAN firewall issue, and so now my first thought is never been, “I should check the firewall,” when it should.
Sadly, firewall info is almost always locked down so that apps can’t even check by themselves and provide helpful hints to users.
Anyway, it’s been a hard lesson for me to learn, for some reason. I need to practice my mantra: it’s always the firewall.
Its crazy, on Windows programs seem to be able to poke holes in the firewall themselves.
Install iptraf on the machine that’s being troublesome, to see if the ping traffic even registers on the interface
Very strange - I just installed it, and as soon as I ran it, the output in Termux went from “Destionation Host Unreachable” to responses from my machine. Outbound pings from my machine also now get a response. I assume this was only supposed to help diagnose and not fix the issue? :p
KDE Connect is still acting up though, but at least they can talk to each other now! Thanks :)
With your EDIT my first thought was “Have you tried turning it off and on again?”.
Hehe yeah, this persisted over several days and through several reboots and on two different phones. No clue what changed as I understood iptraf to simply help me diagnose. But a run directly before and after running iptraf for the first time had different results, and now I am reproducing it every time.
Which version of KDEConnect do you run in Linux Mint? Seems like they package an old version from what I gather when searching for answers:
https://discuss.kde.org/t/can-not-pair-android-phone-and-linux-mint-21-1-desktop-with-kde-connect/1455
https://old.reddit.com/r/linux/comments/1b5fvay/how_do_users_of_mint_or_other_debianbased_distros/Are your other machines running distros with more up to date repositories?
I’ll look closer into this when I’m back at the computer in about an hour. In the post on the KDE forum, they seem to get an error complaining about the version though, while in my case they don’t show up at all when I attempt to pair. I’ve checked the things listed on the KDE Connect wiki, but those checks pass.
EDIT: UDP discovery was turned off on my phone, and turning it on allowed connection. All is good now!
Sweet! Here comes a random tidbit now that your problem is solved.
Easy screen mirroring of android to linux:
Prereqs:- Setup DHCP to always assign the same IP to the phone.
- Install adb and scrcpy on the Linux machine.
- Allow the linux machine to usb debug the phone.
- Allow wireless debugging in the phone settings.
.bashrc function:
#Connect to Android and view phone screen
#Tip: If using PIN on lock screen you can unlock by entering PIN + Enter even if screen is black
function phoneconnect(){
sudo adb start-server
adb tcpip 2233
adb connect <phoneIP>:2233
scrcpy
}
Simply write phoneconnect in terminal when both devices are accessible on the LAN and you can remote control your phone. Some applications will blacken the screen on the computer if sensitive data is shown.
Cheers, that’s pretty cool! I’ve looked into scrcpy before, but never got around to testing it. The way you present it is super easy, so I will definitely give this a shot!
Regarding my problem, it seems it wasn’t as fixed as I thought :p The connection issue described in the original post still comes once in a while, not sure what triggers it, but it usually resolves if I ping the device and run iptraf to monitor the traffic. Probably superstitious, seems weird to me that it should fix it. It also happened once between my laptop and my new machine, so it was not isolated to the phone after all.
If you’re using wireless then you could try disabling power saving on the wifi card. It will drain more battery but the only reason I can see iptraf helping is if it wakes the network card.
https://unix.stackexchange.com/questions/269661/how-to-turn-off-wireless-power-management-permanently#315400I’ve already done that after having had very slow speeds in a room far away from the WiFi hotspot. But another thing I’ve noticed is that the TxPower-setting is very low (3 dBm), which I believe was the real culprit for the slow speeds. I think the max allowed value of this is 20 (according to a line in the
dmesg
output), so I’ve been wondering if I could just change this to a higher value. It is now placed close to the router, so I am thinking of connecting it by cable (I just don’t have one at the moment) - maybe that could solve my other problem as well.This is yet another problem, but do you know if the TxPower-setting could affect the Bluetooth-capabilities? I use a keyboard connected by Bluetooth. When I run the Dolphin Emulator, where I’ve set it to emulate a Bluetooth-adapter and search continuously for my Wii-remotes, it seems to interfere with the keyboard-signals.