NetworkConsiderations

Network Configuration Considerations

Bandwidth Usage

Is this going to bog down my internet connection?

Those contemplating running internet ATCS servers sometimes worry about the bandwidth required to do so. Well, if you were hesitant to put a server (feed) on the net due to bandwidth, fear no more. Basically, if you have even a dedicated dial-up line, you really should put up your server. Fears of overrunning a monthly bandwidth cap are also unfounded.

A single instance of a busy feed with one listener generates about .4kbps of upstream traffic, which equates to about 1.5% of your probable 28.8k upstream dial-up rate. Recall that upstream in a typical internet situation is barely missed anyways, since web browsing is a downstream activity (upstream only handles requests and acks --- GET /dir/dir/file.htm and ACK is "got it") Say nothing of broadband, literally!

Test method: Used Network General Sniffer software (industry standard) software configured to measure bytes received from a busy Chicago area CSX BCP server over a 10 hour period. I used the csxchicago.gotdns.com:4802 feed provided by Don, as listed in the server database.

Traffic: All packets were counted, which include the UDP controls, indications, acks, etc. This BCP feed has 25 MCPs with 2.3.2/4 type packets (so both controls and indications are echoed). Data received had an overall 21% error rate for the period (each error generates a several byte (40-ish?) packet).

Raw Results:

• 10 hours
• 1860000 bytes
• 22000 packets (informational, but a good sanity check, since ATCSmon reported about 21000 ATCS packets...there is a touch of TCP overhead) - 8 bits per byte (constant)

Math:

• 1860000 bytes * 8 bits = 14880000 bits
• 14880000 bits / 10 hours = 1488000 b/hour
• 1488000 b/hour / 1000 b/kb = 1488 kb/hour
• 1488 kb/hour / 3600 sec/hour = .413 kb/sec

Yep, 413 bits per second. Basically squat. And this is a busy server. If you're in MCP-only territory the rate obviously goes WAY down from here.

BTW, I mentioned you could do this on dial-up, and you can, even though your IP address changes. See http://www.homeip.net or http://www.dyndns.org for details.

What about monthly bandwidth caps imposed by ISPs?

Site Servers:

For those concerned about ISP monthly "bandwidth caps", which are technically "usage caps", here's a bit more math. Bandwidth caps are something of misnomer, because bandwidth means, how much data can I possibly push in an given instant, so we measure it in bits per second (bps, roughly equivalent to "baud"), or in the case of DSL and cable, kilobits per second kbps) or megabits per second (Mbps). Usage is how many Bytes of data are used in a given period, usually per billing cycle (usually a month) and has nothing to do with "bandwidth". Bits is standardly abbreviated with a lower-case "b", Bytes is upper-case "B".

• .413kbps = 413 bps (bits per second)
• 413 bps / 8 bits per byte = 52 Bytes per second (rounded up)
• 52 Bytes * 60 sec (min) * 60 min (hour) * 24 hr (day) * 31 days (month) = 139,276,800 Bytes/month
• 139,276,800 Bytes/month = 139.3 MB/month (rounded up)
• Remember, this is based on a BUSY Chicago BCP feed, so it should be high. If you don't serve up this data via an aggregator (single connection), multiply by the number of direct connections you expect to have.
• Be certain that you take other precautions against (or calculate in) usage by other than ATCS data, such as automatic Windows and software update activity, anti-virus signature downloads, web browsing, etc.
• For reference, typical RadioReference.com scanner feeds occupy about 16kbps, which translates to 5GB/month; obviously far more of a factor for both bandwidth and usage.

Aggregators:

One of the first widely publicized landline bandwidth caps was imposed by Comcast (large cable internet provider) in October 2008. They are restricting usage to 250GB/mo.

[[1]]

Ok, let's be super conservative and say one connection is 1 Kbps. That would equal 1Kbps x 60 seconds x 60 minutes x 24 hours x 30 days= 2.592 Gb (small "b" = bits). Notice they used a Bytes allocation for their cap, not bits, whereas we measured in bits. Therefore, divide by 8 to get bytes, so in reality one EXTREMELY BUSY 1Kbps (normally WELL under half that for a typical non-aggregator) actually uses about 324MB/mo., or roughly 1/800th of the allotted 250GB cap.

