Remote-ftp: ECONNRESET

[k3larra]

Hi
Sort of out of the blue I get this error?

Have Been using Remote-FTP for a while and it has always worked, tested a few days ago but from today I get this. I can connect to the same site with command-line-ftp and FileZilla.
(Great product tnx for that)
regards
/L

[dylanholmes222]

Getting the same result on a clients Go Daddy web hosted account. Other hosts like Digital Ocean and Site Ground seem to be working fine for me still on Remote FTP. Filezilla connects to the Go Daddy account.

[k3larra]

My problems are also related to GoDaddy so it seems reasonable to think that there are some change on their side that Remote-FTP doesn't handle.

[Humanitech]

I've the same issue. I can't see my remote folders. I tested the connection with two different provider (Aruba and DNS Hosting) and the main problem isn't the connection, but the directory listing (Error 200).

[alanneese]

I've been receiving the same error for the past couple of days. I've had to switch back to Sublime Text 3 which isn't a big deal, but I prefer Atom. I'm a GoDaddy customer also, but it had been working just fine.

[DanMoCa]

Can confirm that trying to connect to GoDaddy gives ECONNRESET, connecting to Dreamhost or DigitalOcean give no trouble at all.

Atom: 1.12.5
Remote-FTP: 0.9.4
OS: Windows Anniversary Edition

[allendotson]

I'm having this issue using Bluehost. Also noticed that my internet got super sluggish just before the error popped up.

[limonanagituser]

Same issue for me. Evrything works with Filezila and nppFTP Notepad++ plugin but remote FTP doesn' want to list repository

[wolfymaster]

Also having this issue with GoDaddy. I am able to connect w/ Filezilla but not through atom with Remote-FTP. Gives the ECONNRESET error.

[lip2502]

Same here on OVH

[moskalukigor]

The update should be soon?

[jimmaaay]

Is there anything that stands out in the console of the dev tools?

[johnmarlow007]

Hi all.
I have the exact same issue. I can connect to my ftp fine with notepad++ and filezilla, but I get the same error every time I connect with Atom. My server is also with godaddy...
I even deleted all the atom installation folders and reinstalled it, but same behavior.
If it helps, when I get to the Cpanel, I can see the idle ftp connection that atom started.
God help the brilliant minds that are hunting this bug !!!
Best of luck!

[lip2502]

Ok, So What I don't understand is that when looking at the console output everything seems to be fine. Except that no file is showing and I get this ECONNRESET.

If it is of any help here is the output of the console.
Welcome to OVH ~~~\r\n220 This is a private system - No anonymous login C:\Users\Utilisateur\.atom\packages\Remote-FTP\lib\client.js:347 < 331 User a36265ds4 C:\Users\Utilisateur\.atom\packages\Remote-FTP\lib\client.js:347 < 230 OK. Current restricted directory is / C:\Users\Utilisateur\.atom\packages\Remote-FTP\lib\client.js:347 < 211-Extensions supported:\r\n EPRT\r\n IDLE\r\n MDTM\r\n SIZE\r\n MFMT\r\n REST STREAM\r\n MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;\r\n MLSD\r\n AUTH TLS\r\n PBSZ\r\n PROT\r\n UTF8\r\n TVFS\r\n ESTA\r\n PASV\r\n EPSV\r\n SPSV\r\n ESTP\r\n211 End. C:\Users\Utilisateur\.atom\packages\Remote-FTP\lib\client.js:347 < 200 TYPE is now 8-bit binary C:\Users\Utilisateur\.atom\packages\Remote-FTP\lib\client.js:347 < 227 Entering Passive Mode (213,186,33,215,187,67) C:\Users\Utilisateur\.atom\packages\Remote-FTP\lib\client.js:347 < 150 Accepted data connection

Any idea about what's causing the issue ?

Thanks for the help

[shahafan]

I've figured it out!!

fix:
go to .atompackagesRemote-FTPnode_modulesftplibconnection.js
on line 106 change socket.setKeepAlive(true); -> socket.setKeepAlive(false);

You are welcome :)

@jimmaaay

[alupkasix]

Thank you! I made the change and it seems to be working now.

[paul2903]

Awesome @shahafan! I would just add that we need to restart Atom.
I've followed the steps and worked as expected! Thanks again :)

[lip2502]

