Connection refused

[AlexYuan]

Describe the bug

DioError [DioErrorType.other]: SocketException: Connection refused (OS Error: Connection refused, errno = 61), address = 192.168.1.3, port = 59495 Source stack: #0 DioMixin.fetch (package:dio/src/dio_mixin.dart:488) #1 DioMixin.request (package:dio/src/dio_mixin.dart:483) #2 DioMixin.post (package:dio/src/dio_mixin.dart:97) #3 SendNotifier.startSession (package:localsend_app/provider/network/send_provider.dart:97)

To reproduce

send a file from macos to iphone.

Expected behavior

get a error

Screenshots

No response

Desktop (please complete the following information)

No response

Smartphone (please complete the following information)

No response

Additional context

No response

[sprhawk]

I got same error, sending file from Linux to iOS

I only opened 53319 tcp/udp in firewall, it can discover devices, but when send files from Linux to iOS, it reported same error. The refused port seems to be a random port.

[Tienisto]

Does accept works? Do you get to the progress page?

[sprhawk]

Does accept works? Do you get to the progress page?

Yes I can receive file from the same iOS.

Do you think this is related to firewall?

[c-yau]

received the same error when attempting to send files from Windows to iOS. The other way around works. (iOS to Windows). Am using the lastest 1.7.0 version on Windows

[aggonzo326]

I also have this issue. I have this error when sending to macOS or sending from macOS with the secondar device being Android or Windows 11.

Anyone else able to successfully use LocalSend with macOS devices on arm64????

[mkalinski]

I encountered the same problem with Android to Linux transfer.

The connection is refused because of the firewall on the receiver. It works when the firewall is disabled completely.

Transfer in the other direction (Linux to Android) worked for me. Perhaps my Android doesn't have a (strict enough) firewall?

The real problem is: why is this randomized port being opened for file transfer? Was it meant to be happening? Is this a bug? The protocol documentation is rather unclear on what port is supposed to be used to receive data through. I would think that it would be 53317, since it's the only one that can be configured, but the documentation only explicitly says that it's used for discovery.

[Tienisto]

Hello, port 53317 is used both for discovery and for file transfer. The random port is likely the port opened on the sending device when doing an HTTP request (ephemeral ports).

[mkalinski]

If 53317 is used for discovery and file transfer, then why is a random port being opened? What is it used for?

If this is intended behaviour, then it probably makes the app unusable in environments with strict firewalls (unless I misunderstand something).

[Tienisto]

As I said, the receiving device opens the HTTP server on port 53317. HTTP clients can open any port to connect to 53317.

This is actually no different when you open a website. Your browser will open any random port to connect to 80/443. The browser will not open the port 80 or 443 to connect to the server.

It is enough to open the UDP and TCP port 53317 to be able to receive files. I don't know much about Linux but you may check the firewall logs if you notice anything wrong.

Edit: To be clear, the sending device is the HTTP client. The receiver is the HTTP server. The receiver's port is fixed but the sender's port is random. This is normal behaviour that can be seen in regular browsers.

[mkalinski]

The key observation to me is that when the firewall is disabled, the transfer is successful. This suggests that:

1. The client connects to server to prepare file transfer. This must be happening through the configured (53317) port.
2. The server must somehow be opening another, random port on its host, and the client must know of this port and tries to send data to it. If there's no firewall, the communication is successful, and the server receives the data. If there's firewall, the communication fails when the client tries to send to the random port that is not exempt on the firewall. And the client receives "connection refused".

Based on your reply, I assume this is a bug and not intended behaviour.

Looking at the protocol documentation, I can imagine the bug may be happening because either:

• The client sends a wrong, random port in info.port field of POST /api/localsend/v2/prepare-upload request, instead of 53317, and then the client and the server try to set up file transfer through this port.
• The server somehow instructs the client to send the file to a different port through the response to POST /api/localsend/v2/prepare-upload (that contains the sessionId and fileTokens).

Those are just guesses. I did not analyse the app's code, or the network traffic, so I don't know what is actually possible (the info.port field and the format of tokens are not documented).

I passed up on using LocalSend because of this error, so I'm not going to analyse this further, sorry. I just posted these observations in hopes they could be somehow useful.

[andrewheadricke]

I just had this issue, sending to iOS ipad. The iPad was discovered and appeared as a destination, however sending files to it received an error. Socket refused.

I swipe closed the app and restarted it and the transfer worked fine.

I've only been using Localsend for a few hours, all other transfers have worked well so far.

[buyddy]

Getting the same error when sending from Android to MacOS Sonoma. The other way around is fine. Can send from another MacOS (Ventura) to the Sonoma machine. The issue seems OS dependent.

[einarpersson]

Same, when attempting to send from Samsung Android to Iphone

DioException [connection error]: The connection errored: Connection refused This indicates an error which most likely cannot be solved by the library.
Error: SocketException: Connection refused (OS Error: Connection refused, errno = 111), address = 192.168.32.9, port = 60524

Versions localsend 1.13.1 (android) 1.13.2 (iphone)

[Crazyokd]

When attempting to send from Windows11 to Samsung S23, i encounter same problem. Then I capture the network package of both sides. and i found the request do not really send to my android. further i found the ip of my android is a static ip address which configured by myself in the past, and this ip address now have been occupied by another equipment. so the request can not send to my android. so i change the android static ip address to another value. Then the problem is solved.

[whatacold]

Restarting the server on the target device helped for me.