Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The listen() call never rejects and always listens on 0.0.0.0 #84

Closed
TimLuq opened this issue May 15, 2018 · 4 comments
Closed

The listen() call never rejects and always listens on 0.0.0.0 #84

TimLuq opened this issue May 15, 2018 · 4 comments
Assignees
Labels
bug A defect or bug that affects the original indended use of the application

Comments

@TimLuq
Copy link
Contributor

TimLuq commented May 15, 2018

listen() never rejects

The callback to (net | tls).server.listen will not receive an error argument, but is instead attached as a callback to the "listening" event. When there is a binding error listening will never be dispatched and the promise is dead and will never reject nor resolve.

See https://nodejs.org/api/net.html#net_server_listen

listen() always listens to 0.0.0.0

No host is passed on to the net.server.listen(), as such the default 0.0.0.0 is always bound.

TimLuq added a commit to TimLuq/ftp-srv that referenced this issue May 15, 2018
@trs trs added the bug A defect or bug that affects the original indended use of the application label May 15, 2018
@trs trs assigned TimLuq and trs May 15, 2018
trs pushed a commit that referenced this issue May 15, 2018
trs pushed a commit that referenced this issue May 16, 2018
trs pushed a commit that referenced this issue May 18, 2018
@trs
Copy link
Contributor

trs commented May 18, 2018

#86

@trs trs closed this as completed May 18, 2018
@sbstnbr
Copy link

sbstnbr commented May 25, 2018

Hi @trs @TimLuq,

This fix breaks my use case where my FTP is deployed behind a TCP Router which reroutes client connection to it (like a load balancer).

In my case, the hostname I provide while starting the server is the public IP of the TCP Router, which is sent back to the client when he wants to push files.
But my FTP server now fails at startup because it tries to listen to this same IP (which is normal) instead of 0.0.0.0.

{"message":"listen EADDRNOTAVAIL ",
"name":"Error","stack":"Error: listen EADDRNOTAVAIL :\n at Object._errnoException
(util.js:1022:11)\n at _exceptionWithHostPort (util.js:1044:20)\n at Server.setupListenHandle [as _listen2]
(net.js:1334:19)\n at listenInCluster (net.js:1392:12)\n at doListen (net.js:1501:7)\n at _combinedTickCallback
(internal/process/next_tick.js:141:11)\n at process._tickCallback (internal/process/next_tick.js:180:9)",
"code":"EADDRNOTAVAIL"},"msg":"[Event] error","time":"2018-05-22T10:14:39.374Z","v":0}

Would it be posible to configure 2 kind of hostnames ?

  • the listening hostname
  • the hostname to which the client should send files

@trs
Copy link
Contributor

trs commented May 25, 2018

@sbstnbr Thank you for your report, I was worried there would be broken builds. I apologize for it.

I think I have a solution:

  • The server and any passive connections will listen on the provided hostname in url. Even if this is 0.0.0.0.
  • The hostname which to send to the client (via the PASV command) will be the url hostname or an optional pasv_url value. If this value is 0.0.0.0, it will then resolve to the external IP.

What do you think?

@sbstnbr
Copy link

sbstnbr commented May 25, 2018

Works for me ! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A defect or bug that affects the original indended use of the application
Projects
None yet
Development

No branches or pull requests

3 participants