mrc@cac.washington.edu (Mark Crispin) (06/27/91)
I recently got Louis Mamakos' port of Dial-UP IP for the NeXT
working between my office cube and home slab.
Here are a few notes that may be useful for someone else:
1) Have a thorough understanding of your IP connectivity
configuration. This issue is too complex to go into here, but
briefly, you need to have sketched out what you have since you will
have to make adjustments based on what you have.
2) Your modems *must* be hardware flow controlled. This means no
Mac modem cables. If you haven't done so already, call NeXTConnection
(1-800-800-NeXT) and order a pair of NeXT modem cables from them. At
$15/each, that's cheaper than most places sell Mac modem cables.
NeXTConnection is pricey in most of their other stuff but this is a
good deal.
I made the mistake of thinking I could win with Mac modem cables
and disabling XON/XOFF. I had amazing problems which were clearly due
to buffer overruns. NeXT modem cables and using /dev/cufa /dev/ttydfa
cured the lossage.
3) To make sure the slip line is seen by anyone else, make sure
that the gateway machine is running routed with the -s option. The
NeXT-supplied /etc/rc does not specify -s so you will need to add it.
4) I found that the the receiving (dudisc) end didn't work the
way the scripts expected. The scripts expect the string "Dialup IP
connected" to appear after sending the password, but dudisc doesn't
output it (at least it doesn't on my two systems and `strings' didn't
find it). To work around this, I put together this little hack, which
should be built and run as the login shell instead of the hard links
created by `duinstall':
#include <stdio.h>
main (int argc,char *argv[],char *envp[])
{
char *nargv[] = {"dudisc_slip0",0};
puts ("Dialup IP connected");
execve ("/usr/dialupip/bin/dudisc",nargv,envp);
}louie@sayshell.umd.edu (Louis A. Mamakos) (06/27/91)
In article <1991Jun27.071351.17884@milton.u.washington.edu> mrc@cac.washington.edu (Mark Crispin) writes: > 1) Have a thorough understanding of your IP connectivity >configuration. This issue is too complex to go into here, but >briefly, you need to have sketched out what you have since you will >have to make adjustments based on what you have. Yes, that's for sure. Everyone's environment and situation is likely to be just a little bit different. Remember, you're designing a network here, and that deserves careful thought. > 2) Your modems *must* be hardware flow controlled. This means no >Mac modem cables. I'm surpised to hear this. I'm using a non-hardware flow controlled connection to my modem at 9600 BPS, and it has worked just fine. On the other hand, it is NOT a Mac cable because it has DTR and CD correctly wired. > 3) To make sure the slip line is seen by anyone else, make sure >that the gateway machine is running routed with the -s option. The >NeXT-supplied /etc/rc does not specify -s so you will need to add it. This is very much a site specific option, and one of many solutions. At our site, this won't work because of how the routing is configured and who believes what. Again, see (1) above for thinking Real Hard about how your proposed configuration is supposed to work. > 4) I found that the the receiving (dudisc) end didn't work the >way the scripts expected. The scripts expect the string "Dialup IP >connected" to appear after sending the password, but dudisc doesn't >output it (at least it doesn't on my two systems and `strings' didn't >find it). To work around this, I put together this little hack, which >should be built and run as the login shell instead of the hard links >created by `duinstall': It looks like dudisc tries to spits out a message like: DialUpIP 1.0 910613 connected to "slip0" but is does so AFTER it has switched the line discipline to the SLIP line discipline. I'll try to fix this. Rather than hack a small program, you might just consider hacking on the scripts. The scripts provided are very much just samples and not intended to be the last word on how things are supposed to be done. You might just have your script look for the echo of the login or password that you shove at it. The "goal" of the scripts is to turn on the SLIP connection. Once it does that, it invoked the "go" command to start up the network connetion on the NeXT. For a hardwired line, potentially you might have the single line "go" as your script if the other end always has the serial connection in SLIP mode. One other point to keep in mind is that by default, the Inactivity timer of the SLIP interface is 300 seconds. This also applies to interfaces that are "enabled" by using the dudisc program for dial-in connections. You might consider increasing the timeout by using the duioctl program right after you ifconfig the interface's address. /usr/dialupip/bin/duioctl slip0 SATIMEO 99999999 louie
waltrip@capd.jhuapl.edu (06/27/91)
In article <1991Jun27.071351.17884@milton.u.washington.edu>, mrc@cac.washington.edu > (Mark Crispin) writes: > > I recently got Louis Mamakos' port of Dial-UP IP for the NeXT > working between my office cube and home slab. > > Here are a few notes that may be useful for someone else: [...note 1 deleted...] > 2) Your modems *must* be hardware flow controlled. This means no > Mac modem cables. If you haven't done so already, call NeXTConnection > (1-800-800-NeXT) and order a pair of NeXT modem cables from them. At > $15/each, that's cheaper than most places sell Mac modem cables. > NeXTConnection is pricey in most of their other stuff but this is a > good deal. > > I made the mistake of thinking I could win with Mac modem cables > and disabling XON/XOFF. I had amazing problems which were clearly due > to buffer overruns. NeXT modem cables and using /dev/cufa /dev/ttydfa > cured the lossage. > Do you think this might be related to characteristics of the machines you were connecting to? I am planning to try to connect to VAX/VMS systems running TGV Multinet which I would expect to support XON/XOFF (since that is the standard VAX/VMS mode). I don't believe I would be able to make it all work together if I have XON/XOFF flow control on the VAX side and hardware RTS/CTS flow control on the NeXT side (or vice versa). Did the systems you were trying to connect to support XON/XOFF? [...notes 3 and 4 deleted...] Thanks for sharing this info. c.f.waltrip Internet: <waltrip@capsrv.jhuapl.edu> Opinions expressed are my own.
hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy)) (06/27/91)
In article <1991Jun27.124556.27545@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: > > > 2) Your modems *must* be hardware flow controlled. This means no > >Mac modem cables. > > I'm surpised to hear this. I'm using a non-hardware flow controlled > connection to my modem at 9600 BPS, and it has worked just fine. On > the other hand, it is NOT a Mac cable because it has DTR and CD > correctly wired. I am using hardware flow control (/dev/cufb) AND what appears to be a Macintosh cable (have not checked the connections, but it works on a Mac), without any trouble; but I am still at 2400 Baud. >> Rather than hack a small program, you might just consider hacking on >> the scripts. The scripts provided are very much just samples and not >> intended to be the last word on how things are supposed to be done. >> You might just have your script look for the echo of the login or >> password that you shove at it. We have modified the scripts for our local situation and Carl Edman (expect to read more from him later) has come up with a neat "awk" script to extract the varible IP number our server assigns and use it in ifconfig. If it weren't for 2400 Baud -- I would be very happy. I even 'crawled' X-window programs from my HP-host with output on the NeXT. And they worked! Now I am working on our University's networking people to speed up the installation of higher-speed modems at the other end. Thanks, Louie for an extremely useful program! Greetings, Hardy -------****------- Meinhard E. Mayer (Hardy); Department of Physics, University of California Irvine CA 92717; (714) 856 5543; hardy@golem.ps.uci.edu or MMAYER@UCI.BITNET
louie@sayshell.umd.edu (Louis A. Mamakos) (06/27/91)
In article <1991Jun27.100914.1@capd.jhuapl.edu> waltrip@capd.jhuapl.edu writes: > I am planning to try to connect to VAX/VMS systems > running TGV Multinet which I would expect to support XON/XOFF (since that > is the standard VAX/VMS mode). If you're gonna use SLIP, you must have an 8 bit transparent serial connection. That means that you cannot use XON/XOFF for flow control. Really. Now, with PPP, you can get around this particular problem.. louie
eps@toaster.SFSU.EDU (Eric P. Scott) (06/28/91)
In article <1991Jun27.124556.27545@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >I'm surpised to hear this. I'm using a non-hardware flow controlled >connection to my modem at 9600 BPS, and it has worked just fine. I have to agree with Mark--I tried 9600 BPS w/o hardware flow control, and I was getting complaints from the zs driver about stuff coming in too fast. Not often enough that TCP couldn't recover, but often enough to be annoying. With hardware flow control I was able to run at 38.4Kb with no problems whatsoever. -=EPS=-
nerd@percival.rain.com (Michael Galassi) (06/28/91)
louie@sayshell.umd.edu (Louis A. Mamakos) writes: >In article <1991Jun27.071351.17884@milton.u.washington.edu> mrc@cac.washington.edu (Mark Crispin) writes: >> 2) Your modems *must* be hardware flow controlled. This means no >>Mac modem cables. >I'm surpised to hear this. I'm using a non-hardware flow controlled >connection to my modem at 9600 BPS, and it has worked just fine. On >the other hand, it is NOT a Mac cable because it has DTR and CD >correctly wired. You need hardware flow control any time you don't know the actual throughput of your modem. This will be the case with any v42bis (LAPM) or mnp5 modem where the data stream is compressed and the compression ratio is a function of the data (i.e. varies over time). Many of the newer v32, v32bis, and v24bis modems support v42bis data compression which is a real boon for slip throughput when highly compressible data is being transferred though our experience on RAINet (Portland, OR's MetroNet) is that response time (i.e. ping/ echo/et all) are not heavily affected. >> 3) To make sure the slip line is seen by anyone else, make sure >>that the gateway machine is running routed with the -s option. The >>NeXT-supplied /etc/rc does not specify -s so you will need to add it. >This is very much a site specific option, and one of many solutions. >At our site, this won't work because of how the routing is configured >and who believes what. Again, see (1) above for thinking Real Hard >about how your proposed configuration is supposed to work. The man page says this is the default for situations with multiple network interfaces or with point-to-point links, did NeXT F* up again? -- Michael Galassi | nerd@percival.rain.com MS-DOS: The ultimate PC virus. | ...!tektronix!percy!nerd
louie@sayshell.umd.edu (Louis A. Mamakos) (06/29/91)
In article <1991Jun28.143819.2188@percy.rain.com> nerd@percival.rain.com (Michael Galassi) writes: >You need hardware flow control any time you don't know the actual >throughput of your modem. This will be the case with any v42bis >(LAPM) or mnp5 modem where the data stream is compressed and the >compression ratio is a function of the data (i.e. varies over time). But the issue here is why Mark was experiencing zs0 overrun errors. The point that I made is that I am running my NeXT serial port at 9600 BPS, and the modem interface at 9600 BPS; the bytes are not going to come in from the modem any faster than 9600 BPS. I am not experiencing overrun errors on input on my machine, and was surprised that Mark was on his. MNP or V.42 Compression really doesn't become an issue here. I'm still interesting in finding out the circumstances under which input overruns are occuring. Were you doing I/O to the OD or floppy disk at the time? Playing sounds? Printing to a NeXT printer? From the debugging that I was doing, I noticed that the line discipline input routine usually gets called with 15 bytes at a time; this gives plenty of time to do other things in between. louie