nitroshare-desktop
nitroshare-desktop copied to clipboard
Connection refused with version 0.3.4 in Ubuntu
When I try to send files or directories from Ubuntu (17.10) with Nitroshare 0.3.4 (downloaded from the PPA) to my Android device (with the most recent version downloaded from PlayStore, 0.4.0.35), it reports connection refused. However, it works perfectly vice-versa.
I'll take a look. The Android app shares its assigned addresses with the desktop app via mDNS. This protocol allows multiple addresses to be specified so it's possible that the desktop app is using the wrong one.
I can confirm the bug with Nitroshare 0.3.4 from PPA on Ubuntu 18.04, to an Android device with most recent version from PlayStore. Ubuntu -> Android: Connection refused, Android -> Ubuntu: works well.
Kind of a show-stopper for me since I would use Nitroshare mainly to upload to Android devices.
Confirming the same behaviour on Fedora 27.
@nathan-osman Exactly right. I've the same issue as others on Fedora 27. And one more thing is the notification has a old design and graphic on my GNOME it will be pretty cool if it can be re-design and also it doesn't support my dark theme (arc-dark-solid)
Cannot repro this bug, Ubuntu 17.10 VM, Nitroshare 0.4.0.37 Android, LG V10 7.0. This bug is weird.
I'm facing the same issue on Arch (installed from AUR), trying to send to an Android 8.1 Oreo device.
Hello, I can confirm having this same problem.
I am using Arch linux, with both latest version of android and mobile app...
According to traffic sniff, android phone does broadcast properly, but, linux never tries to connect to it (according to my interpretation of strace)
When I try to print out address to connect from TransferSender, I get gibberish...
Sorry for that, I wass logging it wrong.
I think I narrowed it down to this:
https://gist.github.com/nemanjan00/4489f4af6ca7444c27b10dcc5c76e028
Ok, I did just get some progress:
$ nc -v -6 fe80::a650:46ff:fe28:726d 40818
nc: connect to fe80::a650:46ff:fe28:726d port 40818 (tcp) failed: Invalid argument
Looks like this is not local to this app...
Ok, apperently, this is expected behaviour, according to this:
https://www.linuxquestions.org/questions/linux-newbie-8/urgent-iperf-does-not-work-to-run-tcp-traffic-using-ipv6-ip-same-work-with-ipv4-ip-4175499745/#post5142674
So, solution is disabling IPv6.
So, solution is disabling IPv6.
Disabling ipv6 from network manager did not improve the situation here.