-- Gary Hahn - 1 Sep 2008 - Contributions from Barry Baines, Dave Sheppard

Public Addresses

Well nobody has touched on this aspect so I will give it a go.

First off -> Public address ?? what IS that? There are two choices here; public or private. When talking about the Internet, a public address is one that can be routed to by other computers using the Internet. Public addresses are assigned in two different ways: static and dynamic.

• A static IP address is manually assigned by the ISP and usually does NOT change.

• A dynamic IP is assigned by most ISP's automagically and can change at the whim or wish of those entities.

Note that the two above are the same thing, it is just a matter of the amount of time or duration of the assignment. With dynamic you basically get a IP lease for a certain amount of time; could be seconds, minutes, hours or days!

Ok, so now we need to talk about IP's. Most of the residential Internet providers use DHCP ( dynamic host configuration protocol ) or PPPoE to assign a public address to your firewall's Internet connection. You DO have a firewall .. right? Since that address could change on a regular basis, it is not easy to map a host name to IP address. DNS ( domain name service ) is used to do just that. For instance, I update the DNS at my registrar to point names to IP's. Makes it easier for us humans. Why remember 206.63.25.90 for my web server when you can instead use www.soundrail.com to get there? I use enom ( http://www.enom.com ) for this as they have a great configuration widget. I don't worry about it until I need to make some host/alias change at a later date. So you now have more knowledge about DNS/DHCP than you may want to know! Oh yeah, I forgot... most of you want to run a server using an ISP providing a dynamic IP. For my home Internet and ATCSMon box, I use DynDNS which is pretty easy to setup and deal with. I also use it for the remote boxes that I have been setting up in different parts of Washington for monitoring. Most of you probably will end up with a name something like ' ATCSHomeserver.dyndns.org'. Note that the alias ( hostname ) portion (ATCSHomeserver) will be something that you think up and must be unique for that FQDN ( fully qualified domain name ). In other words there can NOT be two ATCSHomeserver.dyndns.org's pointing to different IP's! Well, OK so that is not exactly true. Load balancing uses something like that along with other stuff, but beyond this realm.

Now for the fun part. DynDNS has a widget that runs on your ATCSBox behind your firewall that updates the dynamic IP your Internet provider gives you and maps it to your alias. When you post your server name ( ATCSHomeserver.dyndns.org ) on the ATCS Monitor Yahoo site, people then point to that in their ATCS Monitor configuration and .. bingo ... traffic happens! As a note, I use Linux for my firewall and haven't had a inch of problems with the dns updater. I have heard horror stories about the NEW DynDNS widget for windoz so I used the older one. Yes, there is a link on the DynDNS site for it. Just remember to 'start it as a service' when you install it so that when ever your machine reboots, the IP address will be updated! As long as DynDNS check mark is green, people can find your server. Pretty simple isn't it?

Ok, test tomorra! Now lets see if we can put it all together. You have your DynDNS account setup and the widget is running on your ATCSMonitor server ( check mark is green ) right? There is yet another hoop you need to jump. How do people get from your public dynamic IP address to the address on your local network. You need to setup your ATCSMonitor box with a static IP and then port forward TCP 4800-4804 (as a five-server example) in your firewall ( You DO have a firewall ... right? ) to the IP address you assigned to the ATCS Monitor box. You will never guess what we are talking about now will ya? Yep Private Addresses. Your firewall uses DHCP to assign or lease a private address to all of the local computers on your network, except ones that you have assigned a static IP. Private address are usually in the form of:

• 10.0.0.0 to 10.255.255.255
• 172.16.0.0 to 172.31.255.255
• 192.168.0.0 to 192.168.255.255

You can't use some of the above. Most of the router/firewall boxes ( Linksys, Belkin, Dlink, Netgear ... etc ) of today assign in the 192.168 block and leave room for static IP's in the DHCP setup ranges. See your operation manual for your specific router/firewall. When you setup port forwarding to an internal private address, anything that is presented to your firewall in the port range or ranges you stipulated will be translated to the IP address you assigned to the ATCSMonitor box. Also called NAT'd ( network address translation ). Wow - things are up and working... you can sit back and watch trains!

Note there are other dynamic dns sites, I only used DynDNS as this example as that is the one I am familiar with. Google 'dynamic dns' for more options.

