david@ms.uky.edu (David Herron -- One of the vertebrae) (05/03/89)
I'm trying to establish a slip connection .. as a test .. as so: -----+--------ether-------+--------- this cable is network 128.163.0.0 | | | | + + g/g2----serial-line---staff/staff2 ^ +-- this is network 223.163.130.0, currently unassigned to anybody. Also I'm not advertising a route to it. With interface IP addresses assigned as so: ether slip g 128.163.128.7 223.163.130.1 g2 staff 128.163.128.78 223.163.130.2 staff2 /etc/sliphosts contains: staff: 223.163.130.1 223.163.130.2 255.255.255.0 9600 hw ... g: SLstaff 223.163.130.1 255.255.255.0 any /dev/tty Both machines are uVaxIIen running Ultrix v3.0 and the pseudo-device sl has been configured in. 'staff' is a vs2000 and 'g' is a true-blue uVaxII in that roll-around case they first sold 'em in. I'm prevented from doing all the testing I want to do since this is finals week and lots of grad students are working on project. Crashing machines isn't very popular right now ;-). At first the link wasn't working at all. After doing slattach, the device on the staff2 side was completely configured and the one on g2 was down but otherwise unconfigured. Eventually I discovered that if I ifconfig'd sl0 on g AFTER starting things up, it will start fine. So great, now I can do SLIP ... Were you expecting the BUT? BUT ... I've gotta have another connection to the target machine in order to ifconfig sl0 ... so trying a login shell like: | 4 - g:david --> cat staff2 #! /bin/sh (sleep 10; ifconfig sl0 223.163.130.1 223.163.130.2 up -trailers netmask 255.255.255.0 )& /usr/new/slattach exit 0 | 5 - g:david --> doesn't configure the device ... it just stays marked as down. I haven't yet tried a more simple approach with "slattach" then "sleep" then "ifconfig". The slattach man page leads me to believe that it's doing an ifconfig for me. Perhaps it doesn't do it on the slave side? I dunno ... YAB (Yet Another BUT) ... Trying to bring down the connection doesn't work too well. On "staff" to bring it down I "ifconfig sl0 down" then find the slattach process and kill it, the only problem is that the machine hangs (except for the mouse cursor) for about 10 seconds. On "g" if I ifconfig/kill it, it prints "rtpurge 81546000 815dee00" (or "rtpurge 81546000 815c6e80") in a loop on the console, hanging the machine -- the only way out is a reboot. The only place that's printed is from net/raw_usrreq.c but seeing as I don't have sources I don't know what's going on there. And this message isn't printed *ANYWHERE* in the Ultrix v2.2, MtXinu 4.3, 4.3-tahoe network (ftp'd from uunet yesterday), or Dynix 3.? sources. What're these numbers? They can't be hex versions of an IP address because the one I'm using has the high bit set in the first byte. I suppose they're addresses of some internal data structure. Should I work from the other end of the connection? I haven't had the time yet to try the ifconfig/kill first on staff then on g yet and don't know what difference it would make. Also .. cutting the line between the two doesn't make the software hang up & reset the line. This is something I'd like to be able to do .. to offer dial-up SLIP service to our users. They log in to their account and do "slattach" and it does the ifconfig & etc for them and when they hang up it cleans up after itself. But no, it doesn't clean things up. I'd call DEC for queries .. BUT this is an unsupported piece of software so they'd probably just turn me away.. Any suggestions? Is the if_sl.o they provide much different than if_sl.o's for other operating systems? I know that slattach is much different from the one in the 4.3-tahoe sources .. that one doesn't even TRY to do nice things like provide an L.sys type script to log in with... -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- By all accounts, Cyprus (or was it Crete?) was covered with trees at one time <- -- Until they discovered Bronze