dave@jato.jpl.nasa.gov (Dave Hayes) (05/23/91)
Is there SLIP on Apollo 10.3? If so, where is it available from?
Thanks!
--
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ames!elroy!dxh
Complete possesion is proved only by giving
All you are unable to give posseses youdbfunk@ICAEN.UIOWA.EDU (David B Funk) (05/23/91)
In posting <1991May23.020448.7855@jato.jpl.nasa.gov>, Dave Hayes asks:
> Is there SLIP on Apollo 10.3? If so, where is it available from?
Now, I'm going to assume that you are asking about "Serial Line Internet
Protocol". when you say "SLIP".
THe answer is yes, it is available from /dev/sio1, and is controled by
doing an "/etc/ifconfig sl0 <ip-address> <dest-address>". Look at the
manual "Configuring and Managing TCP/IP" for more info, but be sure that
you have revision 002 (order no: 008543-A02). Also read the sr10.3 release
notes ("AA/install/doc/apollo/os.v.10.3__notes") for an important note about
baud rate limitations when using SLIP. In general, it is not reliable at
speeds above 4800 baud unless you have a DN4500 or faster machine.
Dave Funkherb@ajfcal.uucp (Herb Peyerl) (05/24/91)
dbfunk@ICAEN.UIOWA.EDU (David B Funk) writes: >baud rate limitations when using SLIP. In general, it is not reliable at >speeds above 4800 baud unless you have a DN4500 or faster machine. Yeah, but I wouldn't worry about it... I am composing this message through an Xterm on a DN3000 telnet'd to an IBM RT (AIX) through 19.2k slip link. I haven't had any problems with it... I've transfered large files through it and gotten the expected throughput... -- -------------------------------------------------------------------------- UUCP: herb@ajfcal.UUCP || #define Janitor Administrator I brew, therefore I am.. || Apollo System_Janitor, Novatel Communications "I spilled spot remover on my dog and now he's gone..." <Steven Wright>
dave@jato.jpl.nasa.gov (Dave Hayes) (05/29/91)
dbfunk@ICAEN.UIOWA.EDU (David B Funk) writes: >THe answer is yes, it is available from /dev/sio1, and is controled by >doing an "/etc/ifconfig sl0 <ip-address> <dest-address>". Ok. Now what? Seriously...we did the following: 1) Connect two Apollo machines by modem. (Call them A and B) 2) ifconfig sl0 on both machines: on A...ifconfig sl0 A B on B...ifconfig sl0 B A 3) On A ping B. THe ping didn't work. What now? AM I being hopelessly naive or what? -- Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ames!elroy!dxh "Every extreme attitude is a flight from the self." -- Eric Hoffer.
dbfunk@ICAEN.UIOWA.EDU (David B Funk) (05/31/91)
in posting <1991May28.214746.13408@jato.jpl.nasa.gov>, Dave Hayes writes: > dbfunk@ICAEN.UIOWA.EDU (David B Funk) writes: > >THe answer is yes, it is available from /dev/sio1, and is controled by > >doing an "/etc/ifconfig sl0 <ip-address> <dest-address>". > > Ok. Now what? > > Seriously...we did the following: > > 1) Connect two Apollo machines by modem. (Call them A and B) > 2) ifconfig sl0 on both machines: > on A...ifconfig sl0 A B > on B...ifconfig sl0 B A > 3) On A ping B. > > THe ping didn't work. What now? AM I being hopelessly naive or > what? The last time I played with slip was about a year ago & under sr10.2 At that time I found it relatively straight forward, just folllow the book and it pretty much worked. (except for modem hassles & baud rate problems). So I didn't think too much about my first posting on this topic. However the follow up questions implied that there may be more to it, so I went back and tried it again under sr10.3. Bingo, a new got-cha (bug? ;) discovered. It seems that under sr10.3 (specifically kernel(7), 10.3.0.5 & kernel(11), 10.3.4.1 with ts "1991/02/25 16:09:08 CDT (Mon) /etc/tcpd") the system does not properly configure the serial port for slip use; it does not put the line in "raw" mode. This causes checksum errors for each packet. ;{ With the proper usage of "/com/tctl" to condition the serial line it works just fine though. Here is the transcript from one test that I did: root_$ tctl -line 1 -default -speed 4800 root_$ /etc/server -p /etc/tcpd root_$ /etc/ifconfig sl0 128.255.16.5 128.255.16.6 netmask 255.255.255.0 root_$ /etc/ifconfig lo0 localhost root_$ tcpstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis sl0 1000 128.255.16 128.255.16.5 0 0 0 0 0 lo0 9216 loopback localhost 0 0 0 0 0 root_$ ping 128.255.16.6 PING 128.255.16.6: 56 data bytes Timed out (1 second) waiting for echo reply Timed out (1 second) waiting for echo reply Timed out (1 second) waiting for echo reply Timed out (1 second) waiting for echo reply Timed out (1 second) waiting for echo reply ----128.255.16.6 PING Statistics---- 5 packets transmitted, 0 packets received, 100% packet loss root_$ tctl -line 1 -raw root_$ ping 128.255.16.6 PING 128.255.16.6: 56 data bytes 64 bytes from 128.255.16.6: icmp_seq=0. time=430. ms 64 bytes from 128.255.16.6: icmp_seq=1. time=363. ms 64 bytes from 128.255.16.6: icmp_seq=2. time=362. ms 64 bytes from 128.255.16.6: icmp_seq=3. time=363. ms 64 bytes from 128.255.16.6: icmp_seq=4. time=363. ms 64 bytes from 128.255.16.6: icmp_seq=5. time=362. ms 64 bytes from 128.255.16.6: icmp_seq=6. time=362. ms ----128.255.16.6 PING Statistics---- 7 packets transmitted, 7 packets received, 0% packet loss round-trip (ms) min/avg/max = 362/377/430 I had to do the "tctl -line 1 -raw" to -both- ends of the slip link (assuming that you have apollos at both ends). Also this was with 2 machines directly connected via a null-modem cable. If you are using modems, you will have to use emt (or your favorite terminal emulater) to talk to your modem to make the call & get things connected -before- you do the ifconfig. Tcpd assumes that the lines are already connecetd, it doesn't know how to talk "modem-ese". It would probably be a good idea to "ifconfig sl0 down" before hanging up the phone. When you do "down" the interface, it will dissapear from a "tcpstat -i" listing. However it is still there, just do a "ifconfig sl0 up" and it wil reappear. One other note, if one of the machines is a DSP (displayless server node) you will need to redirect or delete /dev/sio.spm to keep the SPM from grabbing /dev/sio1 and using it for its console messages. So the bottom line is to do a "/com/tctl -line 1 -default -raw -speed 'baud'" (where 'baud' is the speed that you're using) before trying to use the slip link. In another posting <1991May24.133559.8614@ajfcal.uucp> (relating to my first note) Herb Peyerl <herb@ajfcal.UUCP> writes: >dbfunk@ICAEN.UIOWA.EDU (David B Funk) writes: >>baud rate limitations when using SLIP. In general, it is not reliable at >>speeds above 4800 baud unless you have a DN4500 or faster machine. > >Yeah, but I wouldn't worry about it... I am composing this message >through an Xterm on a DN3000 telnet'd to an IBM RT (AIX) through >19.2k slip link. I haven't had any problems with it... I've transfered >large files through it and gotten the expected throughput... My comment was derived from my experience with slip at sr10.2 connecting two DN3500s that were running a reasonable system load (various daemons, users etc). I found slip on that configuration to be usable at 4800 baud (01% packet loss in a ping test) but unreliable at 9600 baud (> 90% packet loss in a ping test). With different revisions of OS, hardware configurations, system load, etc your mileage will vary. Go ahead and experiment you can use "/com/tctl" to change your baud rate on the fly. In my recent test, I tried a DN3500 + 425t and it worked just fine at highter baud rates. Dave Funk