-- ctclibby Dec 6, 2008

Multiple Servers

Contact [| Gary Hahn] regarding an application which aggregates the feeds from multiple servers into one feed. Simplifies pairing a layout with a single host address rather than several addresses at different server site locations.

Internet Service Provider - specific notes

Verizon FIOS (Fiber)

Paraphrased from a message by Bill Larduskey with regard to installing Verizon FIOS.

If you only want Internet and phone on FiOS you can hook straight up from the Verizon box to your router and not use their router at all IF you specify that you want the install to be Cat5e and not Coax (they will push Coax). If you are upgrading from their DSL service remember to change from PPPoE to DHCP in your [router's] configuration.

If you do want their TV service it requires the use of their router which has configuration areas for some rule sets but I really didn't dig into UDP rules versus TCP rules. You could set a DMZ but that exposes your ATCS PC to the outside world [not recommended]. Their wireless access point only supports 64 bit WEP so it is recommended that you disable that as WEP is not a very secure encryption method - it's easily hacked.

-- JAlexLang - 13 Dec 2007

Verizon DSL

Several people have had difficulty serving from behind Verizon DSL when Verizon provides a Westell DSL modem/router. For one thing, newer versions seem to work better, so check if you can update the firmware or get a newer unit. Otherwise, use of ATCS Router software to relay the feed typically works a bit better because of the more frequent keepalive messages used by ATCS Router. Ask the Yahoo group for assistance with this.

Network Security Considerations

Firewall Configuration

See ServerAdministration for firewall configuration basics. Your exact interface will vary. In general, it's a good idea to update to the latest firmware to get the simplest configuration interface.

Network Security

Personal perspective of Gary Hahn:

This may look like an all-out home IT security synopsis, but I want to make sure that potential feed hosters are not discouraged from doing so! There is truth that operating a server introduces some risk, but as someone who involves myself in information technology security for a living, and as someone who hosts several audio and ATCS railroad feeds, it's not as bad as it may seem. Beware the naysayers!

In most cases, I let a broadband router, Windows XP Firewall, and Windows Updates protect my machines, and I really don't need to touch them or fret about them.

A bit about hackers and attacks...

1) Everyone on the internet gets attacked. EVERYONE. If by putting up a feed this attack rate increases, it's only by a few percent at most. This means that if your computer is not already compromised, the security systems you have in place are probably pretty much doing the job already.

2) Your exposure increases only a little, because you've poked a pinhole in your firewall(s) to allow people to connect. However, usually, you've set up a different computer for this function, so that's what they'd get to. Also, it only gives outsiders access to a single application (ATCS Monitor) so there would have to be known vulnerabilities to that application in order to perpetrate something evil, so keeping software up to date and applying Windows patches is most important. Since ATCS Monitor is so obscure, in the global sense, hackers aren't even aware it exists and if they do, so few people have it that it's not worth trying to write exploits for!

3) Most attacks are not "manned". These are robots looking for weak systems or juicy targets, which provide reports for hackers to choose their victims. These robots simply pick internet addresses at random and probe for weaknesses. If your security is weak, you could be compromised whether you've poked this new pinhole or not. Do you really have anything a hacker would want? Aside from borrowing your system to launch attacks at REAL targets like businesses and governments, you are probably not worth the trouble to a hacker. Again, it's unlikely that there's someone in Russia sitting there beating his head on the keyboard thinking "Darn it, I WILL get into Joe Foamer's ATCS feed computer if it's the last thing I do!"

4) Watching firewall logs will scare the pants off of you. If you plan to watch logs, be sure to do it now before you launch an internet feed, first. I guarantee you will see you are now being attacked often and that you will see very little difference once you launch your feed. If you want to sleep at night and not sacrifice precious hours of your life to pouring over firewall logs, just don't. Spend your time being proactive about keeping your defense mechanisms up to date instead.

Protect yourself! Do these regardless of whether you run a server. My comments, in order of priority:

1) Patch, patch, and patch some more. Why? It's software vulnerabilities which are the root risk point...an open port (pinhole) on a router is useless if the software doesn't somehow allow a way to exploit your computer. How to patch? Oh that's easy, now, just let Windows Update automatically apply updates as they come out. For any third-party applications you have that utilize internet (ATCS Monitor, audio feed software), grab the updates often.

