OUTLINE OF MY PART: net side: KA9Q PCROUTE keeping lines up and connected modems: telebit supra digicom zyxel etc Phone service: POTS History of TLG Administrator job Enduser: OS/2 NOS FTP Software 386BSD admin: name service dead modems assigning IP addresses down ssytems maintaining mailing lists building routers debugging THE LITTLE GARDEN The Little Garden (TLG) is a cooperative network connected to the Internet using the services of AlterNet. It is not formally organized. The goal of TLG is to provide low cost wide-area IP connectivity to its members. TLG is responsible for forwarding traffic among its members, and between its members and AlterNet. TLG connects members systems to the Internet; it does not provide remote login nor email services, at this time. The Little Garden was formed when... [HISTORY] LITTLE GARDEN INFRASTRUCTURE The Little Garden has a lot of hardware accumulated over time, most of which was provided by the oroginal members when they first set up the network. Most likely if we were to build a more or less identical Little Garden from scratch, today, we would use fewer, cheaper boxes. Even two years ago there simply wasn't the choices in hardware we have today. The Little Garden has about 15 members scattered around the San Francisco Bay Area, in four locations; two in Mountain View (Cygnus Support and Trusted Information Systems (TIS)); one in Palo Alto, another in San Francisco. From the last two sites are fed the "low speed" members, such as myself, who connect using ordinary phone lines and modems, just as BBSs and FidoNet do (though with signifigant differences too). These four locations are known as Points of Presence, or POPs. POPs are linked together, and finally to the Internet at large, in our case using leased lines. As we add new members, so far rather haphazardly, we add new hardware as we go. All of this mess is paid for my the members, with a lot of initial investment done by the original members. New hardware however is paid for by new members, and while I am the manager (I prefer gardener) and The Internet is informally heirarchical, same as FidoNet; there are a number of backbones (Alternet, CIX, NSFnet, etc) which interconnect large sites and POPs. From each POP are further connected smaller sites, which may also act as POPs for even more sites. As of this writing, there are about 2,000,000 sites (hosts) connected this way. Leased lines are expensive. The local telephone companies have a monopoly on them, of course. They are frequently the only practical way to get from Here to There over multi-mile distances (see below for UNUSUAL CIRCUMSTANCES for fun workarounds...). The leased line from Mountain View to San Francisco costs about $350/month, not including the multi-thousand buck installation cost. It is an admittedly long 40 miles. At each end of a T1 or 56K leased-line is an ugly thing called a CSU/DSU, which is essentially a line driver modem. They cost about $500 per end; volume on these duckies is low, hence costs high. The Little Garden is connected to the Internet via a 56K-bit-restricted T1 to Alternet, our current service provider, to TIS. From TIS to Cygnus is another T1 (1.54Megabit/sec). Palo Alto and San Francisco are each connected to Cygnus via separate 56K leased lines. Where each line interconnects is a box called a router. A router, well, routes data between the interconnected host computers. The Little Garden has six to twelve routers, depending on how you count (some boxes have multiple functions these days). Routers vary widely in price, though they're dropping constantly. For example: a Livingston Portmaster 2E with ten async ports and one Ethernet port costs about $1850, or $185 per port. Each port supports one Internet member's site. Not bad. A basic 386 pclone with four async ports and Ethernet, running NOS, costs about $600 if you buy all the parts new, or about $150 per user. Not bad. Even less if you can scrounge. (Neither if these will support a full T1 though the Portmaster claims it'll do 800K aggregate; I think the NOS box would be working hard to keep up at 100K total.) FINDING AN IP CARRIER/SERVICE PROVIDER GETTING CONNECTED There are three major areas of interest in connecting your site to the Internet: the IP carrier (who usually provides IP connectivity to a number of customers); your site (your computer and software, unix, OS/2, etc); and the connection between the two (modems, phone lines, etc). The service provider is covered elsewhere; the last two are the ones you'll worry about the most. Your site can be as simple or complex as you need. A very practical system could be a single 386-based pclone running some flavor of unix, or OS/2, or even DOS with appropriate applications. A 286-based pclone with 1 meg of memory running NOS will work, but you'll be somewhat limited in what you can do, compared to other solutions. The high end is limited only by money (what else is new) and is therefore not as interesting to us here. HOST SOFTWARE I personally have run OS/2 and 386BSD unix, and NOS. I have nearly-zero experience with OS/2, though another Little Garden member uses OS/2 exclusively on one machine with wonderful results. (The only limitation I saw was that the telnet daemon in TCP/IP 2.1 was "faked", because OS/2 is not a multi-user system; there was a single password login that dumped you into a CMD shell. It seemed otherwise complete, and even a Kerberos authentication system is available.) If you utterly hate the macho command line of unix please check out OS/2; as much as I hate cluttered windowing systems, I have to admit IBM did a great job with OS/2. The multitasking is real, as opposed to the current joke of Microsoft Windows' "cooperative" (sic) multitasking. NOS is easy to install and run -- once you completely ignore the documentation and find a human with experience to handhold you all the way through it for a couple of months. NOS is great software, but it's exceedingly feature-filled, and there are many different versions out there. It was designed for amateur radio use, and has many features and commands utterly useless and alien outside that world. (I'm sure they say the same thing about "BBS" software that creeps into the ham radio world...) NOS has few built-in drivers; async port SLIP is about it (of interest to us). Other drivers are TSR-type drivers called "Clarkson" or "Bluebook" or [OTHERNAMEHERE], which are simply names for the same thing. If you're using NOS as your sole connection to the Internet, you can use the built-in Async/SLIP driver, and not worry about Bluebook drivers at all. If you're using it as a router, you'll probably want to use Ethernet. Most Ethernet cards come with a diskette full of drivers; poke around in the FTP or PCTCP directories and look for one that looks right. Following this article are some example NOS configuration files for these two representative uses. TELEPHONE SERVICE How you connect to your local POP depends on what arrangements you've made. Below 56K, you can generally use voice-grade phone lines and modems. If you go with a commercial service provider, you won't have any control over their end of the link, and they might recommend you get a "data line" of some sort. However, if you dial in to make the connection, you can use POTS -- Plain Old Telephone Service. In The Little Garden, both ends of the link are POTS. We utterly rely on the "local call" characteristic of home phone service; the fact that for a fixed monthly rate you get unlimited calls to some fixed geographical area. Because the modem/phone line connetion to the POP stays up continuously, nearly any per-minute charges make this method prohibitively expensive. (If the closest POP is not within your local dialing area, all is not lost; see the UNUSUAL PHONE LINE SITUATIONS section below.) In case it was not obvious enough -- you absolutely need a dedicated phone line for IP use. It cannot be shared with other users, human or otherwise. Since we're making a point-to-point connection, you need one phone line at your site, and one at the POP. What we do is tell new members to order two lines, one at our POP and one at their site. Just as in BBSing, don't alarm telco personell with talk about modems, data, networks, or any other scary technical gunk. You want phone service. Here's what to order: no call waiting, no long distance service, no added features. Depending on your local PUC, you may have other optional features; here in Calfornia, we can choose between "Measured Rate" and "Local Dialing"; with the former you pay for each call, even locally, the latter gives you "free" local dialing for a greater monthly fee. What we do is have the members site be "Local Dialing" and the POP end be "Measured Rate", since the connection is almost always originated (dialed) from the members site, the POP end never makes a call. One last but not least item: remember to have the telco mail the bill for both lines to your address, not that of the POP, unless other arrangements are made. Yes, it is unusual to have a phone line that makes one phone call that never ends, and in fact gets re-made if you unplug a modem by accident, etc. As far as anyone seems to know, there is no telco policy on this. Personally I'm not in favor of rocking this particular boat. One telco person said it's not that big a deal; each phone line has a pair of contacts assigned to it, and a 100% connect isn't using up any precious resources; it merely ties up those lines. This assumes a local call of course, using copper and not multiplexed or other long-distance type switching circuitry. So it's probably not a problem. What is a potential problem is a new-fangled device Pacific Bell has been installing on all new phone lines for some time now. Inside the little grey isolator box, behind the locked door is an ingenious device that allows for remote testing of the entire phone system, one line at a time; given some sort of electrical command from the central office, this device disconnects your phone (or modem...) momentarily, and presents a staandard impedance across the line that the central office then tests for; when complete your phone or modem is reconnected to the line. However, your modem may get upset with this fiddling and drop the connection. I have no idea how often this testing is done, nor how long the test takes, and whether or not it actually disrupts service, or when the test is done. (In case you're curious, the device is a small PC board wired in series between the outside line and your jack; red/green on one side and red-white-stripe/green-white-stripe on the other. Disconnecting one lead and connecting a wire between same-color screws would disable the device. You might get the installer to do this for you.) INSTALLING THE MODEMS If you've installed modems for a modern BBS or FidoNet system, are you in for a surprise. BBSing is nearly entirely done from modems, and the software is generally very smart about modems. IP is done over wire, Ethernet, radio, leased-line, twisted-pair, microwave, any and all that can carry bits. IP doesn't know anything about modems. This is As It Should Be, though it's damn annoying. NOS especially is very simplistic in it's use of modems, if you are not using the DIAL command. (We don't, because the rather old version of NOS that we're running has a bug in the DIAL command.) Most unix boxes are the same way; they are utterly ignorant of "AT" commands, result codes, etc. On the POP end, make the modem: auto-answer (S0=1), no result codes (Q1), no command echo (E0) Carrier Detect follows carrier/connect, and DTR ignore/acknowledge depends on the software used. For NOS, set to ignore DTR; this allows remote-restarting of the software without losing the connection. On the member site end, it matters not, though if you have to manually dial and establish the connection turn on all the result codes, speaker volume and all that to make it easier. Test, test, test!!! Your POP is a remote site, you don't want to have to drive across town every time you need to reconnect. If you have "remote configure" ability in your modems, by all means enable it and use it. The link between your site and your POP is a potential, though reasonably slight, security risk. The risk is that if you lose carrier, someone else could dial in to your (temporarily disconnected) POP, and use your connection to the Internet. In fact, this isn't much ofa problem for mere mortals. Assuming the link is down and your POP available, it would require someone who (1) knows that it's down (2) knows the phone number (3) your SLIP port address and (4) to get "in and out" before you notice the connection is down; a busy signal when you attempted reconnect would alert you immediately. If you are likely to have attempts like this you're out of my league entirely. Consult a security expert. Many modems have security features built in, such as passwording, call back, etc. You may want to use these. UNUSUAL PHONE LINE SITUATIONS In The Little Garden we have some members with not-so-unusual problems that have been overcome with a little ingenuity. We have POPs in San Francisco and Palo Alto; not all of our members can call those locations with their local dialing area. Local dialing areas frequently overlap, for example, San Francisco is not within Berkeley's local-dial-area, but Alameda is; San Francisco is within Alameda's local-dialing-area. One enterprising Berkeley member solved the problem with way: at a friends house in Alameda, he installed a single phone line and telephone, went there, and using optional Call Forwarding, forwarded all calls to San Francisco (his POP number). Then back home in Berkeley, dials the Alameda number, which forwards to San Francisco. The call to Alameda within Berkeley's local-dialing-area; the forward from Alameda to San Francisco is within Alameda's local-dialing-area. This method added about $9.00 to the monthly cost of IP connection. Another problem we encountered is that one members site is from a phone billed at business rates; ie. a per-minute charge that is prohibitive. At the moment a complex simulation of "demand SLIP" is implemented in scripts and chrons on a NeXT machine; the callback feature of many modems would solve this by allowing a single call from the business-rate phone to the POP modem, causing it to call back for the connect. UNUSUAL CIRCUMSTANCES Grasshopper Group: fishin' in the street... 814 University: Parking lot Ethernet... ESTABLISHING AND MAINTAINING THE CONNECTION Nearly all SLIP software requires the modem-to-modem connection to be "up" continuously and at all times in order to be useful. ("Demand SLIP" is possible, ie. dropping the connection after a pre-determined quiet time (no packets) and auto-dialing when either end has a packet to send, though I've personally not seen anything that does this -- yet.) You have two basic options on maintaining this connection. What most Little Garden members do is simply do it manually. There are things that will cause the connection to be lost; tripping over cords, unplugging to move equipment, power failures, reboots, etc. For most simple systems, eg. one or a few hosts, the effort to implement an automatic scheme is just not worth it. Mine is handled manually. I use the TIP command on my NOS box to issue ATDT command and manually start the connection. Pozar has his NOS box run a DIAL script if ten subsequent pings to the POP fail. it simply depends on how much effort you want to exert. (Presumably as time goes on our tools will get better and simple things won't be so much work!) The actual process you'll use to establish the connection depends entirely on the host software (unix, OS/2, NOS, etc) you use, as well as that of the POP (NOS, unix, etc). While I can't give you details, the overall process is pretty common, with one exception. SLIPPING INTO A UNIX BOX (or workalike) From your host site, you'll probably use TIP to manually issue commands to dial out to your other end, at the POP. Once the modems answer, you'll have to jump through hoops to get the damned things attention (issue BREAKs, hit CR repeatedly) or just hit a single CR, depending on how it's set up. (Unix modem handling today is about where BBSing was in 1980. Primitive.) You enter the username and password assigned to you at the login: and password: prompts; you'll probably get some sort of message announcing "SLIP READY" or somethint to this effect. At this point you terminate TIP (~.) and run SLATTACH and IFCONFIG and all that other fun stuff if your host is running unix or OS/2, or kill TIP with a RESET command if you're running NOS. SLIPPING INTO A NOS BOX A plain vanilla NOS installation assumes the async port is a simple piece of wire. Our two NOS boxes (four ports each) are arranged this way. The attached modems auto-answer, unbeknownst to NOS, and once connected, packets flow. That's that. Or, that's what we want. In real life though, since NOS is oblivious to the modems real status, online or offline, it will blindly output IP packets to the port, and therefore the modem, when it's offline. And when the modem is attempting to answer (assuming youv'e just dialed in) those extraneous packets are like hitting keyboard keys during manual use -- the modem aborts the connect attempt! Not good! We just live with it. Some modems, like some Telebits, can be commanded to ignore input when attempting to connect; presumably this is a common problem. As bad as all this sounds it in fact works OK. MODEMS net side: KA9Q PCROUTE keeping lines up and connected modems: telebit supra digicom zyxel etc Phone service: POTS History of TLG Administrator job Enduser: OS/2 NOS FTP Software 386BSD