pjh@mccc.edu (Pete Holsberg) (01/10/91)
I have a pair of 3B2/400s running SV R3.1, StarLAN-1 and RFS. I also have a 386 running SV/386 R3.2.2 (includes Network Support Utilities and RFS, both release 1.2 version 2.0) and StarGroup 3.2 (to a bunch of MSDOS clients). Each network works well. So I administered the 3B2 (mccc) that's the primary server for its network to include the 386 (tech) and set up RFS. Next I connected the cable between an IN on one NAU and an OUT on the other, and rebooted all three computers. The 3B2s come up normally, but I get the following message from the 386: rfstart: could not contact primary name server rfstart: No reply from domain name server I have swapped cables and manually checked out all configuration files, and everything seems to be OK (well, I know that the cables are OK). It dawned on me today that I hadn't tried to see if Starlan was OK. So I tried to do a "cu -d mccc" from the 386. Here's what I got: conn(mccc) Device Type STARLAN wanted ProtoStr = eg Internal caller type TLIS filelock: ok tlicall: bound to t_connect to addr "mccc" t_connect: System error tlicall: system error: Invalid argument. Undaunted, I went to the 3B2 that's connected to mccc and did the same "cu -d mccc". The first five lines were as above but the sixth said: tlicall: bound to ATT.TLI and then it connected successfully! I grep /usr/lib/uucp, /usr/net, /usr/nserve, and /usr/slan looking for ATT.TLI but drew a blank. The 3B2 and the 386 have identical Devices and Systems entries: STARLAN,eg starlan - - TLIS \D mccc Any STARLAN - mccc in:--in: nuucp Help! -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
thad@cup.portal.com (Thad P Floryan) (01/11/91)
pjh@mccc.edu (Pete Holsberg) in <1991Jan10.021409.2651@mccc.edu> writes:
I have a pair of 3B2/400s running SV R3.1, StarLAN-1 and RFS. I also
have a 386 running SV/386 R3.2.2 (includes Network Support Utilities
and RFS, both release 1.2 version 2.0) and StarGroup 3.2 (to a bunch
of MSDOS clients).
Each network works well. So I administered the 3B2 (mccc) that's the
primary server for its network to include the 386 (tech) and set up
RFS. Next I connected the cable between an IN on one NAU and an OUT
on the other, and rebooted all three computers. The 3B2s come up
normally, but I get the following message from the 386:
rfstart: could not contact primary name server
rfstart: No reply from domain name server
I have swapped cables and manually checked out all configuration
files, and everything seems to be OK (well, I know that the cables are
OK).
[...]
The 3B2 and the 386 have identical Devices and Systems entries:
STARLAN,eg starlan - - TLIS \D
mccc Any STARLAN - mccc in:--in: nuucp
Help!
Though I don't have the same hardware config you do (mine are 3B1), I solved a
similar problem when I first brought StarLAN up on my systems. I've extracted
the relevant portions of several files listed below in the hope this can serve
you as a model for the changes required on your systems.
Please note the entries in Dialers matching entries in Devices; this "may" be
the solution in your case (it's been a while since I've done this and my docs
aren't handy).
Thad Floryan [ thad@cup.portal.com ]
-------------------- begin included material
/usr/lib/uucp/Devices:
#
STARLAN starlan - Any STARLAN
STARLAN_NAU,eg starlan - Any STARLAN \D.serve pc_uucp
STARLAN_UU,eg starlan - Any STARLAN \D.serve SLAN_uucico
/usr/lib/uucp/Sysfiles:
service=cu systems=Systems.cu:Systems \
devices=Devices \
dialers=Dialers
service=uucico systems=Systems.uucico:Systems \
devices=Devices \
dialers=Dialers
/usr/lib/uucp/Systems.cu:
# StarLAN entries for cu activity
#
amiga Any STARLAN - access0 "" \r\d\r in:--in: nuucp
thadlabs Any STARLAN - thadlabs "" \r\d\r in:--in: nuucp
tlabs3 Any STARLAN - tlabs3 "" \r\d\r in:--in: nuucp
tlabs4 Any STARLAN - tlabs4 "" \r\d\r in:--in: nuucp
tlabs5 Any STARLAN - tlabs5 "" \r\d\r in:--in: nuucp
/usr/lib/uucp/Systems.uucico:
# StarLAN entries for uucico activity
#
thadlabs Any STARLAN_NAU,eg - thadlabs "" \r\d\r in:--in: nuucp
tlabs3 Any STARLAN_NAU,eg - tlabs3 "" \r\d\r in:--in: nuucp
tlabs4 Any STARLAN_NAU,eg - tlabs4 "" \r\d\r in:--in: nuucp
tlabs5 Any STARLAN_NAU,eg - tlabs5 "" \r\d\r in:--in: nuucp
/usr/lib/uucp/Dialers:
# STARLAN dialers
#
STARLAN_NIU "" "" \r\d\r\d\r DIAL:-\r\d\r\d\r-DIAL: \D "" \d\d\c
pc_uucp "" "" NLPS:000:001:102\N\c
SLAN_uucico "" "" NLPS:000:001:101\N\c
SLAN_login "" "" NLPS:000:001:1\N\c
nls "" "" NLPS:000:001:1\N\c
-------------------- end included materialbbh@mtek.com (Bud Hovell @ Mtek) (02/14/91)
We have a 3B2/400 and two 3B1s, all fitted out with StarLAN, and set up
in a daisy-chain with the 3B2 at the top of the chain. All the hardware
and underlying software seems to check out fine.
We are able to log in and send mail from either 3B1 to any other machine,
including the 3B2. We can send mail from the 3B2 to either of the 3B1s.
What we *cannot* do is log in from the 3B2 to either of the 3B1s.
I can't figure out what I am missing here. One problem in gaining a solution
is that the debugging output provides error messages which are (to me, anyhow)
quite cryptic, and I've no idea where they can be looked up to find out what
they mean. In some rare AT&T manual that I don't own, probably. :-)
This is the debugging output when I attempt to call from the 3B2 to one of
the 3B1s ('irish') on our StarLAN network ('mteknet'):
$ cu -d irish
conn(irish)
Device Type mteknet wanted
ProtoStr = eg
Internal caller type TLI
filelock: ok
tlicall: bound to ATT.TLI
t_connect to addr irish
set interface TLI
processdev: calling setdevcfg(cu, mteknet)
gdial(nls) called
chat: TCGETA failed, errno 13
expect: ("")
got it
sendthem (<NO CR>???????)
getto ret 6
device status for fd=6
tdmp for fd=6: Permission denied
call _mode(1)
Connected
_receive started
got read error, not EINTR
Lost Carrier
call _rcvdead(4)
call _bye(16)
Disconnected
call cleanup(4)
call _mode(0)
Can someone suggest what may be wrong here? Thanks for any help you may be
able to offer. ^^^
--
____________
bud@mtek.com
"...God give me the strength to be what I am." - Gabriella Brinner