Date: Sat, 20 Mar 93 04:30:06 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #76
To: tcp-group-digest
TCP-Group Digest Sat, 20 Mar 93 Volume 93 : Issue 76
Today's Topics:
Dialer enhancements
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Fri, 19 Mar 93 19:40:40 EST
From: Mike Gallaher <mg@bds.bds.com>
Subject: Dialer enhancements
To: nos-bbs@hydra.carleton.CA
[This is a response to a question in nos-bbs, but I'm posting it to
tcp-group too.]
If you want to implement more flexible dialer scripts, you may want to
look at the script language used by the dialupip package. The doc and
source code is in uunet.uu.net:pub/networking/dialupip2.0.tar.Z.
While we're on the subject: I wanted JNOS to have the on-demand
dialing feature that's appeared in recent versions of ka9q NOS. (When
packets are outbound on an asy interface, if the dialup link is down,
it invokes the dialer script. When the link is made, the packets go
through. After a period of inactivity, it hangs up.)
The problem with the present scheme is that it's hard to use the same
port to route to different destinations. If you route to both Joe and
Harry over the same port, then datagrams for either will go to
whichever it happens to be connected to. (The misrouted packets
usually ping-pong back and forth until the time-to-live expires.)
I've been considering implementing a multiple-interface-per-port
scheme, similar to the Telebit NetBlazer's dynamic IP interfaces.
When such an IP interface has outbound traffic, it grabs a port from a
pool of available modem ports and dials up the destination, as before.
On the incoming call side, a calling host can start up a dynamic IP
interface on the called host, which automatically installs routes to
whatever destination are now reachable over the new connection.
Has anyone already done this, or something like it?
As a first step, I've got the demand-dialer working in JNOS. I
originally set out to port just the dialer to JNOS, but for various
reasons I wound up merging all the lower-level protocol code from ka9q
into JNOS. This includes everything from the device drivers up to the
socket code. (I haven't touched the servers, sessions, etc.) The
merged code mostly works, but I haven't fully shaken out all the bugs
yet.
Some of the reasons I've been wanting this code are:
- The ka9q code has a cleaner IP interface interface :). For example,
what used to be in rafts of #ifdefs is now called through function
pointers in the interface structure. This simplifies the
various link encapsulations, among other things.
The socket code is similarly cleaner.
- ka9q also has a much faster async driver. The async code in JNOS would
drop characters at speeds above 9600 on my 12MHz 286,
(A 16550 does keep this from being to much of a problem, but with
an internal V.32bis modem I don't have that option.)
The ka9q code doesn't lose any at 19200 (I haven't tried 38400).
- I haven't verified this by experiment yet, but I believe that the
ka9q code inherently avoids the output queue overflow problem that
JNOS suffers from.
I've been very careful to retain in the merged code the fixes made to
JNOS. (Sometimes it's not easy to tell which version was "fixed"...)
In particular, I can't test all the device drivers. The drivers are a
bit different in the ka9q code. The interrupt buffer pool (nibufs,
ibufsize) wasn't in ka9q (where did this come from, anyway?). Drivers
now pass their incoming packets up slightly differently. The
interrupt handlers have a different assembly-language wrapper.
Many of the drivers were already worked over in the ka9q code, but not
all the drivers in JNOS are present in ka9q, such as gracilis/packtwin.
The PI driver appears to have diverged considerably; I could use some
help with that one!
Mike Gallaher WA2HEE mg@bds.com wa2hee@wa2hee.ampr.org
------------------------------
End of TCP-Group Digest V93 #76
******************************
******************************