| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| faq:tcpip [2020/02/13 23:49] – And finally, diffie-hellman with sha256 deuce | faq:tcpip [2024/11/02 13:48] (current) – [Ports] List the disabled service ports too (for reference) digital man |
|---|
| * [[#ftp_connect|Why can't users connect to my FTP server]]? | * [[#ftp_connect|Why can't users connect to my FTP server]]? |
| * [[#ftp_nat|Why do FTP clients lock-up or time-out when listing directories or downloading files from my FTP server]]? | * [[#ftp_nat|Why do FTP clients lock-up or time-out when listing directories or downloading files from my FTP server]]? |
| | * [[#ftp_html|Why won't a web browser render HTML content from my FTP Server]]? |
| * [[#bind|Why do some or all of my servers get bind errors when starting or recycling]]? | * [[#bind|Why do some or all of my servers get bind errors when starting or recycling]]? |
| * [[#bandwidth|How many nodes/clients/users can I support with my Internet connection]]? | * [[#bandwidth|How many nodes/clients/users can I support with my Internet connection]]? |
| |WS |1123 | |WebSocket Service - to support the [[http://ftelnet.ca|fTelnet web browser-based terminal]] | | |WS |1123 | |WebSocket Service - to support the [[http://ftelnet.ca|fTelnet web browser-based terminal]] | |
| |WSS |11235 | |WebSocket Secure Service - to support the [[http://ftelnet.ca|fTelnet web browser-based terminal]] over TLS | | |WSS |11235 | |WebSocket Secure Service - to support the [[http://ftelnet.ca|fTelnet web browser-based terminal]] over TLS | |
| | |
| | Additionally, a default Synchronet installation includes *disabled* servers and services on the following ports: |
| | |
| | ^Protocol ^TCP ^UDP ^Comments^ |
| | |QOTD |17 |17 |Allows remote querying of BBS's auto-message (e.g. via ''qotdservice.js'')| |
| | |IMAP |143 |- |Allows remote download of user's email (similar to POP3, via ''imapservice.js'')| |
| | |IMAPS |993 |- |Allows secure remote download of user's email (similar to POP3/TLS)| |
| | |BINKP |24554 |- |Allows exchange of FidoNet files (e.g. mail bundles and packets, via ''binkit.js'')| |
| | |BINKPS |24553 |- |Allows secure exchange of FidoNet files| |
| | |NNTPS |563 |- |Allows BBS users to securely read and post messages using standard news readers/clients| |
| | |Hotline |5500 |- |Allows interaction with Hotline client| |
| | |Hotline-TRANS |5501 |- |""| |
| | |
| | |
| |
| Enabling connectivity to Synchronet through your firewall is no different than enabling connectivity to any other TCP/IP server. Follow your firewall documentation for forwarding or opening ports for TCP/IP servers located "behind" the firewall. Your firewall may have the option of placing the entire BBS computer in a "DMZ" (opening all its ports to the public Internet), but doing so is not normally recommended. | Enabling connectivity to Synchronet through your firewall is no different than enabling connectivity to any other TCP/IP server. Follow your firewall documentation for forwarding or opening ports for TCP/IP servers located "behind" the firewall. Your firewall may have the option of placing the entire BBS computer in a "DMZ" (opening all its ports to the public Internet), but doing so is not normally recommended. |
| |
| If your firewall cannot dynamically open/forward FTP PASV data ports for incoming passive FTP data connections, you can specify a limited range of TCP port numbers to use for passive transfers by modifying the PasvPortLow and PasvPortHigh values in the ''[FTP]'' section of your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file. You will of course need to configure your firewall device to open/forward these ports to your FTP server. | If your firewall cannot dynamically open/forward FTP PASV data ports for incoming passive FTP data connections, you can specify a limited range of TCP port numbers to use for passive transfers by modifying the PasvPortLow and PasvPortHigh values in the ''[FTP]'' section of your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file. You will of course need to configure your firewall device to open/forward these ports to your FTP server. |
| | |
| | ===== FTP HTML ===== |
| | :?: **Question:**\\ |
| | Why will a web browser not (no longer) render the HTML content sent by the Synchronet FTP Server (i.e. ''00index.html'' generated by ''ftp-html.js'')? |
| | |
| | :!: **Answer:**\\ |
| | For security reasons, modern web browsers (e.g. Google Chrome) have stopped rendering HTML content served by protocols other than HTTP or HTTPS. |
| | * [[https://www.bleepingcomputer.com/news/google/chrome-and-firefox-developers-aim-to-remove-support-for-ftp/]] |
| | |
| | Some web browsers (e.g. Microsoft Edge) are removing FTP support altogether. |
| | * [[https://www.ghacks.net/2020/03/19/mozilla-will-remove-ftp-support-in-the-firefox-web-browser/]] |
| |
| ===== Bind ===== | ===== Bind ===== |
| |
| This usually means you have another TCP/IP server on your system that is already bound to (and is presumably already listening for incoming connections on) this port. This could be a pre-existing instance of Synchronet or any other Telnet/Web/Mail/FTP servers that you may have installed on your system. You can use utilities such as ''[[man>netstat]]'' (for Windows or Unix((e.g. 'netstat -naptu' as root user on Linux))) or [[http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx|TCPView]] (for Windows) to verify what programs (if any) have the TCP or UDP port in question already bound. If these utilities do not report any program is bound to (and listening) on this port, you can try Telnetting to the port in question and see if anything answers. If you're unable to connect to the port with a Telnet client and Synchronet cannot bind the port, your TCP/IP stack probably needs to be reset, so a system reboot may be in order. | This usually means you have another TCP/IP server on your system that is already bound to (and is presumably already listening for incoming connections on) this port. This could be a pre-existing instance of Synchronet or any other Telnet/Web/Mail/FTP servers that you may have installed on your system. You can use utilities such as ''[[man>netstat]]'' (for Windows or Unix((e.g. 'netstat -naptu' as root user on Linux))) or [[http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx|TCPView]] (for Windows) to verify what programs (if any) have the TCP or UDP port in question already bound. If these utilities do not report any program is bound to (and listening) on this port, you can try Telnetting to the port in question and see if anything answers. If you're unable to connect to the port with a Telnet client and Synchronet cannot bind the port, your TCP/IP stack probably needs to be reset, so a system reboot may be in order. |
| |
| If you're running a Unix-like operating system (not Windows) and get bind errors only when recycling servers, this is most likely because a TCP session is stuck in a ''TCP TIMEWAIT'' state (you can use ''[[man>netstat]]'' to verify this). The session will eventually time-out and close properly on its own, allowing the port to be re-bound at that time. To work-around this problem, you can either increase the ''BindRetryCount'' and/or ''BindRetryDelay'' values in your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file, or you can add the following line to your ''[[dir:ctrl]]/[[config:sockopts.ini]]'' file: | |
| REUSEADDR=1 | |
| |
| :!: **Answer:**\\ | :!: **Answer:**\\ |
| |
| Error ''13'' means "access denied". | Error ''13'' means "access denied". |
| This error upon binding usually means that you're running Synchronet as non-privileged user account (e.g. not 'root') and the operating system you're running does not allow processes run under non-privileged user accounts to bind to low (TCP or UDP) port numbers (usually less than 1024). You can either use higher TCP port numbers in your configuration or have Synchronet switch to a non-privileged user *after* binding the TCP ports (see [[config:nix]] for details). | This error upon binding usually means that you're running Synchronet as non-privileged user account (e.g. not 'root') and the operating system you're running does not allow processes run under non-privileged user accounts to bind to low (TCP or UDP) port numbers (usually less than 1024). You can either use higher TCP port numbers in your configuration or have Synchronet switch to a non-privileged user *after* binding the TCP ports (see [[config:nix]] for details), see also: [[howto:Linux non-root]]. |
| | |
| | ==== Rebind ==== |
| | :!: **Answer:**\\ |
| | If you're running a Unix-like operating system (not Windows) and get bind errors //only// when recycling servers: |
| | sbbs: term 0001 !ERROR 98 binding Telnet Server socket to port 23 |
| | sbbs: term 0001 Will retry in 15 seconds (1 of 2) |
| | |
| | ... this is most likely because a TCP session is stuck in a TCP "TIME WAIT" or "CLOSE WAIT" state (you can use ''[[man>netstat]]'' to verify this). The session will eventually time-out and close properly on its own, allowing the port to be re-bound at that time. To work-around this problem, you can either increase the ''BindRetryCount'' and/or ''BindRetryDelay'' values in your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file, or you can add the following line to the root section of your ''[[dir:ctrl]]/[[config:sockopts.ini]]'' file: |
| | REUSEADDR=1 |
| |
| ===== Bandwidth ===== | ===== Bandwidth ===== |
