bushell@HAWK.NSTN.NS.CA (Tom Bushell) (11/26/90)
Hello, We're about to offer dial in Internet access over SLIP for NSTN (the Nova Scotia Technology Network). Our plan is to let our customers use public domain packages like NSCD Telnet with the Clarkson SLIP packet driver to dial in to a central teminal server, using Hayes compatable modems with their PCs. I've been able to dial the modem from Phil Karn's KA9Q using the "tip" command, but we want to automate this process for our dial in customers, so they just run their applications (Telnet, FTP, whatever) and the connection will be automatically established. We have three main requirements: 1) Must be able to automatically establish a SLIP connection over a modem. 2) Must be able to automatically accept an IP number assigned by the terminal server being dialed into, and run public domain applications like KA9Q and NCSD Telnet with this IP number. 3) To try to minimize connect charges for the users, we want to monitor the line for user activity, and drop it after a specified period if there is none, even if he/she is still in the application. We want to reconnect when activity is detected. I'm currently in the process of coding to solve #1 and #2. Our approach is to use a standalone C program to establish a connection, get the IP number from the terminal server, and use it to modify the configuration file for NSCA Telnet. I'll probably have this working soon, but if someone were to hand me an existing solution on a silver platter, I'd be happy to take it. Requirement #3 looks like a bit of a bitch. Looks like we'll have to write a TSR that grabs the PC's system timer, and decrements a counter for the line idle timeout. If this counter reaches 0, the line is dropped. We'll also have to modify the SLIP packet driver so it resets this counter every time a packet is sent by the user. My questions are: Is this a good approach to meet our three requirements? Has anyone out there already met any or all of these goals? If so, can you share what you did? Thanks in advance to all who take the time to reply. I will post response to the net if interest is sufficient. As an incentive to code sharing, I've been given tenative permission to make the code I'm working on available. Thanks Tom ************************************************************* * Tom Bushell Software Kinetics Ltd * * 101 Ilsley Ave * * E-mail - bushell@hawk.nstn.ns.ca Suite 5 * * Phone (902)468-3680 Dartmouth N.S., Canada * * Fax (902)468-3679 B3B 1S8 * *************************************************************
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/02/90)
On 26 Nov 90 12:02:54 GMT, bushell@HAWK.NSTN.NS.CA (Tom Bushell) said: bushell> We're about to offer dial in Internet access over SLIP for NSTN bushell> (the Nova Scotia Technology Network). Our plan is to let our bushell> customers use public domain packages like NSCD Telnet with the bushell> Clarkson SLIP packet driver to dial in to a central teminal bushell> server, using Hayes compatable modems with their PCs. I will not comment on the auto-dial problem, which is fairly obvious, but I will sternly warn you that using SLIP for such an application is largely suboptimal. By all means switch to PPP. SLIP is a patch up job for connecting _two_ machines with a temporary link. If you want to do the proper thing, that is a dial up IP network, PPP is the answer. It provides the framework to solve many difficult problems that any SLIP setup just ignores. There are already PPP implementations for the most popular architectures, and I seem to remember that ther eis even a NOS version with PPP compiled in. PPP support is not as diffuse as SLIP support, but since you are just starting, by all means do not lock yourself into a dead end. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
chad@qip.UUCP (Chad R. Larson) (12/04/90)
In article <1852@hawk.nstn.ns.ca> bushell@hawk.nstn.ns.ca writes: +--------------- | We have three main requirements: | | 1) Must be able to automatically establish a SLIP connection over a modem. | | 2) Must be able to automatically accept an IP number assigned by the | terminal server being dialed into, and run public domain applications like | KA9Q and NCSD Telnet with this IP number. | | 3) To try to minimize connect charges for the users, we want to monitor the | line for user activity, and drop it after a specified period if there | is none, even if he/she is still in the application. We want to | reconnect when activity is detected. +--------------- A product called the "NetBlazer" from Telebit meets all your needs, I believe. It is a combination Bridge/Router/Terminal server built on a PC chassis. It supports ethernet cards, wide area net cards, and Digiboard multi-port async cards in combination. It uses Phil Karn's Network Operating System as its heart. The serial cards are used to provide both terminal service and dial-up IP connections. The dial-up connections may be either dial out or in, and either SLIP or PPP. The modems I saw it demo'd with were Telebit Trailblazers (natch) but I think any Hayes compatable will do. You can set a time-out value on a link, and the dial connection will be dropped after the time out. The TCP connection need not be dropped, and when the next packet arrives the dial connection is re-established. I saw it demo'd at InterOp '90 in San Jose. I have no connection with Telebit. -- Chad R. Larson ...{mcdphx,asuvax}!anasaz!chad or chad@anasaz.UUCP Anasazi, Inc. - 7500 North Dreamy Draw Drive, Suite 120, Phoenix, Az 85020 (602) 870-3330 "I read the news today, oh boy!" -- John Lennon
cec@cup.portal.com (Cerafin E Castillo) (12/07/90)
While the virtual circuit, IP addressing, and idle time may be
critical points to your application(s), I would have to agree on
the speed of SLIP. Currently, most SLIP/CSLIP/PPP are run via high-speed
modems and hardwired links which are limited to the abilities of
the serial I/O port in combination with the phone line or copper wire
bandwith. 18 Kbps is the fastest currently possible on the phone line
(Telebit PEP) but V.32 (9600) is the most responsive to interactive
full-duplex sessions. 38.4 Kbps is quite suitable via hardwired connection.
But for a WAN, its got to be modems or special services (leased, 56k, T1).
The NetBlazer introduces two ways in which one can attain high throughput
while using SLIP/CSLIP/PPP. A 56 kbps V.35/RS-232 interface board can
be integrated into the NetBlazer and used with Synchronous PPP to talk
to another NetBlazer OR the Cisco, Novell, and 3COM PPP Routers. INVERSE
MULTIPLEXING is yet another way to gain a high thorughput, BUT over
phone lines!
Inverse muxing is a way of taking two or more modems (TELEBIT V.32s) and
dividing an IP data stream amongst them. Thus, you multiply your bandwith
by the number of modems used and their throughput:
6 modems x 9600 bps (V.32) = 57.6 kbps (approx.)
This can be done using SLIP/CSLIP/PPP, BUT requires two NetBlazers (1-mux
-> 2-demux) and multiple phone lines and modems to accomplish the connection.
The modems are assigned as a group and the high-water mark is the maximum
number of modems in the group. Thus, if your file transfer or X-Windows
session does not require all 6 modems, only the number needed to get the
job done (as calculated by the NetBlazer) are used. The other modems remain
on standby or are used on a first-come; first-serve basis, depending on the
number of overlapping groups given access to the modem pool. Any contension
for modems yield a 'Network Unreachable' error. The modems go on and off
hook as more or less bandwith is needed throughout the connection.
I understand that Inverse Muxing has been tested with up to 24 modems so
far, with reliablity and good throughput (remember TCP/IP overhead over
serial lines...).
These two features are meant to provide ease of dialbackup or Point-of-
Presence (POP) applications in WANs. If your 56 kbps goes down, several
modems pick-up and replace the high-throughput connection (metrics are
used to keep traffic on 56 kbps channel until modems are needed; OSPF is
on the way in the NetBlazer - '91). These features will also serve quite
well for a dial-up IP service provider. The nice part about this is that
the modems are auto initialized and configured for the connection in the
virtual circuit. This leaves the Sys or Net Admin to worry about IP addresses
and and network topography rather then hacking SLIP drivers and configuring
modems to auto-dial. RIP makes this box go well with your routers, gated,
and routed systems and SNMP MIB I and II provide good network support.
NCSA Telnet, KA9Q [NOS] (PPP.12), freeware SLIP for Suns, as well as VJ
CSLIP, FTP Software Inc. PC-205 for DOS, and InterCon InterConnect II for
Mac; were all tested with this box doing SLIP/CSLIP/PPP. I used them all
quite a bit and found no problems. I am waiting for the virtual circuit
capabilities to be built into these applications in order to enjoy this
connectionless IP environment from my Mac/PC/UNIX sys at home to my office
NetBlazer. It'd be nice to see this in a few X-Windows terminals, as well.
We'll see what the future brings for these product.
For more information, please feel free to e-mail or phone, I'm a TELEBIT
distributor, as well as an ex-Telebit (NetBlazer) employee. (Sorry for
the salesy plug, but I do have this info and carry the products...;-).
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \ | \ |
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
INTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================jbvb@FTP.COM (James B. Van Bokkelen) (12/08/90)
While our SLIP version of PC/TCP has been around for a long time, note that we are not yet shipping our PPP. Xmas? James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901