tcpip_faq.html 24.54 KiB
<html>
<head>
<title>Synchronet Version 3 and TCP/IP: Answers to Frequently Asked Questions</title>
</head>
<body>
<font face="Arial", "Helvetica">
<h1 align="center">Synchronet Version 3 and TCP/IP<br><font size=5><i>Answers to Frequently Asked Questions</i></font></h1>
<hr>
<p>
<h2>Table of Contents:</h2>
<ul>
<li><a href="#ports">What inbound ports do I need to open in my firewall?</a>
<li><a href="#private_ip">How come my friends can't connect to my BBS at my IP address?</a>
<li><a href="#public_ip">What is my public IP address?</a>
<li><a href="#relay_smtp">Why can't I relay Internet e-mail through my BBS?</a>
<li><a href="#tx_smtp">Why can't I send Internet e-mail from my BBS?</a>
<li><a href="#rx_smtp">Why can't my BBS receive Internet e-mail or inter-BBS instant messages?</a>
<li><a href="#ftp_connect">Why can't users connect to my FTP server?</a>
<li><a href="#ftp_nat">Why do FTP clients lock-up or time-out when listing directories or downloading files from my FTP server?</a>
<li><a href="#socket_io">Why do external programs that use socket I/O not work on my Windows BBS?</a>
<li><a href="#bind">Why do some or all of my servers get bind errors when starting or recycling?</a>
<li><a href="#bandwidth">How many nodes/clients/users can I support with my Internet connection?</a>
</ul>
<a name="ports"><hr></a>
<p>
<b>Question:</b><br>
<i>What inbound ports do I need to open in my <b>firewall</b>?</i>
<p>
<b>Answer:</b>
<br>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.
<p>The default Synchronet installation enables servers and services on the following ports:
<p>
<table border=1>
<tr valign="top" align="left"><th>Protocol<th>Port<th>Comments
<tr valign="top"><td nowrap>Telnet<td nowrap>TCP 23<td>For Telnet logins (highly recommended)
<tr valign="top"><td>RLogin<td nowrap>TCP 513<td>Optional for quick-login from RLogin clients (e.g. SyncTerm)
<tr valign="top"><td>SMTP<td nowrap>TCP 25<td>Necessary for receiving Internet e-mail and inter-bbs instant messages
<tr valign="top"><td>POP3<td nowrap>TCP 110<td>Allows BBS users to check their e-mail using standard Internet mail clients (e.g. Outlook Express)
<tr valign="top"><td>FTP<td nowrap>TCP 21<td>Allows access to the BBS file/download areas using a standard FTP client or web browser
<tr valign="top"><td>HTTP<td nowrap>TCP 80<td>Required for access to the BBS's web server
<tr valign="top"><td>NNTP<td nowrap>TCP 119<td>Allows BBS users to read and post messages using standard news readers/clients
<tr valign="top"><td>Gopher<td nowrap>TCP 70<td>Archaic protocol allows reading of messages and other BBS info
<tr valign="top"><td>Finger<td nowrap>TCP 79<td>Allows remote querying of BBS user info, who's online, and other BBS info
<tr valign="top"><td>Finger<td nowrap>UDP 79<td>For use with the Synchronet inter-bbs instant message service
<tr valign="top"><td>IRC<td nowrap>TCP 6667<td>Allows Internet Relay Chat (IRC) clients to connect to your BBS
</table>
<p>Enabling connectivity to Synchronet through your firewall is <b>no different</b> 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 <b>all</b> its ports to the public Internet), but doing so is not normally recommended.
</p>
<a name="private_ip"><hr></a>
<p>
<b>Question:</b><br>
<i>How come my friends can't connect to my BBS at my <b>192.168.x.x</b>, <b>172.[16-31].x.x</b>, or <b>10.x.x.x</b> IP address?</i>
<p>
<b>Answer:</b>
<br>The IP address ranges listed above are reserved for use in <b>private</b> networks and are <b>not publicly addressible</b>
from the Internet. See this <a href=http://www.faqs.org/rfcs/rfc1918.html>document</a> for technical details.
<p>You do <b>not</b> 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 <b>private</b> network to share the same <b>public</b> IP address using a mechanism known as
<i>Network Address Translation</i> (<a href=http://www.faqs.org/rfcs/rfc1631.html>NAT</a>).
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 <b>will not</b> begin with <i>192.168</i>, <i>172.[16-31]</i>, or <i>10</i>.
</p>
<a name="public_ip"><hr></a>
<p>
<b>Question:</b><br>
<i>What is my <b>public</b> IP address?</i>
<p>
<b>Answer:</b>
<br>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 <a href=http://www.whatismyipaddress.com/>any</a>
<a href=http://checkip.dyndns.org/>one</a> of <a href=http://www.whatismyip.com/>many</a>
public web-sites that can tell you what your public IP address is. However, it is usually much better to advertise a <b>hostname</b>
(e.g. <i>vert.synchro.net</i>) rather than a cryptic hard-to-remember IP address (e.g. <i>69.104.209.211</i>).
<p>
If you use a <i><a href=dyndns.txt>Dynamic DNS</a></i> service to get a hostname for your BBS,
they can usually correctly determine your public IP address automatically, even if your IP address changes.
So you don't <b>need</b> to necessarily know what it is.
</p>
<a name="relay_smtp"><hr></a>
<p>
<b>Question:</b><br>
<i>Why can't I <b>relay Internet e-mail</b> through my BBS?</i>
<p>
<b>Answer:</b>
<br>Indications of this problem include error messages in your e-mail client similar to the following:
<br><tt>553 Relaying through this server requires authentication. Please authenticate before sending.</tt>
<br><tt>550 Relay not allowed.</tt>
<br>
Or error messages similar to the following in your Synchronet Mail Server window/log output:
<br><tt>0504 !SMTP ILLEGAL RELAY ATTEMPT from <yourname@yourhost.org> [192.168.0.2] to someuser@somehost.com</tt>
<br>Where the <i>from</i> address is that of your mail sending host and the <i>to</i> address is that of an external mail recipient
that <b>you</b> are attempting to send e-mail to.
<p>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.
<p>By default, the Synchronet Mail Server <b>disallows</b> the <i>relaying</i> of SMTP e-mail messages
received for an external recipient (not destined for a local BBS user account).
<p>
You <b>can</b> allow specific hosts or users to relay e-mail through your mail server by either:
<ol>
<li>Entering the sending host's IP address or hostname in your <tt>ctrl/relay.cfg</tt> file.
<br>This file may be edited with the SBBSCTRL:Mail->Edit->Allowed Relay List menu option.
<p>
or:
<p>
<li>Use SMTP authentication:
<ol type=a>
<li>Enable the mail server configuration option to allow authenticated users to relay mail.
<br>This can be done by adding <tt>ALLOW_RELAY</tt> to the <tt>Options</tt> key of the
<tt>[mail]</tt> section of your <tt>ctrl/sbbs.ini</tt> file.
<br>Or, if using SBBSCTRL, checking the "Allow Authenticated Users to Relay Mail" checkbox
on the SMTP tab of the Mail Server Configuration dialog.
<p>
<li>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.
</ol>
<br>The Synchronet Mail Server supports the following SMTP authentication schemes:
<ul>
<li>PLAIN
<li>LOGIN
<li>CRAM-MD5
<br>(Note: password case sensitivity
can be an issue when using CRAM-MD5 authentication)
</ul>
</ol>
<a name="tx_smtp"><hr></a>
<p>
<b>Question:</b><br>
<i>Why can't I <b>send Internet e-mail</b> from my BBS?</i><p>
<b>Answer:</b>
<br>You must have the Synchronet SendMail thread enabled in your Synchronet Mail Server configuration.
<br>If you <b>do not</b> see the following message in your Synchronet Mail Server window/log output when the server
is started or recycled:</p>
<tt>0000 SendMail thread started</tt>
<p>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).
<p>If your Synchronet SendMail thread cannot deliver e-mail messages, it could be for any of the following
reasons:
<ol>
<li>You have your mail server configured for "Direct Delivery", but have an improperly configured DNS server
IP address.
<br>Example errors indicating this condition include:
<br><tt>0000 !SEND INVALID DNS server address</tt>
<br><tt>0000 !SEND ERROR -1 obtaining MX records for someserver.com from 192.168.1.1</tt>
<p>The configured DNS server IP address should usually be set to that of your ISP's primary DNS server.
<p>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 <i>blank</i>
or <tt><auto></tt>.
<br>You'll know this feature is active when you see log lines similar to the following:
<br><tt>0000 SEND using auto-detected DNS server address: 206.13.29.12</tt>
<p>
<li>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).
<br>Example errors indicating this condition include:
<br><tt>0700 !SEND ERROR 60 connecting to SMTP server: smtp.somedomain.com</tt>
<br><tt>0023 !SEND ERROR 110 connecting to SMTP server: mx.somesite.org</tt>
<p>
You can verify if this is the case by attempting to Telnet to a known public SMTP server (e.g. <i>vert.synchro.net</i>) on TCP port 25.
<br>You should see a mail server version banner similar to the following:
<br><tt>220 bbs.synchro.net Synchronet SMTP Server 1.362-Win32 Ready</tt>
<p>If you cannot connect or do not see a mail server version banner, then <i>something</i> is filtering or blocking
your outbound connections to TCP port 25.
<p>
If your ISP is blocking port 25, they will normally make an exception for their own mail servers
(e.g. <tt>mail.yourisp.com</tt> or <tt>smtp.yourisp.com</tt>). If this is the case (and your ISP's mail server allows the <i>from</i> 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. <b>Do not</b> use your own mail server's hostname or IP address as the relay server
(this will cause an undesireable message "loop").
<p>
If your ISP's mail server <b>only</b> allows e-mail to be sent from <tt>somename@yourisp.com</tt>
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?
<p>
<li>You have your mail server configured to use an external "Relay Server", but have an improperly configured
relay server hostname or IP address.
<br>Example errors indicating this condition include:
<br><tt>0000 !ERROR resolving hostname: badhostname.com</tt>
<br><tt>0680 !SEND ERROR 60 connecting to SMTP server: 192.168.1.1</tt>
<p>
<li>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.
<br>Example errors indicating this condition include:
<br><tt>0000 !Delivery attempt #1 FAILED (somehost.org replied with: "550 Relay not allowed." instead of the expected reply: "250 ...")</tt>
<br><tt>0000 !Delivery attempt #1 FAILED (somehost.org replied with: "553 Authentication required." instead of the expected reply: "250 ...")</tt>
<p>Synchronet v3.12+ supports the <i>Plain</i>, <i>Login</i>, and <i>CRAM-MD5</i> methods of SMTP authentication when relaying
mail through an external relay server. To enable SMTP authentication when relaying, add one of the <tt>RELAY_AUTH</tt> flags to the <tt>Options</tt> value in the
<tt>[Mail]</tt> section of your <tt>ctrl/sbbs.ini</tt> file. Or, if running sbbsctrl-Win32, enable one of the authentication
radio buttons on the "Relay" tab of the Mail Server Configuration dialog.
<p>
<li>You have a message in your outbound e-mail queue that is flagged as '<i>in transit</i>'. If you're
running only <i>one</i> instance of the Synchronet Mail Server, this is not a normal condition and the affected message
<b>will not be sent</b> until the '<i>in transit</i>' flag is cleared.
<br>Example log message indicating this condition:
<br><tt>0000 SEND Message #999 from Some User to someone@somesite.com - in transit</tt>
<p>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 '<i>in transit</i>' flag is used to protect multiple instances of the SendMail thread from attempting to deliver the same e-mail message simultaneously.
<p>If you only have one instance of the Synchronet SendMail thread active (the usual scenario), you can eliminate this problem
by adding <tt>SEND_INTRANSIT</tt> to the <tt>Options</tt> value in the <tt>[Mail]</tt> section of your <tt>ctrl/sbbs.ini</tt> file.
Or you can remove the '<i>in transit</i>' flags from all existing e-mail messages by running the <tt>fixsmb</tt> utility on your
<tt>data/mail</tt> database or by running the <tt>exec/notransit.js</tt> script.
</ol>
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.
</p>
<a name="rx_smtp"><hr></a>
<p>
<b>Question:</b><br>
<i>Why can't my BBS <b>receive Internet e-mail</b> or inter-BBS instant messages?</i>
<p>
<b>Answer:</b>
<br>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:</p>
<tt>220 bbs.synchro.net Synchronet SMTP Server 1.362-Win32 Ready</tt>
<p>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 its 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. <i>vert.synchro.net</i>, 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.
<p>
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 <a href=http://www.dyndns.org/services/mailhop/relay.html>service</a>
for a fee. Or a fellow sysop may be able and willing to perform this service for you as a favor.
</p>
<a name="ftp_connect"><hr></a>
<p>
<b>Question:</b><br>
<i>Why can't users connect to my FTP server?</i>
<p>
<b>Answer:</b>
<br>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.
<p>If your FTP server window/log indicates an accepted FTP connection, then it's not a connectivity problem and probably a login failure.
<p>FTP sessions require a <b>login</b>. If you have not created a <i>Guest</i> account for your BBS, then the FTP server will
not allow <i>Annonymous</i> logins (most web browsers, for example, will attempt to login anonymously by default). If this is the problem,
then either create a <i>Guest</i> account (preferably using the <tt>exec/makeguest.js</tt> module) or tell your FTP users that they
must login with a valid BBS user account in order to use the FTP server.
</p>
<a name="ftp_nat"><hr></a>
<p>
<b>Question:</b><br>
<i>Why do FTP clients lock-up or time-out when listing directories or downloading files from my FTP server?</i>
<p>
<b>Answer:</b><br>
Your BBS computer is probably behind a <i>Network Address Translator</i> (<a href=http://www.faqs.org/rfcs/rfc1631.html>NAT</a>).
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 <b>passive</b> (PASV) transfers work fine, but <b>active</b> (PORT) transfers do not, or vice versa.
<p>
This <a href=http://www.ncftpd.com/ncftpd/doc/misc/ftp_and_firewalls.html>document</a>
contains the technical details about how and why and the recommended solutions.
<p>Note: Most web browsers (e.g. <i>Microsoft Internet Explorer</i>) use <b>passive</b> FTP transfer mode by default.
<p>Note: Some FTP clients (e.g. the Windows command-line FTP client) <b>only</b> support <b>active</b> mode transfers.
<p>
Enabling the logging of FTP data channel activity can help diagnose these kinds of problems.
This can be done by adding the <tt>DEBUG_DATA</tt> option to the <tt>Options</tt> value in the
<tt>[FTP]</tt> section of your <tt>ctrl/sbbs.ini</tt> fileor by checking the <b>Data Channel Activity</b> checkbox in the <i>Log</i>
tab of the <i>FTP Server Configuration</i> dialog in the <i>Synchronet Control Panel</i> for Win32.
<p>If you're having problems with <b>passive</b> transfers and you're seeing
<tt>!UNSUPPORTED COMMAND from <i>username</i>: 'P@SW'</tt> in your FTP server log/window output,
you're probably using an <b><i>SMC Barricade</i></b> router (see this <a href="http://www.gbnetwork.co.uk/smcftpd/">
document</a> for details). Upgrade to Synchronet v3.13a (FTP Server Revision 1.296) or later to
work-around this problem with this device.
<p>
If you're having problems with <b>passive</b> (PASV) transfers through your NAT/firewall device
and you're running Synchronet v3.13a (FTP Server Revision 1.296) or later:
<ul>
<li>If the remote client is attempting to connect to your <a href="#private_ip"><b>private</b> IP address</a>
(your NAT device isn't <i>translating</i> the PASV response from the FTP server) and you have a
<b>static</b> public IP address, you can work-around this limitation of your NAT device by using
the <tt>PasvIpAddress</tt> value in the <tt>[FTP]</tt> section of your <tt>ctrl/sbbs.ini</tt> file to
specify your <a href="#public_ip"><b>public</b> IP address</a>.
<p>
<li>If your firewall cannot dynamically open/forward FTP PASV data ports for incoming passive FTP data connections, you can
specifiy a limited <i>range</i> of TCP port numbers to use for passive transfers by modifying the
<tt>PasvPortLow</tt> and <tt>PasvPortHigh</tt> values in the <tt>[FTP]</tt> section of your
<tt>ctrl/sbbs.ini</tt> file. You will of course need to configure your firewall device to open/forward
these ports to your FTP server.
</ul>
</p>
<a name="socket_io"><hr></a>
<p>
<b>Question:</b><br>
<i>Why do external programs that use socket I/O (e.g. Synchronet Blackjack, Synchronet BBS List, DoorMUD, SEXYZ) not work on my Windows BBS?</i>
<p>
<b>Answer:</b><br>
Some "security" software (e.g. firewall and anti-virus programs) will interfere with the inheritance of socket descriptors between processes.
One such program is the <b><i>ZoneAlarm Security Suite</i></b>.
I don't know if this is an intentional security "feature" or a <b>design flaw</b>.
If you have this (or similar) software installed, it must be completely un-installed for socket inheritance to work.
</p>
<a name="bind"><hr></a>
<p>
<b>Question:</b><br>
<i>Why do some or all of my servers get <b>bind errors</b> when starting or recycling?</i>
<p>
<b>Answer:</b><br>
If you're getting bind errors when first starting up one or more Synchronet servers,
similar to the following:
<p><tt>0420 !ERROR 48 binding FTP Server socket to port 21</tt>
<p>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
<a href="http://www.rt.com/man/netstat.1.html">netstat</a> (for Windows or Unix)
or <a href="http://www.sysinternals.com/Utilities/TcpView.html">TCPView</a> (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.
<p>If you're running a <b>Unix</b>-like operating system (<i>not</i> Windows) and get bind errors only when
recycling servers, this is most likely because a TCP session is stuck in a TCP <i>TIMEWAIT</i> state
(you can use <a href="http://www.rt.com/man/netstat.1.html">netstat</a> 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
<tt>BindRetryCount</tt> and/or <tt>BindRetryDelay</tt> values
in your <tt>ctrl/sbbs.ini</tt> file, or you can add the following line to your <tt>ctrl/sockopts.cfg</tt> file:
<p><tt>REUSEADDR 1</tt>
</p>
Or, if running Synchronet v3.13b or later, your <tt>ctrl/sockopts.ini</tt> file:
<p><tt>REUSEADDR=1</tt>
</p>
<a name="bandwidth"><hr></a><p>
<b>Question:</b><br>
<i>How many nodes/clients/users can I support with my Internet connection?</i>
<p>
<b>Answer:</b><br>
Depends on what those clients will be doing while connected. Here are some facts to consider:
<ol>
<li><b>A BBS node doesn't consume any bandwidth when not <i>in use</i>.</b>
<p>
<li><b>An active TCP session doesn't consume any appreciable bandwidth when <i>idle</i>.</b>
<p>
<li><b>Most Internet connections are <i>asymmetrical</i> in nature (as in <u>A</u>DSL).</b>
<p>This means your <i>upstream</i> channel usually has less bandwidth than your <i>downstream</i> channel.
<br>When TCP/IP clients (users of your BBS's servers) <i>download</i> content from your servers
(this includes viewing menus, reading messages, and playing door games on your BBS),
they are primarily using your <i>upstream</i> channel.
<p>So if you have a 1.5Mbps/128Kbps DSL connection, your <i>downstream</i> is 1.5Mbps while your
<i>upstream</i> is only 128Kbps.
If you have a "56K" dial-up connections, for example, your <i>downstream</i> is probably
in the 43-53Kbps range while your <i>upstream</i> bandwidth cannot be any more than 33.6Kbps.
<p>If you are lucky enough to have an <b><u>S</u>DSL</b> or other type of <i>symmetrical</i> Internet connection,
then both your upstream and downstream channels are of the same bandwidth.
<p>
<li><b>Most BBS traffic is <i>bursty</i>.</b>
<p>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.
<p>
<li><b>Not all clients will be capable of saturating your upstream channel.</b>
<p>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.
</ol>
<p>
</p>
<hr>
<p align="right"><font size="1">
$Id$</font>
</p>
</font>
</body>
</html>