2) External firewall (broadband router). Yep! $40 of protection for broadband users makes up for hundreds of "whoops" security indiscretions on the individual PCs.

3) Software firewall. Yep! For XP users, the built-in Windows Firewall is just dandy...done. For other OS, finding something is a good idea. Since most attacks are blocked at the external firewall, what this does is prevents your system from being hacked by other systems behind your firewall...yes, in your house. If you inadvertently download a "trojan horse" on your day-to-day PC, it may launch a "worm" that scours your own network for things to attack.

4) Anti-virus. A must for your everyday PC, but actually optional for your feed server. You're not downloading anything over there, that thing just sits and does it's job. Viruses are pulled down by users, maybe by email, web browsing, or even removable media. Really the risk is that if the server gets infected it may need to be rebuilt. I generally do not a/v dedicated servers.

5) ShieldsUp or similar. Can't hurt! This internet-based service scans your system to make sure all the measures you've taken are actually working, or tells you what to change. Trouble here, again, is that it may not differentiate in the report the things that are truly risks for the typical system...if it tells you every risk, again, you just won't sleep at night....unplug the computer for good!

Now, huge disclaimers!

I've tried to outline the reasonable things to do for a home user/server, not EVERYTHING to do. Again, to be completely secure, you have to unplug the computer from the power outlet. Security is a continuum; the more money you spend and the more people you hire to watch after your systems, the more secure you can be. If you haven't spent the money on a monitored alarm system for your house, a hacker COULD break in and TAKE your computer. Extreme example but points out that you should spend your money and time where it makes sense.

Finally, this is NOT my security approach for a business! The risks are far greater. Depending on the business, we're talking from tens of thousands to millions of dollars in security measures such as assessments, intrusion prevention, threat management, policy review, content management, etc, to protect millions of dollars in assets and sales. A rightfully different animal altogether....opposite end of the continuum.

ATCS Server Communications Detail

For those experiencing difficulty operating ATCSMonitor behind firewalls, the client-server protocol is documented below

Normal Client/Server Communications Summary

1. The ATCSMon client opens a TCP connection to the published server IP address and listener port (usually 4800) on the ATCSMon server, and waits for data arrival.

2. The ATCSMon server accepts the connection request, sends the port number it has established for the data connection, closes the TCP connection, and restarts the listener.

3. The client receives the port number, closes the TCP connection to the server listener port, and prepares for UDP traffic to and from the supplied port number. If there are no available UDP ports (all connections configured in Base=xxxxx,yy) or if your client is in the list of denied connections on the server, the word "Rejected" is sent to the client, and the client silently fails to connect.

4. Immediately after the TCP connection is closed, and every 2 minutes or less thereafter, the client sends the ATCS Monitor version number as a string like “3.5.2” (or "Thanks" in older versions) to the server on the assigned port via UDP. Otherwise, the server will assume the client has disappeared, and will cease sending traffic. The initial transmission is solely used to create an inbound path through a firewall for the forthcoming UDP, as many firewalls refuse to accept inbound UDP unless outbound UDP to the port is seen first.

4. The server sends complete, validated data packets to the client via UDP.

5. Every 2 minutes, if no traffic has been sent by the server, it sends the message "*KEEPALIVE" instead. This permits the client to assume the server has disappeared if nothing has been received for over 2 minutes, and then gracefully conclude the session.

6. The client sends the string "DISCONNECT" before terminating to keep the server happiest.

UDP Packet Loss for Servers

In case anyone is interested, I ran a little test with 2 clients at my home location on cable broadband from a server on fiber broadband.

As you know from reading the previous sections, ATCS Monitor uses the IP protocol UDP to pass the data received from the radio at the server on to the client. (TCP is only used to set up the connection.) UDP is a connectionless protocol, so when a packet is sent, it is hoped to arrive, but nothing ensures that it does. There is no resend of missed data, so you get what you get. Some call it "spray and pray" networking. I've maintained that UDP is an adequate method of operation for ATCS Monitor, and that using TCP would be a waste of bandwidth due to it's overhead in acknowledging packets as they're received.

So....

