ATTENTION: GSConnect only supports the latest, stable version of GNOME. We are no longer accepting bug reports for previous versions.
Send file does not work. I have the following rule in iptables: -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP
It's the first of all, at the top of the list of rules.
Each time I try to send a file from the computer to the phone the count of dropped packets in this rule increases. So I think this rule is what is stopping the packets from reaching the phone. Also, a listening connection in IPv6 is left open each time I try to send a file:
gjs 3055 user 99u IPv6 6410988 0t0 TCP *:1759 (LISTEN)
gjs 3055 user 101u IPv6 6431003 0t0 TCP *:1760 (LISTEN)
Appart from those, These are the other connections opened by GSConnect:
js 3055 user 17u IPv6 67014 0t0 TCP *:1716 (LISTEN)
gjs 3055 user 18u IPv6 67015 0t0 UDP *:1716
gjs 3055 user 41u IPv4 6111759 0t0 TCP hostname:40760->192.168.x.x:1716 (ESTABLISHED)
The phone opens a notification with a message telling me that "File reception from hostname failed." (or something similar, I'm not and English speaker, so the message appears in a different language). A 0 byte file copy is left in phone storage.
The reverse situation works, however. Sending from the phone to the computer is not being blocked.
Steps To Reproduce:
Expected behavior
Files should be sent. Packets should be valid.
Screenshots
If applicable, add screenshots to help explain your problem
Support Log
GSConnect Version: 41
GSConnect Install: user
GJS: 16403
XDG_SESSION_TYPE: x11
GDMSESSION: ubuntu
--------------------------------------------------------------------------------
-- Logs begin at Fri 2020-09-04 12:09:29 CEST, end at Sat 2020-09-19 21:21:18 CEST. --
de set. 19 21:20:00 systemd[2320]: gnome-launched-gnome-control-center.desktop-849220.scope: Succeeded.
de set. 19 21:20:05 dbus-daemon[1021]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.2578' (uid=1000 pid=849272 comm="gjs /home/user/.local/share/gnome-shell/extensions" label="unconfined")
de set. 19 21:20:05 systemd[1]: Starting Hostname Service...
de set. 19 21:20:05 dbus-daemon[1021]: [system] Successfully activated service 'org.freedesktop.hostname1'
de set. 19 21:20:05 systemd[1]: Started Hostname Service.
de set. 19 21:20:05 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
de set. 19 21:20:07 org.gnome.Shell.Extensions.GSConnect[3055]: [/service/device.js:sendPacket:446]: OnePlus 7 Pro: {
"id": 1600543207965,
"type": "kdeconnect.systemvolume",
"body": {
"sinkList": [
{
"name": "alsa_output.pci-0000_0b_00.1.hdmi-stereo-extra4",
"description": "HDMI / DisplayPort 5 (Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] Digital Stereo (HDMI 5))",
"muted": false,
"volume": 33237,
"maxVolume": 65536
},
{
"name": "alsa_output.pci-0000_0d_00.3.analog-surround-21",
"description": "Sortida de lÃnia (Family 17h (Models 00h-0fh) HD Audio Controller So envoltant analògic 2.1)",
"muted": false,
"volume": 31966,
"maxVolume": 65536
}
]
}
}
de set. 19 21:20:08 org.gnome.Shell.Extensions.GSConnect[3055]: [/service/device.js:sendPacket:446]: OnePlus 7 Pro: {
"id": 1600543208050,
"type": "kdeconnect.systemvolume",
"body": {
"sinkList": [
{
"name": "alsa_output.pci-0000_0b_00.1.hdmi-stereo-extra4",
"description": "HDMI / DisplayPort 5 (Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] Digital Stereo (HDMI 5))",
"muted": false,
"volume": 33237,
"maxVolume": 65536
},
{
"name": "alsa_output.pci-0000_0d_00.3.analog-surround-21",
"description": "Sortida de lÃnia (Family 17h (Models 00h-0fh) HD Audio Controller So envoltant analògic 2.1)",
"muted": false,
"volume": 31966,
"maxVolume": 65536
}
]
}
}
de set. 19 21:20:11 dbus-daemon[2340]: [session uid=1000 pid=2340] Activating service name='org.gnome.gedit' requested by ':1.2735' (uid=1000 pid=849272 comm="gjs /home/user/.local/share/gnome-shell/extensions" label="unconfined")
de set. 19 21:20:11 dbus-daemon[2340]: [session uid=1000 pid=2340] Successfully activated service 'org.gnome.gedit'
de set. 19 21:20:11 gnome-shell[2755]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x6e00084
de set. 19 21:20:21 org.gnome.Shell.Extensions.GSConnect[3055]: [/service/device.js:sendPacket:446]: OnePlus 7 Pro: {
"id": 1600543221458,
"type": "kdeconnect.systemvolume",
"body": {
"sinkList": [
{
"name": "alsa_output.pci-0000_0b_00.1.hdmi-stereo-extra4",
"description": "HDMI / DisplayPort 5 (Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] Digital Stereo (HDMI 5))",
"muted": false,
"volume": 33237,
"maxVolume": 65536
},
{
"name": "alsa_output.pci-0000_0d_00.3.analog-surround-21",
"description": "Sortida de lÃnia (Family 17h (Models 00h-0fh) HD Audio Controller So envoltant analògic 2.1)",
"muted": false,
"volume": 31966,
"maxVolume": 65536
}
]
}
}
de set. 19 21:20:21 org.gnome.Shell.Extensions.GSConnect[3055]: [/service/device.js:sendPacket:446]: OnePlus 7 Pro: {
"id": 1600543221543,
"type": "kdeconnect.systemvolume",
"body": {
"sinkList": [
{
"name": "alsa_output.pci-0000_0b_00.1.hdmi-stereo-extra4",
"description": "HDMI / DisplayPort 5 (Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] Digital Stereo (HDMI 5))",
"muted": false,
"volume": 33237,
"maxVolume": 65536
},
{
"name": "alsa_output.pci-0000_0d_00.3.analog-surround-21",
"description": "Sortida de lÃnia (Family 17h (Models 00h-0fh) HD Audio Controller So envoltant analògic 2.1)",
"muted": false,
"volume": 31966,
"maxVolume": 65536
}
]
}
}
de set. 19 21:20:26 org.gnome.Shell.Extensions.GSConnect[3055]: [/service/device.js:sendPacket:446]: OnePlus 7 Pro: {
"id": 1600543226544,
"type": "kdeconnect.systemvolume",
"body": {
"sinkList": [
{
"name": "alsa_output.pci-0000_0b_00.1.hdmi-stereo-extra4",
"description": "HDMI / DisplayPort 5 (Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] Digital Stereo (HDMI 5))",
"muted": false,
"volume": 33237,
"maxVolume": 65536
},
{
"name": "alsa_output.pci-0000_0d_00.3.analog-surround-21",
"description": "Sortida de lÃnia (Family 17h (Models 00h-0fh) HD Audio Controller So envoltant analògic 2.1)",
"muted": false,
"volume": 31966,
"maxVolume": 65536
}
]
}
}
de set. 19 21:20:27 gnome-shell[2755]: Window manager warning: WM_TRANSIENT_FOR window 0x50056f9 for 0x50128b1 window override-redirect is an override-redirect window and this is not correct according to the standard, so we'll fallback to the first non-override-redirect window 0x5000007.
de set. 19 21:20:35 systemd[1]: systemd-hostnamed.service: Succeeded.
de set. 19 21:20:35 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
de set. 19 21:20:37 gnome-shell[2755]: ../clutter/clutter/clutter-actor.c:10556: The clutter_actor_set_allocation() function can only be called from within the implementation of the ClutterActor::allocate() virtual function.
de set. 19 21:20:48 org.gnome.Shell.Extensions.GSConnect[3055]: [/service/backends/lan.js:_onIdentity:361]: {
"id": 1600543247704,
"type": "kdeconnect.identity",
"body": {
"deviceId": "fbf2ecbbebbe262b",
"deviceName": "OnePlus 7 Pro",
"protocolVersion": 7,
"deviceType": "phone",
"incomingCapabilities": [
"kdeconnect.telephony.request_mute",
"kdeconnect.notification",
"kdeconnect.ping",
"kdeconnect.notification.reply",
"kdeconnect.notification.action",
"kdeconnect.share.request",
"kdeconnect.clipboard.connect",
"kdeconnect.runcommand",
"kdeconnect.contacts.request_all_uids_timestamps",
"kdeconnect.sms.request_conversations",
"kdeconnect.telephony.request",
"kdeconnect.mpris",
"kdeconnect.sms.request_conversation",
"kdeconnect.findmyphone.request",
"kdeconnect.systemvolume",
"kdeconnect.mousepad.keyboardstate",
"kdeconnect.sftp.request",
"kdeconnect.share.request.update",
"kdeconnect.notification.request",
"kdeconnect.mousepad.request",
"kdeconnect.photo.request",
"kdeconnect.sms.request",
"kdeconnect.contacts.request_vcards_by_uid",
"kdeconnect.mpris.request",
"kdeconnect.battery.request",
"kdeconnect.clipboard"
],
"outgoingCapabilities": [
"kdeconnect.sms.messages",
"kdeconnect.telephony",
"kdeconnect.mpris",
"kdeconnect.notification",
"kdeconnect.contacts.response_uids_timestamps",
"kdeconnect.findmyphone.request",
"kdeconnect.ping",
"kdeconnect.mousepad.keyboardstate",
"kdeconnect.share.request",
"kdeconnect.contacts.response_vcards",
"kdeconnect.notification.request",
"kdeconnect.mousepad.echo",
"kdeconnect.clipboard.connect",
"kdeconnect.mousepad.request",
"kdeconnect.presenter",
"kdeconnect.sftp",
"kdeconnect.photo",
"kdeconnect.runcommand.request",
"kdeconnect.mpris.request",
"kdeconnect.systemvolume.request",
"kdeconnect.battery",
"kdeconnect.clipboard"
],
"tcpPort": 1716,
"tcpHost": "192.168.1.12"
}
}
de set. 19 21:20:50 org.gnome.Shell.Extensions.GSConnect[3055]: [/service/device.js:_readLoop:338]: OnePlus 7 Pro: {
"id": 1600543249154,
"type": "kdeconnect.notification",
"body": {
"id": "0|org.kde.kdeconnect_tp|-1479564009|null|10147",
"isCancel": true
}
}
de set. 19 21:21:15 gnome-shell[2755]: ../clutter/clutter/clutter-actor.c:10556: The clutter_actor_set_allocation() function can only be called from within the implementation of the ClutterActor::allocate() virtual function.
de set. 19 21:21:18 org.gnome.Shell.Extensions.GSConnect[3055]: [/service/device.js:sendPacket:446]: OnePlus 7 Pro: {
"id": 1600543278129,
"type": "kdeconnect.notification.request",
"body": {
"cancel": "43baebaf-e60d-44e0-b528-bd9121e58ca2"
}
}
System Details (please complete the following information):
GSConnect environment (if applicable):
We can add a timeout to transfer connections so they don't block ports waiting forever, but this sounds like a problem with your networking, not GSConnect.
Then, why can I ring the phone? (kdeconnect.findmyphone.request).
Sorry, I'm not sure how that relates? Since there's no mention in your logs of a file share being requested, there's not much for me to go on though.
All TCP connections are opened the same way in GSConnect and the only TCP options we set on sockets are TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT and SO_KEEPALIVE. If these created invalid TCP packets you could never connect your devices at all.
I have to ask though, do you have a good reason for mangling packets?
There's no mention in the logs because it is not getting logged. I followed the procedure to generate a support log. Click on the menu option to generate the support log and then use the extension to reproduce the bug. Finally click on show log, copy and then paste.
It's relevant for a couple reasons, most importantly that no one as reported this error without using such a rule.
It's also relevant because you have reported this only happens when uploading, which indicates the invalid TCP packet is not coming from GSConnect, but from the remote device. The transfer process for uploads is as follows:
If an exception occurred in GSConnect at any point, an error would logged and the connection closed. So here is how I see the situation:
kdeconnect-android.Have you confirmed the GSConnect is producing INVALID TCP packets? If not, then I would assume the packet is coming from kdeconnect-android or being corrupted somewhere else in the network stack.
I am also facing this problem .
i have tried using hotspot and Wi-Fi , disabled VPN also on both devices
Still I am unable to send files from my Ubuntu 20.04 to Android AOSP 10 device
however all other functions i have tried are working
just this file transfer from laptop to mobile does not work however the opposite works like a charm
also clipboard pull (phone>>laptop) does not work but opposite works .
i can send android apps log if its needed
edit
KDEConnect from F-Droid
GSconnect from gnome extension website
Logs would be required, yes. Since we have automated test for this use case, I would still suspect this is a either a networking problem or a problem in kdeconnect-android.
Clipboard is known not to work on Android 10, unless using the notification action. Also please be sure you have configured a download location in the Android app.
I have configured Download Destination in the android app (KdeConnect) under Share and Recive settings to
/tree/primary:Download and re-enabled the persistent notification now it is working .
I will send logs if it misbehaves again.
thanks
When I request a file share from PC to phone, in Wireshark I can see the procedure you described. But after establishing the connection, only TCP keep alive packets are sent. The checksum incorrect notice is normal, it's due to the ethernet card doing the checksum computation on its own. The checksum is not filled by the TCP/IP stack but by the hardware.
The rest of features are not being blocked. Only file transfer. Find the phone, clipboard from computer to phone and viceversa behave as expected.
No. Time Source Destination Protocol Length Info
5173 749.493714852 PC phone TLSv1.2 279 Application Data
5174 749.723491667 phone PC TCP 66 xmsg(1716) → 38312 [ACK] Seq=1 Ack=427 Win=942 Len=0 TSval=2233191502 TSecr=853770164
5175 749.743615845 phone PC TCP 74 43778 → swiftnet(1751) [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=2233191521 TSecr=0 WS=512
5176 749.743647966 PC phone TCP 74 swiftnet(1751) → 43778 [SYN, ACK] Seq=0 Ack=1 Win=0 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 SACK_PERM=1 TSval=928086681 TSecr=2233191521 WS=128
5177 749.753118593 phone PC TCP 66 43778 → swiftnet(1751) [ACK] Seq=1 Ack=1 Win=88064 Len=0 TSval=2233191531 TSecr=928086681
5207 759.595646824 phone PC TCP 66 [TCP Keep-Alive] 43778 → swiftnet(1751) [ACK] Seq=0 Ack=1 Win=88064 Len=0 TSval=2233191756 TSecr=928086681
5208 759.928117554 PC phone TCP 66 [TCP Keep-Alive] 38312 → xmsg(1716) [ACK] Seq=426 Ack=1 Win=1022 [TCP CHECKSUM INCORRECT] Len=0 TSval=853780599 TSecr=2233191502
5211 760.582741069 phone PC TCP 66 [TCP Keep-Alive ACK] xmsg(1716) → 38312 [ACK] Seq=1 Ack=427 Win=942 Len=0 TSval=2233192051 TSecr=853770164
5216 760.708338353 phone PC TCP 66 [TCP Keep-Alive] 43778 → swiftnet(1751) [ACK] Seq=0 Ack=1 Win=88064 Len=0 TSval=2233192176 TSecr=928086681
5249 770.680110419 PC phone TCP 66 [TCP Keep-Alive] 38312 → xmsg(1716) [ACK] Seq=426 Ack=1 Win=1022 [TCP CHECKSUM INCORRECT] Len=0 TSval=853791351 TSecr=2233192051
5251 771.773767323 phone PC TCP 66 [TCP Keep-Alive] 43778 → swiftnet(1751) [ACK] Seq=0 Ack=1 Win=88064 Len=0 TSval=2233193050 TSecr=928086681
5262 775.800124754 PC phone TCP 66 [TCP Keep-Alive] 38312 → xmsg(1716) [ACK] Seq=426 Ack=1 Win=1022 [TCP CHECKSUM INCORRECT] Len=0 TSval=853796471 TSecr=2233192051
5266 776.253627019 phone PC TCP 66 [TCP Keep-Alive ACK] xmsg(1716) → 38312 [ACK] Seq=1 Ack=427 Win=942 Len=0 TSval=2233193493 TSecr=853770164
5293 786.296121153 PC phone TCP 66 [TCP Keep-Alive] 38312 → xmsg(1716) [ACK] Seq=426 Ack=1 Win=1022 [TCP CHECKSUM INCORRECT] Len=0 TSval=853806967 TSecr=2233193493
The rest of features are not being blocked. Only file transfer. Find the phone, clipboard from computer to phone and viceversa behave as expected.
That makes sense, since none of those require a dedicated connection. I don't see any evidence that GSConnect is doing anything wrong here and there are no other reports of this problem.
Sorry, but until I have some hint of what exactly is going wrong for you, I'm afraid there's not much else I can do here.
Well, I found the problematic iptables rules. Removing these allows the file transfer to work again.
*raw
-A PREROUTING -p tcp -m tcp --syn -j CT --notrack
COMMIT
*filter
-A ufw-before-input -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 9 --mss 1460
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
COMMIT
Now I have to figure out how to use SYNPROXY to allow conntrack to track the flow instead of dropping follow up packets.
All right. It was a matter of rule ordering in the firewall configuration. And Wireshark captured the 3WHS ACK that iptables was dropping due to being invalid (nf_conntrack_tcp_loose disabled) because of how SYNPROXY works. Better capture a mirrored flow or use ulogd-pcap.
If the connection remains open because the phone was sending out of order keep alive ACKs in SYNPROXY's eyes with it waiting forever for the 3WHS ACK, I don't know. That would be standard TCP behaviour, but SYNPROXY might work differently.
Sorry for the inconvenience. Closing issue.
Most helpful comment
Logs would be required, yes. Since we have automated test for this use case, I would still suspect this is a either a networking problem or a problem in
kdeconnect-android.Clipboard is known not to work on Android 10, unless using the notification action. Also please be sure you have configured a download location in the Android app.