craig@NNSC.NSF.NET.UUCP (11/20/87)
At CSNET we're experimenting with an idea which is close to this.
The basic idea is that when an IP packet hits our gateway destined
for a remote machine we make a phone call, establish the link, and
keep it running as long as there is continued traffic. When the
traffic stops, we shut down the line.
There are lots of nasty little problems in this scheme:
- The TCP SYN takes a huge hit for establishing the phone call.
So the initial RTT estimate will be much too high.
- Topology. That SYN probably can't take multiple hops in which
the phone gets dialed. (We're using a star topology with gateway
in the center).
- How to maintain line quality. We know how variable long-distance
connectivity is.
Interestingly, keeping track of when the line is busy probably isn't a
problem (we already had to handle that problem in X25Net).
Also note that this system is designed to support more than IP. We want to
be able to use more than IP over the interface (line control packets, ISO IP,
XNS, etc). So we had to put leaders in.
Finally, address mapping is fixed. Each address is assigned, and we
do a deterministic IP address to phone # mapping to do the phone call.
We then log in at the remote end, and start up the line protocol.
Craiggnu@hoptoad.UUCP (11/20/87)
UC Davis was doing a summer project with dialup slip. Their software
is available on ucdavis.ucdavis.edu in the "pub/dialslip" directory, as
I recall (don't you hate it how NOBODY gives a full and correct path
for stuff available by anonymous ftp?). I haven't tried any of it yet.
John
Here's the README from ucdavis:
This directory contains the first distribution of software used at UC
Davis for dialin SLIP connections for the UCD Network. The complete
system is a combination of patches for 4.3bsd and the CMU/IP software,
plus new software for the dialin capability. The software comes in five
tar files. Here is a description of what is in each tar file.
1. tiocgetu.tar
This file contains patches and a new function for the 4.3bsd IO. A
problem existed with 4.3 in the linkage of a SLIP interface and the
actual device. The problem was this: The normal procedure to set up a
SLIP was to ifconfig the interface to the desired parameters then
slattach the device to this interface, BUT the slattach just grabs the
first available interface which may or may not be the one that you just
ifconfig'ed. This really becomes a problem when multiple SLIPs are
comming and going randomly. To solve this problem, a patch was added to
slattach to return the interface to which the device was connected. The
returned interface can then be ifconfig'ed AFTER slattach has been
connected to it. This makes sure that the associated device and
interface are coordinated. To make things even easier, there is a new
function included in this tar that does the the whole process, slattach
and ifconfig, in one call.
2. dialslip.tar
This file contains the software necessary to manage the dialin SLIP
connections. The procedure for establishing a SLIP connection is to
logon to the 4.3 computer and enter the slip command. After the command
has been issued, the line becomes a SLIP connection. Disconnection is
accomplished when the serial connection is lost (no carrier detect) and
the line is then reset to a normal login line. Address assignment and
security is provided by a file that associates an IP address with the
usercode. A connection for a given IP address can only be made from the
usercode to which that address is assigned in the configuration file. Of
course the computer dialing in must also be configured for this address.
The software also maintains a file of current connections that can be
displayed to see wht SLIP connections are currently logged in. This file
is also used by the system to make sure that the IP address is not
already connected before making a new connection. If a person logs in on
the same usercode twice at the same time, only the first SLIP connection
will succeed. NOTE: the patches in tiocgetu.tar must be installed before
the software in this tar will work.
3. cmuslip.tar
These are patches to the CMU/IP software that do two things. One, makes
the com port on the pc setable from the CUSTOM program, and two, fixes a
bug that would briefly drop DTR on the com port during a SLIP
connection. (for us that caused immediate disconnection :-})
4. sterm.tar
This is the CMU/IP terminal program with a script capability added. The
script can be setup to allow connection to the network by automatically
sending the sequence needed to dial the modem, logon, and send commands
to connect to SLIP. The script can also wait for given strings to return
to allow testing, timing out, and branching depending on what response
is returned.
5. cmumakes.tar
This file contains a new set of MAKE files for the CMU/IP software that
are better (or at least different) than the standard ones. This tar also
contains a new tarread program that allows extraction so subsets of the
files in a tar file.
The abbreviated IP packet software working but still has a couple of
bugs we want to get out before releasing it. It should be ready in
another week or so, but we wanted to make this available for those that
want to get started.
Russell Hobby
Data Communications Manager
U. C. Davis
Computing Services BITNET: RDHOBBY@UCDAVIS
Davis Ca 95616 UUCP: ...!ucbvax!ucdavis!rdhobby
(916) 752-0236 INTERNET: rdhobby@ucdavis.edu
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
Love your country but never trust its government.
-- from a hand-painted road sign in central Pennsylvaniaandrew@mitisft.UUCP (11/21/87)
in article <8711192329.AA03145@ucbvax.Berkeley.EDU>, craig@NNSC.NSF.NET (Craig Partridge) says: > > > At CSNET we're experimenting with an idea which is close to this. > > The basic idea is that when an IP packet hits our gateway destined > for a remote machine we make a phone call, establish the link, and > keep it running as long as there is continued traffic. When the > traffic stops, we shut down the line. > We've had dial-up SLIP running for over a year internally here at Convergent, initially on a more-or-less straight 4.3 port and currently on a Streams port. It works, basically, by having a deamon which is woken up when the routing code chooses a "dialed" (more generally, switched) route. It then calls into a bunch of UUCP code to establish the connection, and logs in to an account which runs the daemon in "server mode". The "client" then informs the "server" of who he is (ascii), his numeric address, and what he thinks the server's numeric address is. The server checks his host and authentication files, they synchronize and slattach, and the deferred packets are sent. After that its peer-peer, until a timeout occurs with active TCP or carrier loss. I still consider this to be in the experimental phase, primarily in the routing area. Currently the system uses the "gateway" model; no net number is assigned to the link itself, an each system sort of thinks it has an interface on the nets connected to the remote. The inital connection protocol is pretty crude -- just an exchange of cute little text messages. Eventually I'd like to add some simple error checking, though the problems there have been minimal so far. We use it over our PBX to comminiacte between biuldings here regularly, at 19200 baud. Andrew Knutsen (408) 435-3623 I'm also planning on testing with the new high speed modems.