I compared actual sent packet counts (from ATCS Router aggregator) to the received count at ATCS Monitor. Over 28.75 hours, 46000 packets were sent to each client. Client #1 dropped 9 packets and client #2 dropped 4 packets. That's an average of 99.9859% server to client accuracy.

Of course various network factors such as saturation of any portion of the link will impact packet drop, but I'd say this is likely to be typical of most home internet users.

-- Main.GaryHahn - 01 May 2009

Normal Client/Server Communications Packet Detail

• Client <> Server (source / destination port number; example ports shown)

61399>4800 TCP SYN

61399<4800 TCP SYN ACK

61399>4800 TCP ACK

61399<4800 TCP PSH ACK UDP port #48140 communicated to client

61399>4800 TCP FIN ACK

61399<4800 TCP ACK

61399<4800 TCP FIN ACK

61399>4800 TCP ACK

61399>48140 UDP version (initializes client firewall to receive UDP traffic on 61399)

61399<48140 UDP data packets

61399<48140 UDP data packets

61399<48140 UDP data packets

61399>48140 UDP version again after 2 minutes to keep client port open

61399<48140 UDP data packets

61399<48140 UDP data packets

61399<48140 UDP data packets

61399>48140 UDP DISCONNECT (when client stops monitoring)

Server Workaround for Connection Problems with Certain Client Routers

Server operators running Linksys WRT54G and certain other makes and models may need to do the following as a workaround. For each server instance of ATCS Monitor, configure the Server Mode Listener Notes comment as “Base=x,y” where x is a base port number and y is the number of ports above x to make available. Variable x can be anything you do not already have in a range in use by another server instance. Variable y should be as small as possible for best security, but at least as big as the number of connections to support (minimum is 3). So “Base=33001,15” means that clients contacting you will connect to any of UDP ports 33001 through 33015. Without this “Base=x,y” configuration, clients contacting you could be any UDP ports from 1 through 65535, meaning you’d have to open that same range up in your router; a very huge range leaving a relatively large security vulnerability.

So once you’ve configured the “Base=x,y”, you will need to configure your router to forward that UDP range into your server, much as you did for the TCP connection. You already have a router configuration entry that forwards TCP 4800 (or other TCP port) to your server’s internal IP (perhaps 192.168.1.10). Now you need to set up a similar rule in the same section that forwards UDP 33001 thru 33015 (from our example above) to your server’s internal IP.

If you have multiple server instances, you might set up one instance with “Base=33001,15” and another with “Base=33016,15”. This means that you’ll set up the router to forward UDP 33001 through 33030 to the server.

Detail of Linksys WRT54G Server Problem with Certain Client Routers

From a D-Link client to a Linksys WRT54G server, the client actively refuses the UDP data packets with an ICMP port unreachable message. This continues even though the client sent its first UDP (with ver number).

The problem is that when the server does not receive the first UDP packet from the client, due to that the server router is not passing it to the server (unless UDP is opened up), the server sends its packet one source port number too low. So the client router sets up a conversation instance on S=61400 D=48140, then the server sends a data packet on S=48140 D=61399. The client router refuses this S/D pair since it does not match the conversation in its table.

In the case above, the TCP source was 61399, so it looks to me like ATCS Monitor server (or Windows IP stack) matches the UDP destination port to the TCP source. In fact, it did in all the samples I saw. But some clients send their initialization UDP using the port matching TCP source, while others increment the source port by one (or more likely, the client router increments it). In the latter case, the mismatch described above ensues.

-- Main.GaryHahn - 31 Aug 2008

DSL modem bridge mode (aka, IP Passthrough)

When I was setting up my ATCSMon server using DYNDNS dynamic DNS, a Westell DSL modem, and a Linksys WRT54G wireless router, connections to my server were being refused, even after following all the instructions and workarounds listed in this wiki. What was happening was that the remote connections were being refused by the DSL modem. One of the individuals on the ATCSMon yahoogroup recommended that I set up my router in bridge mode, which in the version of my modem's firmware is called IP Passthrough. To set this up, I went to the modem's firmware through my web browser, selected Home Network, then IP Passthrough. The setup was very easy, since I was only able to select one IP address. After setting up IP Passthrough and rebooting my DSL modem, other individuals were able to successfully connect to my server and receive data.

-- Main.WarrenWhitby - 31 Dec 2008 -- BrianSwan - 29 Oct 2006