Waow @shahafan ! I have been trying to find a fix for ages, thank you soooooo much ! You made my day ;-)

[GregoryNatter]

Thanks !

[teeramusic]

socket.setKeepAlive(false); <== maybe add option to set this in the .ftpconfig?

[alupkasix]

Yes, please make this default or add to settings. The last update a couple days ago broke my FTP again by turning this back to TRUE.

What's weird is that this worked for a long time without having to make this change until about the time this thread started. Did it use to be set to false by default? If so, why not just set it back?

[zachdyer]

I'm still getting the error.

[jpxd]

Add socket.setKeepAlive(false); as default or as option for the .ftpconfig?
What do you think?

[hatzopoulos]

@jpxd it needs to be an option.

[hatzopoulos]

For SFTP Configuration Options if keepalive is set to 0 it should be disabled as it is specified in the readme.

For FTP/FTPS it should probably do the same thing; when set to zero it is disabled.

[alupkasix]

Hi Developer, can you please:

1. Fix this to default, or
2. Give us option, or
3. Don't let updates keep reverting it back every time we fix it, or
4. Stop making updates so we don't have to worry about it breaking again

Previously there was no issue with this, so why change it in the first place? This is the only FTP app I have that has this problem. Every time it updates it breaks it again.

Secondly, can you please revert back to allow me to connect "once" for all "open in new window" instances on multiple monitors? This use to work too but now it doesn't. Now I have to connect 3 times to the same FTP server. On 2 monitors it may work, but on the 3rd monitor the change never uploads because of time out. And there is no indication of it unless I keep the the remote folder column open.

So now, I have to waste considerable screen real estate just to keep the same remote files list open in 3 different places...all just to see the tiny text that says upload failed because of time out when it happens.

This is super annoying and I'm sure you can agree that this is poor design. Especially considering this extension use to be AMAZING and none of these hacks were needed before.

Please, I hope you will consider restoring this package to it's former glory. This was the package that originally sold me on Atom and made it worthy of using full time. Workflow was awesome. Now, it's the one package that makes me consider giving up on Atom altogether. I just don't understand the direction you are going here.

[jpxd]

Hey to all,
sorry that this bug existed for so long, but the problem is in the ftp module Remote-FTP uses.

There is even a PR on the ftp package (https://github.com/mscdex/node-ftp/pull/147) but it is not updated currently as it seems. (When the bad support of this ftp module continues we should consider a new one...)

@hatzopoulos is right, when keepalive is set to 0 it should be disabled.

Because the socket.setKeepAlive(true); is hardcoded in the ftp module we cannot really change it without forking the whole package. Can you please try the dev branch? I committed a change that disables the sockets keepalive when it is set to 0 directly after the connection has been established.

git clone https://github.com/mgrenier/remote-ftp.git
cd remote-ftp
git checkout dev
apm install
amp link

[jpxd]

The fix is now in the new update (0.10.5). Please report if the issue persists or if it goes away :)

[alanneese]

I am running 0.10.5 and I still get the following message.

This is very frustrating.

[jpxd]

@alanneese Yes, it is. Did you set keepalive to 0 in the .ftpconfig? (And restarted Atom afterwards)

[alanneese]

Yes.

"keepalive": 0
}

[jpxd]

