====== TCP/IP Servers and Services ======

Answers to Frequently Asked Questions regarding Synchronet and TCP/IP (the Internet protocol suite).

  * [[#ports|What inbound ports do I need to open in my firewall]]?
  * [[#private_ip|How come my friends can't connect to my BBS at my IP address]]?
  * [[#public_ip|What is my public IP address]]? 
  * [[#relay_mail|Why can't I relay Internet e-mail through my BBS]]? 
  * [[#send_mail|Why can't I send Internet e-mail from my BBS]]? 
  * [[#receive_mail|Why can't my BBS receive Internet e-mail or inter-BBS instant messages]]? 
  * [[#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_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]]? 
  * [[#bandwidth|How many nodes/clients/users can I support with my Internet connection]]? 
  * [[#block_hackers|Can Synchronet automatically block the IP address of hackers]]?
  * [[#ssh_algo|Why do some SSH clients fail to connect to my BBS]]?
  * [[#ssh_session_key|How do resolve the SSH error: importing session key to protect private key]]?

===== Ports =====

:?: **Question:**\\
What inbound ports do I need to open in my firewall?

:!: **Answer:**\\
Depends on which Synchronet servers and services you wish to make available to Internet clients and which ports you have configured those servers and services to listen on.

The default Synchronet installation enables servers and services on the following ports:

^Protocol	^TCP	^UDP	^Comments^
|Telnet	        |23	|-	|For Telnet logins (highly recommended)|
|SSH	        |22	|-	|For SecureShell logins (recommended)|
|RLogin	        |513	|-	|Optional for quick-login from RLogin clients (e.g. SyncTERM)|
|SMTP	        |25	|-	|Necessary for receiving Internet e-mail |
|Submission     |587	|-	|Necessary for users to send Internet e-mail through the BBS from a standard e-mail client|
|Submission/TLS |465	|-	|Necessary for users to send Internet e-mail through the BBS from a standard e-mail client using TLS((encrypted communications over TCP))|
|POP3	        |110	|-	|Allows BBS users to check their e-mail using standard Internet mail clients (e.g. Outlook Express)|
|POP3/TLS       |995	|-	|Allows BBS users to check their e-mail using standard Internet mail clients (e.g. Outlook Express) using TLS|
|FTP	        |21	|-	|Allows access to the BBS file/download areas using a standard FTP client or web browser|
|HTTP	        |80	|-	|Required for access to the BBS's web server|
|HTTPS	        |443	|-	|Required for secure access to the BBS's web server using TLS|
|NNTP	        |119	|-	|Allows BBS users to read and post messages using standard news readers/clients|
|Gopher	        |70	|-	|Archaic protocol allows reading of messages and other BBS info|
|IRC	        |6667	|-	|Allows Internet Relay Chat (IRC) clients to connect to your BBS|
|Finger	        |79	|	|Allows remote querying of BBS user info, who's online, and other BBS info|
|SYSTAT	        |11	|11	|Allows remote querying of who's online (aka Active Users) required for [[module:sbbsimsg|inter-BBS instant messaging]]|
|MSP	        |18	| 	|Allows incoming [[module:sbbsimsg|inter-BBS instant messages]]|
|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 |

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. 

[[http://vert.synchro.net/scanmyports.ssjs|This page]] or [[http://cvs.synchro.net/scanmyports.ssjs|this one]] can be used to scan your host (your BBS computer) for open ports and active TCP/IP (including UDP) services. **The password is //sbbs//**.

Additionally, an advanced Synchronet installation may make //outbound// requests to the following ports:

^Protocol	^TCP	^Comments^
|MQTT           |1883   |[[howto:MQTT|Message Queue Telemetry Transport]] |
|MQTT/TLS       |8883   |Secure MQTT |
|MQTT/WS        |1884   |MQTT over WebSockets |
|MQTT/WS/TLS    |8884   |MQTT over WebSocketsSecure (aka WSS) |

===== Private IP =====

:?: **Question:**\\
How come my friends can't connect to my BBS at my 192.168.x.x, 172.[16-31].x.x, or 10.x.x.x IP address?

:!: **Answer:**\\
The IP address ranges listed above are reserved for use in private networks and are not publicly addressable from the Internet. See [[rfc>1918|this document]] for technical details.

You do not want to advertise this IP address to the public since it is useless to anyone outside of your own private/local area network (LAN). IP addresses in these ranges are typically assigned to your computer by your router/firewall device (using DHCP) to allow multiple computers on your private network to share the same public IP address using a mechanism known as Network Address Translation ([[rfc>1631|NAT]]). Clients on the Internet must use the IP address of your router/firewall device's public/WAN port to connect to your BBS. This IP address will not begin with 192.168., 172.[16-31]., or 10. 

===== Public IP =====
:?: **Question:**\\
What is my public IP address? 

:!: **Answer:**\\
If you need to know your public IP address, you can usually query your router/firewall device using it's configuration interface (typically via Telnet or HTTP to its private/LAN port) or access [[http://whatismyipaddress.com/|any]] [[http://checkip.dyndns.org/|one]] of [[http://www.whatismyip.com/|many]] public web-sites that can tell you what your public IP address is. However, it is usually much better to advertise a //hostname// (e.g. ''vert.synchro.net'') rather than a cryptic hard-to-remember IP address (e.g. ''64.148.159.105''). 

If you use a [[module:dyndns|Dynamic-DNS]] service to get a hostname for your BBS, the service can usually correctly determine your public IP address automatically, even if your IP address changes (e.g. via DHCP). So **you** don't need to necessarily know what it is. 

Another way that will accurately scan and diagnose your IP connectivity is [[http://ipv6-test.com|the IPv6 test]] site.  It will identify both your [[IPv4|IPv4]] and your [[IPv6|IPv6]] for future connectivity.  This scan will show you your accurate IPv4 and is a great aid to know just how connectable your system is.


===== Relay Mail =====
:?: **Question:**\\
Why can't I relay Internet e-mail through my BBS? 

:!: **Answer:**\\
Indications of this problem include error messages in your e-mail client similar to the following: 
  553 Relaying through this server requires authentication. Please authenticate before sending. 
  550 Relay not allowed. 

Or error messages similar to the following in your Synchronet Mail Server window/log output: 

  0504 !SMTP ILLEGAL RELAY ATTEMPT from <yourname@yourhost.org> [192.168.0.2] to someuser@somehost.com 
  
Where the from address is that of your mail sending host and the to address is that of an external mail recipient that you are attempting to send e-mail to. 

It is common and normal to see "illegal relay attempts" from remote systems that have happened on your mail server and are probing it to determine if it is an "Open Relay". So called "Open Relays" (mail servers that allow any and every host to relay mail through them) are a major source of SPAM on the Internet and are highly discouraged. 

By default, the Synchronet Mail Server disallows the relaying of SMTP e-mail messages received for an external recipient (not destined for a local BBS user account). 

You can allow specific hosts or users to relay e-mail through your mail server by either: 
Entering the sending host's IP address or hostname in your ''[[dir:ctrl]]/[[config:relay.cfg]]'' file. 
This file may be edited with the SBBSCTRL:Mail->Edit->Allowed Relay List menu option. 

or: 

Use SMTP authentication: 
Enable the mail server configuration option to allow authenticated users to relay mail. 
This can be done by adding ''ALLOW_RELAY'' to the ''Options'' key of the ''[mail]'' section of your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file. 
Or, if using SBBSCTRL, checking the "Allow Authenticated Users to Relay Mail" checkbox on the SMTP tab of the Mail Server Configuration dialog. 

Configure your e-mail client to use SMTP authentication to login to your mail server using your BBS user name (i.e. alias) and password. 

The Synchronet Mail Server supports the following SMTP authentication schemes: 
  * PLAIN 
  * LOGIN 
  * CRAM-MD5 
(Note: password case sensitivity can be an issue when using CRAM-MD5 authentication) 

===== Send Mail =====
:?: **Question:**\\
Why can't I send Internet e-mail from my BBS? 

:!: **Answer:**\\
You must have the Synchronet SendMail thread enabled in your Synchronet Mail Server configuration. 
If you do not see the following message in your Synchronet Mail Server window/log output when the server is started or recycled:
  0000 SendMail thread started 

then you do not have the SendMail thread enabled and your system cannot deliver any Internet e-mail messages until it is enabled and recycled (delivery of any previously queued outbound messages will be attempted at that time). 

If your Synchronet SendMail thread cannot deliver e-mail messages, it could be for any of the following reasons: 
You have your mail server configured for "Direct Delivery", but have an improperly configured DNS server IP address. 
Example errors indicating this condition include: 
  0000 !SEND INVALID DNS server address 
  0000 !SEND ERROR -1 obtaining MX records for someserver.com from 192.168.1.1 

The configured DNS server IP address should usually be set to that of your ISP's primary DNS server. 

Note: Synchronet v3.13b can automatically detect and use your DNS server's correct IP address during run-time. This feature is enabled by configuring the DNS server IP address in the mail server configuration to blank or <auto>. 
You'll know this feature is active when you see log lines similar to the following: 
  0000 SEND using auto-detected DNS server address: 206.13.29.12 

Your firewall, Internet Service Provider, or Anti-Virus software is blocking, intercepting, or filtering outbound connections to TCP port 25 (many consumer-class ISPs do this). 
Example errors indicating this condition include: 
  0700 !SEND ERROR 60 connecting to SMTP server: smtp.somedomain.com 
  0023 !SEND ERROR 110 connecting to SMTP server: mx.somesite.org 

You can verify if this is the case by attempting to Telnet to a known public SMTP server (e.g. vert.synchro.net) on TCP port 25. 
You should see a mail server version banner similar to the following: 
  220 bbs.synchro.net Synchronet SMTP Server 1.362-Win32 Ready 

If you cannot connect or do not see a mail server version banner, then something is filtering or blocking your outbound connections to TCP port 25. 

If your ISP is blocking port 25, they will normally make an exception for their own mail servers (e.g. ''mail.yourisp.com'' or ''smtp.yourisp.com''). If this is the case (and your ISP's mail server allows the from address of your e-mail message to contain any hostname or IP address of your choosing), then you need to configure your mail server to use your ISP's mail server as its relay server. Do not use your own mail server's hostname or IP address as the relay server (this will cause an undesireable message "loop"). 

If your ISP's mail server only allows e-mail to be sent from ''somename@yourisp.com'' then you need to contact your ISP about how you can send e-mail from a different domain using their mail server. Perhaps they only allow this feature when using SMTP authentication? 

One possible solution if **outbound** TCP port 25 is blocked by your ISP is to use an SMTP relay server which accepts connections on another TCP port (say, 587) and will then relay your mail to the destination mail server on port 25. If you wish, you can [[howto:relay_smtp|relay the outbound mail from your BBS through Vertrauen]] using your QWKnet account for authentication (this service is for Synchronet sysops only, provides no guarantee of privacy, and may be terminated at any time for any reason).

You have your mail server configured to use an external "Relay Server", but have an improperly configured relay server hostname or IP address. 
Example errors indicating this condition include: 
  0000 !ERROR resolving hostname: badhostname.com 
  0680 !SEND ERROR 60 connecting to SMTP server: 192.168.1.1 

You have your mail server configured to use an external "Relay Server", but the specified relay server requires SMTP authentication in order to allow relaying of mail. 
Example errors indicating this condition include: 
  0000 !Delivery attempt #1 FAILED (somehost.org replied with: "550 Relay not allowed." instead of the expected reply: "250 ...") 
  0000 !Delivery attempt #1 FAILED (somehost.org replied with: "553 Authentication required." instead of the expected reply: "250 ...") 

Synchronet v3.12+ supports the Plain, Login, and CRAM-MD5 methods of SMTP authentication when relaying mail through an external relay server. To enable SMTP authentication when relaying, add one of the ''RELAY_AUTH'' flags to the ''Options'' value in the ''[Mail]'' section of your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file. Or, if running SBBSCTRL-Win32, enable one of the authentication radio buttons on the "Relay" tab of the Mail Server Configuration dialog. 

You have a message in your outbound e-mail queue that is flagged as 'in transit'. If you're running only one instance of the Synchronet Mail Server, this is not a normal condition and the affected message will not be sent until the 'in transit' flag is cleared. 
Example log message indicating this condition: 
  0000 SEND Message #999 from Some User to someone@somesite.com - in transit 

This condition can occur if the Synchronet SendMail thread is terminated unexpectedly while in the process of attempting the delivery an outbound e-mail message. The 'in transit' flag is used to protect multiple instances of the SendMail thread from attempting to deliver the same e-mail message simultaneously. 

If you only have one instance of the Synchronet SendMail thread active (the usual scenario), you can eliminate this problem by adding ''SEND_INTRANSIT'' to the ''Options'' value in the ''[Mail]'' section of your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file. Or you can remove the 'in transit' flags from all existing e-mail messages by running the fixsmb utility on your data/mail database or by running the exec/notransit.js script. 
In general, you need to check your Synchronet Mail Server window/log output for details about why Internet e-mail delivery attempts may be failing. 

==== GMail ====
:?: **Question:**\\
Why can't I send Internet e-mail from my BBS to GMail.com?

Example:
  cvs.synchro.net reporting delivery failure of message
  from Someone to annyone@gmail.com
  
  Reason:
  gmail-smtp-in.l.google.com replied with:
  "550 5.7.26  https://support.google.com/mail/answer/81126#authentication
  d9443c01a7336-21a919d2ef1si90834815ad.334 - gsmtp"
  instead of the expected reply:
  "250 ..."        

:!: **Answer:**\\
GMail.com requires mail severs have a valid **SPF** DNS record to send email to their servers. This requirement from Google is an anti-spoofing/SPAM measurement and nothing to do specifically with the Synchronet Mail Server. [[https://support.google.com/a/answer/33786?sjid=18257063204175362891-NC|Here are helpful instructions from Google on how to set up an SPF record your domain]].

An SPF record is a specially formatted DNS **TXT** (text) record. You can check if your domain has an SPF record by querying the DNS for TXT records for your domain using common network tools provided with your OS such as ''host'', ''dig'', and ''nslookup''.

  $ host -t txt vert.synchro.net
  vert.synchro.net descriptive text "v=spf1 mx a -all"

If you are [[howto:relay_smtp|relaying your outbound Internet mail through Vertrauen]], then it is Vertrauen's mail servers that you need to reference in your domain's SPF record (not your own):
  mail.synchro.net

If you are relaying your outbound Internet mail through Vertrauen **and** [[howto:vert_mx|using Vertrauen as your inbound Internet Mail Exchange (MX)]], then setting your domain's SPF record to just the following will suffice:
  v=spf1 mx a -all
  
If you are using the Synchronet dynamic DNS service to have/update a ''//yourbbs//.synchro.net'' hostname, then see [[module:dyndns#SPF]] for details on how to create the appropriate SPF record.
===== Receive Mail =====

:?: **Question:**\\
Why can't my BBS receive Internet e-mail? 

:!: **Answer:**\\
You must have the Synchronet SMTP (mail) server running and listening for incoming connections on TCP port 25 (the standard SMTP port). You (or a friend) can test this basic connectivity by attempting to Telnet to port 25 (instead of port 23) at your BBS's hostname or [[#public IP]] address from a remote location on the Internet. The remote Telnet client should see a successful connection and a text message similar to the following:
  220 bbs.synchro.net Synchronet SMTP Server 1.362-Win32 Ready 

You should also see evidence of the successful SMTP connection to the server in your Synchronet Mail Server window/log output. If you do not, then it's likely that your firewall or Internet Service Provider is blocking incoming connections to TCP port 25. Before concluding this is the case, verify that the remote Telnet client can connect to other SMTP servers first (e.g. ''vert.synchro.net'', TCP port 25). If it cannot, then this remote client probably has restrictions on which (if any) connections he can make to TCP port 25. Try using a different, less restricted, remote Internet connection for your test. 

If your firewall or Internet Service Provider is blocking incoming connections to TCP port 25 (many consumer-class ISPs do), then you won't be able to receive Internet e-mail on your BBS. Fixing your firewall configuration is rather simple, but changing ISPs is often not. One possible work-around is having a mail proxy (3rd party server) receive the e-mail for you and forward it to a non-standard, non-filtered/blocked SMTP port. Many Dynamic DNS services offer this Mail Exchange (MX) service [[http://www.dyndns.com/services/mailhop/relay.html|for a fee]]. [[howto:vert_mx|Or a fellow sysop may be able and willing to perform this service for you as a favor]]. 

===== FTP Connect =====

:?: **Question:**\\
Why can't users connect to my FTP server? 

:!: **Answer:**\\
You must have the Synchronet FTP server running and listening for incoming connections on TCP port 21 (the standard FTP port). See the previous answer about methods of testing this basic connectivity using a remote Telnet client. 

If your FTP server window/log indicates an accepted FTP connection, then it's not a connectivity problem and probably a login failure. 

FTP sessions require a login. If you have not created a [[:access:#Guest]] account for your BBS, then the FTP server will not allow Annonymous logins (most web browsers, for example, will attempt to login anonymously by default). If this is the problem, then either [[:access:#guest_account_creation|create a Guest account]] or tell your FTP users that they must login with a valid BBS user account in order to use the FTP server. 

===== FTP NAT =====
:?: **Question:**\\
Why do FTP clients lock-up or time-out when listing directories or downloading files from my FTP server? 

:!: **Answer:**\\
Your BBS computer is probably behind a Network Address Translator ([[rfc>1631|NAT]]). NAT functionality is typically built into router/firewall devices. If your NAT device supports active and passive FTP servers "behind" the NAT, then you should have no problems. Unfortunately, this is not always the case: some cheaper consumer-level firewalls do not handle FTP server connections correctly or they do not support FTP servers listening on non-standard ports. Sometimes passive (PASV) transfers work fine, but active (PORT) transfers do not, or vice versa. 

[[http://www.ncftpd.com/ncftpd/doc/misc/ftp_and_firewalls.html|This document]] contains the technical details about how and why and the recommended solutions. 

**Note**: Most web browsers use //passive// FTP transfer mode by default, though this may be configurable. 

**Note**: Some FTP clients (e.g. the Windows command-line FTP client, ''ftp.exe'') //only// support //active// mode transfers. 

Enabling the logging of FTP data channel activity can help diagnose these kinds of problems. This can be done by adding the ''DEBUG_DATA'' option to the ''Options'' value in the ''[FTP]'' section of your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file or by checking the //Data Channel Activity// checkbox in the //Log// tab of the FTP Server Configuration dialog in the Synchronet Control Panel for Windows. 

If you're having problems with passive (PASV) transfers through your NAT/firewall device and you're running Synchronet v3.13a (FTP Server Revision 1.296) or later: 
If the remote client is attempting to connect to your [[#private IP]] address (your NAT device isn't translating the PASV response from the FTP server) and you have a static [[#public IP]] address, you can work-around this limitation of your NAT device by using the ''PasvIpAddress'' value in the ''[FTP]'' section of your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file to specify your IPv4 [[#public IP]] address. 

This problem can be identified (on the client) by finding a comma-separated [[#private IP]] address in the PASV response received from the FTP server (in response to a directory or file transfer request from the client). 

Example:

  # ftp yourbbs.synchro.net
  Connected to yourbbs.synchro.net (70.19.142.182).
  220 Please enter your user name.
  Name (yourbbs.synchro.net:root): anonymous
  331 User name okay, give your full e-mail address as password.
  Password:
  230 Guest logged in.
  ftp> passive
  Passive mode on.
  ftp> dir
  227 Entering Passive Mode (192,168,56,2,4,0) <--- IP address reported as 192.168.56.2 instead of 70.19.41.182

Use an FTP client that supports passive mode and can display all the responses received-from the FTP server to help identify this particular problem. The FTP client must be running on a system outside your private network, so you may need a friend to assist you with this. 

If you have a dynamically-assigned IP address (via DHCP), then your IP address may change at some point, so setting the ''PasvIpAddress'' to a specific IP address may not be a long term solution for your FTP Server. In Synchronet v3.14a and later, you can enable the new //Lookup Passive IP// feature by checking the //Lookup// checkbox on the //Passive// tab of the FTP Server Configuration Dialog in [[monitor:SBBSCTRL]]-Win32, or by adding ''LOOKUP_PASV_IP'' to the Options value in the ''[FTP]'' section of your ''[[dir:ctrl]]/[[config:sbbs.ini]]'' file. This option instructs the Synchronet FTP Server to perform a DNS hostname lookup on your BBS's public hostname and use the resulting IP address (which should be your BBS's [[#public IP]] address) in passive responses. 

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 =====
:?: **Question:**\\
Why do some or all of my servers get bind errors when starting or recycling? 

:!: **Answer:**\\
If you're getting bind errors when first starting up one or more Synchronet servers, similar to the following: 
  0420 !ERROR 48 binding FTP Server socket to port 21 

**Note:**\\
On Unix-like systems, the error number may be different, e.g. ''ERROR 98'' (EADDRINUSE) on Linux.

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. 

:!: **Answer:**\\
If you're getting bind errors when first starting up one or more Synchronet servers, similar to the following: 
  0003 !ERROR 13 binding Web Server socket to port 80

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), 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 =====
:?: **Question:**\\
How many nodes/clients/users can I support with my Internet connection? 

:!: **Answer:**\\
Depends on what those clients will be doing while connected. Here are some facts to consider: 

1. A BBS node doesn't consume any bandwidth when not in use. 

2. An active TCP session doesn't consume any appreciable bandwidth when idle. 

3. Most Internet connections are asymmetrical in nature (as in ADSL). 

This means your upstream channel usually has less bandwidth than your downstream channel. 
When TCP/IP clients (users of your BBS's servers) download content from your servers (this includes viewing menus, reading messages, and playing door games on your BBS), they are primarily using your upstream channel. 

So if you have a 1.5Mbps/128Kbps DSL connection, your downstream is 1.5Mbps while your upstream is only 128Kbps. If you have a "56K" dial-up connection, for example, your downstream is probably in the 43-53Kbps range while your upstream bandwidth cannot be any more than 33.6Kbps (or 48Kbps for V.92 modems). 

If you are lucky enough to have an SDSL or other type of symmetrical Internet connection, then both your upstream and downstream channels are of the same bandwidth. 

4. Most BBS traffic is bursty. 

With the exception of large file transfers, most BBS traffic is sent and received in small bursts. For example, the BBS user's TCP session is idle while the user is viewing menus, reading messages, pausing between keystrokes, etc. Many clients sending and receiving data in small intermittent bursts can be active simultaneously without any perceptible impact on one another. 

5. Not all clients will be capable of saturating your upstream channel. 

If you have a 256Kbps upstream channel, for example, you could support four or five simultaneous "56K" clients all downloading files, and all getting 100% utilization of their respective downstream channels.

===== Block Hackers =====
:?: **Question:**\\
Can Synchronet automatically block the IP address of hackers/attack-scripts? 

:!: **Answer:**\\
Yes, see [[howto:Block-Hackers]] for detailed instructions.

===== SSH Algo =====
:?: **Question:**\\
Why do some SSH clients (e.g. [[http://www.openssh.com/|OpenSSH]]) fail to connect to the Synchronet SSH Server?

:!: **Answer:**\\
SSH supports a variety of cryptographic algorithms for encryption (privacy), integrity (mac) and authentication (key-exchange). As stronger algorithms are introduced, older (less-strong) algorithms are deprecated. As a result, when using a newer version of any SSH client (especially OpenSSH), it may fail to connect to SSH servers which only support less-than-the-strongest (newest) algorithms. There is no permanent solution to this issue as cryptographic algorithms are constantly improving (becoming stronger) and older (weaker) algorithms are going out of favor.


==== SSH Cipher Algo ====

Should be fixed as of Fri Feb 14 07:37:04 2020 UTC. aes128-ctr and aes256-ctr support was added.

Example:
  $ ssh vert.synchro.net
  Unable to negotiate with vert.synchro.net port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc
  
Workarounds for OpenSSH:

  $ ssh -c aes128-cbc user@yourbbs.com
  
or in the ''~/.ssh/config'' file (OpenSSH v6):

  Host yourbbs.com
  Ciphers aes128-cbc
  
==== SSH Kex Algo ====

Should be fixed as of Mon Jun 3 22:21:15 2019 UTC. diffie-hellman-group-exchange-sha256 and diffie-hellman-group14-sha256 support was added.

Example:
  $ ssh vert.synchro.net
  Received disconnect from 71.95.196.34: 2: Handshake failed
  
or:
  Unable to negotiate with legacyhost: no matching key exchange method found.
  Their offer: diffie-hellman-group1-sha1

From the OpenSSH [[http://www.openssh.com/legacy.html|legacy page]]:
> OpenSSH implements all of the cryptographic algorithms needed for compatibility with standards-compliant SSH implementations, but since some of the older algorithms have been found to be weak, not all of them are enabled by default.

Workarounds for OpenSSH:

  $ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@yourbbs.com

or in the ''~/.ssh/config'' file (OpenSSH v6):

  Host yourbbs.com
  KexAlgorithms diffie-hellman-group1-sha1
  
**Note:**
If you created this file to work-around the cryptlib v3.4.2 compatibility issue, you will need to remove this file or modify it after updating to cryptlib v3.4.4  (currently, the latest).

or in the ''~/.ssh/config'' file (OpenSSH v7):

  Host yourbbs.com
  KexAlgorithms +diffie-hellman-group1-sha1

Note: Run ''ssh -V'' to see what version of OpenSSH you have.

==== SSH MAC Algo ====

Should be fixed as of Mon Jun 3 22:21:15 2019 UTC. hmac-sha2-256 support was added.

Another observed problem is with the negotiated Message Authentication Code (MAC) algorithm.

Workaround for OpenSSH (reported by nelgin):

  $ ssh -m hmac-md5 user@yourbbs.com

===== SSH Session Key =====
:?: **Question:**\\
How do I resolve the following terminal server SSH error?

  'Couldn't import the session key used to protect the private key' (-22) getting private key

:!: **Answer:**\\
Rename/move or delete your ''[[config:cryptlib.key]]'' file.

If you're using TLS for your other [[server:|Synchronet servers (e.g. web, mail, ftp, etc.)]], you may also need to rename/move or delete your ''[[config:ssl.cert]]'' file.

===== SSH Errors =====
:?: **Question:**\\
Should I be concerned about ssh errors in my log files?

:!: **Answer**\\
A number of ssh errors are generated mainly due to clients disconnecting or not actually using a valid ssh client, such as port scanners or bots. Some of these errors are

  'Internal consistency check failed' (-16) setting session active
  
  'ENOTCONN: Socket is not connected' (-42) setting session active
  
  'Error reading client's SSH identifier string: ETIMEDOUT: Function timed out before completion' (-41) setting session active
  
  No data was read because the remote system closed the connection (recv() == 0)' (-41) setting session active
  
  'Need resource to proceed' (-50) setting session active
  

===== See Also =====
  * [[:server:|Servers]]
  * [[:service:|Services]]
  * [[:faq:|Frequently Asked Questions]]

{{tag>tcpip servers}}