andyholmes
commented
4 years ago 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.
Closed gnusuari0 closed 4 years ago
andyholmes
commented
4 years ago 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.
gnusuari0
commented
4 years ago Then, why can I ring the phone? (kdeconnect.findmyphone.request).
andyholmes
commented
4 years ago 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?
gnusuari0
commented
4 years ago 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.
andyholmes
commented
4 years ago 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.
cleanerspam
commented
4 years ago 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
andyholmes
commented
4 years ago 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.
cleanerspam
commented
4 years ago 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
gnusuari0
commented
4 years ago 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=2233193493The 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.
gnusuari0
commented
4 years ago 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
COMMITNow I have to figure out how to use SYNPROXY to allow conntrack to track the flow instead of dropping follow up packets.
gnusuari0
commented
4 years ago 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.
gsconnect-log.txt
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:
Appart from those, These are the other connections opened by GSConnect:
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
System Details (please complete the following information):
GSConnect environment (if applicable):