@alanneese And does the manual socket.setKeepAlive(false); fix from @shahafan help?
(referring to https://github.com/mgrenier/remote-ftp/issues/585#issuecomment-266694435)

[alanneese]

@jpxd That fix didn't help. Sorry.

[ghughes27]

Just updated, the setKeepAlive(false) quick fix that used to work is now broken again. I'm getting through initially but after a few seconds I get the same error as @alanneese

[jpxd]

@ghughes27 What do you mean? Even if you manually edit .atom\packages\Remote-FTP\node_modules\ftp\lib\connection.js it doesn't work now, but did before the update?

The thing changed in the update is to set keepalive according to the .ftpconfig (but sadly only in the ready event because the constructor doesn't have an option for this...)
See https://github.com/mgrenier/remote-ftp/commit/585cc7122557b9bd7d60584c7aadc0bd4503ca90.

[ghughes27]

Yes, in the old version I just used @shahafan quick fix, but with the updated version neither his solution nor the "keepAlive": 0 work (I've tried both on/off/alternate to no avail). It looks like I'm initially getting through when I change .keepSocketAlive(false) but shortly after I see the directories I'm getting thrown off with "Error: read ECONNRESET"

After commenting 585cc71 out it looks like its working again

p.s. thanks for the package

[giacomok]

Same problem here.

I tried everything in this thread but I still get the error.

[moaali]

Same issue, tried every thing above with no result

[mattfwood]

Commenting out the lines @ghughes27 suggested worked for me. ( 585cc71 )

All the other fixes caused the same error.

[giacomok]

Any news? I really want to use atom but right now I can't.

[jonnale]

As others have noted, editing .atom\packages\Remote-FTP\node_modules\ftp\lib\connection.js used to work for me. I just updated to 0.10.5, and I was no longer able to connect via ftp.

I tried setting "keepalive": 0 in the .ftpconfig, and that still did not work.

I commented out the lines that @ghughes27 mentioned, and it now works again. Thanks, @ghughes27!

.atom\packages\Remote-FTP\lib\connectors\ftp.js -> comment out (or delete) line 48.

Line 48 looks like this:
self.ftp._socket.setKeepAlive(self.info.keepalive > 0);

[jpxd]

Okay, I can just remove the line again (which should have fixed the issue in the first place) but this does still NOT resolve the original bug and you'll all depend changing the code in node_modules\ftp\lib\connection.js after every update.

If this issue is not fixed in node-ftp itself, we'll have to fork (wich I don't like, because maintaining a fork is extra work...)

@mscdex Can you please look into https://github.com/mscdex/node-ftp/pull/147 ?
This would help us a lot!

[jpxd]

@alanneese did 585cc7122557b9bd7d60584c7aadc0bd4503ca90 help you in the long run?

[alanneese]

Yes. It solved my problem.

http://www.lockerroomtech.com

On Wed, Feb 22, 2017 at 3:48 AM, Jan [e-mail] wrote:

@alanneese https://github.com/alanneese did 585cc71
https://github.com/mgrenier/remote-ftp/commit/585cc7122557b9bd7d60584c7aadc0bd4503ca90
help you in the long run?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mgrenier/remote-ftp/issues/585#issuecomment-281620452,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABcTR7e-rjayA1yryMV8BgKt_ADANy0uks5rfASCgaJpZM4K4s0d
.

[jonnale]

One thing I noticed: if I update my .ftpconfig and set "keepalive": 0, it doesn't look like that change is coming through in .atom\packages\Remote-FTP\lib\connectors\ftp.js.

I confirmed this by editing .atom\packages\Remote-FTP\lib\connectors\ftp.js. I added a console.log to see the value coming through.

48: console.log(self.info.keepalive);
49: self.ftp._socket.setKeepAlive(self.info.keepalive > 0);

When I set "keepalive":0 in my .ftpconfig, that console.log always prints 10000. If I set keepalive to any value other than 0, that value comes through.

So just to recap:
"keepalive":0 -> console.log prints 10000 -> I still get the ECONNRESET
"keepalive":-1 -> console.log prints -1 -> remote-ftp works

[jpxd]

@jonnale Thanks for pointing that out!!!! I totally missed to check that (because I have no server where the ECONNRESET is triggered to test the fix) and just assumed it should work.

Problem is here: https://github.com/mgrenier/remote-ftp/blob/master/lib/client.js#L293

[jpxd]

Okay, @jonnale @GiacomoK @GreatBearShark @ghughes27
Please try the latest version ([email protected]) which hopefully works as wanted with "keepalive": 0

keepalive behavior is now:

• if not set, keepalive defaults to 10000
• if set > 0, the value is used
• if set = 0, keepalive is disabled

@alanneese You should probably change keepalive to 10000 again after the update because in old versions a keepalive set to zero meant a keepalive of 10000

[jonnale]

@jpxd: I just updated to 0.10.7, set "keepalive":0, and it is working! Thanks for the quick fix!

[ghughes27]

Well done @jonnale @jpxd

[slogopogo]

Hello,

I am having the same issue with connecting. I tried all the recommended changes and to no avail. May I ask for some help?

[alupkasix]

Same here. I appreciate the dev's effort on this but I guess the dependencies just aren't reliable enough. I previously turned off updates so that it would stop breaking. But then updated yesterday because it was reportedly resolved, and now it doesn't work again, Sometimes it does, but it's too much trouble and all of the posted solutions fail at some point.

I solved the problem by switching to remote-sync and everything works like a charm with Go Daddy SSH. Go Daddy seems to come up a lot regarding this issue; maybe they don't like the fake keep alive requests or something.

[ghughes27]

@alupkasix I also use GoDaddy, the new update did break a few things but I went back and edited the connection.js file and it worked again. As long as reconfiguration is possible I'm happy but when I get some time I'll actually see if I'll look further into it.

@slogopogo what does your config look like, also what file modifications have you made?

[slogopogo]

@ghughes27 I'm using GoDaddy as well.

{
"protocol": "ftp",
"host": "*", // string - The hostname or IP address of the FTP server. Default: 'localhost'
"port": 21, // integer - The port of the FTP server. Default: 21
"user": "*", // string - Username for authentication. Default: 'anonymous'
"pass": "*", // string - Password for authentication. Default: 'anonymous@'
"promptForPass": false, // boolean - Set to true for enable password dialog. This will prevent from using cleartext password in this config. Default: false
"remote": "/",
"secure": false, // mixed - Set to true for both control and data connection encryption, 'control' for control connection encryption only, or 'implicit' for implicitly encrypted control connection (this mode is deprecated in modern times, but usually uses port 990) Default: false
"secureOptions": null, // object - Additional options to be passed to tls.connect(). Default: (null) see http://nodejs.org/api/tls.html#tls_tls_connect_options_callback
"connTimeout": 10000, // integer - How long (in milliseconds) to wait for the control connection to be established. Default: 10000
"pasvTimeout": 10000, // integer - How long (in milliseconds) to wait for a PASV data connection to be established. Default: 10000
"keepalive": 0, // integer - How often (in milliseconds) to send a 'dummy' (NOOP) command to keep the connection alive. Default: 10000
"watch":[ // array - Paths to files, directories, or glob patterns that are watched and when edited outside of the atom editor are uploaded. Default : []
"./dist/stylesheets/main.css", // reference from the root of the project.
"./dist/stylesheets/",
"./dist/stylesheets/.css"
],
"watchTimeout":500 // integer - The duration ( in milliseconds ) from when the file was last changed for the upload to begin.
}

I tried "keep alive : 0"
I tried different tweaks in the client.js and ftp/sftp.js files in the library. Nothing seems to work.

[alupkasix]

@ghughes27

Thanks for trying to resolve it. I wish I still had my configs in case it helps someone, but I completely uninstalled it.

I tried all of the things mentioned here, and at one time they all worked. But this issue linked to another problem I have with it.

When hiding the remote tree, the connection disconnects/times out without telling me, which always makes me wonder why my code changes don't work until I realize it's my FTP client timing out again. Coming from dreamweaver code-view, I never had to worry about constantly checking FTP connection; once connected, it just always works. Adjusting the timeout settings are too risky, so I finally had to leave the whole remote tree open (in three different monitors) just to see if the tiny connection status was still active. Then I had to disconnect/reconnect each window. Obviously this is a huge waste of screen real estate just to keep an eye on a tiny status in multiple windows. Every time I changed any Remote-FTP settings it would break, so I left it alone and turned off updates, and tried to live with 3 open tree views that I never use (collapsed but still wasting a whole pane).

When I saw that the issue was resolved and closed, I was excited and decided to update to the latest version in hopes of getting all the latest fixes and be able to turn updates back on and hopefully not having to keep all the remote tree panes open. So I completely uninstalled and removed configs to get a fresh start. Of course, the first thing I see is this error again.

So then I went through the fixes again: setting connection config to false, keep alive 0, keep alive -1, etc. in settings. The only thing that worked was to have keep-alive positive.

I did finally get it working on the latest release with plain text FTP, but it would only work sometimes. For example, I could open 3 windows of Atom...2 would work and 1 would throw the error. Even if the connection was reliable, it didn't solved my needing to keep the tree permanently open just to see if it timed out, and it didn't let me turn updates back on for fear of going through all of this again...which is like the 5th time I've done it.

[cbejensen]

I was getting this same error but was able to solve it by leaving line 106 of connection.js as socket.setKeepAlive(true); and setting keepAlive to 0. This was for an ftp connection. Using v0.10.7