MLMCKEE@AUDUCVAX.BITNET (01/17/90)
In the v8n156 issue of Sun Spots, ralerche@lindy.stanford.edu summarized
the best way to 'spool mac laserwriter output on a sun'. The method of
choice was KIP running on a Kinetic FastPath and CAP running on the sun.
the code had not been installed so no information was available on how
difficult that would be. I downloaded KIP0688 and CAP5.0 from
uunet.uu.net, read all the documentation and attempted to install the
software. the fast path we have is Version 4 (K-star Version 7.0) and my
sun is a sparkstation (4.0.3c). the sun is running yp, is designated the
administrator for the K-box but is not a server. the sun is on a LAN
ether network with PC's and (via the FastPath) MAC's. /etc/services has
been modified to include the udp ports starting at 200 (this requires
option 11 in the K-box configuration file. The /etc/atalkad deamon was
started with the /etc/atalk.local file given below:
21.42 50 the Chem Zone
20.1 2 131.204.42.2
and the /etc/atalkatab file:
21.42 N1 131.204.42.0 KSL #sun, appletalk-in-IP
21.42 N1 131.204.42.0 CSLI #chemistry, appletalk-in-IP
20.1 KC 131.204.42.2 CSLI #fastpath, localtalk
I131.204.42.255 I131.204.2.10 #ipbroad ipname=nameserver
I131.204.42.50 L0 #ipdebug ipfile
L0 L0 L0 L0 S0 S200 #ipother atnetet ddprangestart
Lx0 S0 S40 #flags ipstatic ipdynamic
S20.1 S21.42 #atneta atnete
(the sun is 131.204.42.50 and the K-box is 131.204.42.2 on a class-b net)
The first test is to run atlook which checks to see if the sun
can see anything on appletalk. When atlook is executed the following is
produced:
abInit: [ddp: 21.42, 50] starting
Looking for =:=@* ...
and then atalkad core dumps (at inet_ntoa() at 0xf777a860). Has anyone
encountered this before? (I contacted ralerche@lindy.stanford.edu and he
said that atalkad core dumped for him too; at which point he switched to
TOPS for sun). any ideas on what to try next?kre@cs.mu.oz.au (Robert Elz) (02/02/90)
In article <4362@brazos.Rice.edu>, MLMCKEE@AUDUCVAX.BITNET writes: > and then atalkad core dumps (at inet_ntoa() at 0xf777a860). Has anyone > encountered this before? Yes .. for atalkad on a sparc (or probably other risc processor) fetch multigate/atalkad.1.20.shar.Z (in binary mode, using anon ftp) from munnari.oz.au [128.250.1.21] It has zillions of unrelated changes, but will work for standard kip using a fairly standard atalkatab (a few minor syntax changes described in a README), and will work correctly on SPARCS, and other similar processors. kre
jsm@princeton.edu (John Scott McCauley Jr.) (02/04/90)
In article <4362@brazos.Rice.edu> MLMCKEE@AUDUCVAX.BITNET writes: >X-Sun-Spots-Digest: Volume 9, Issue 11, message 14 of 15 > >and then atalkad core dumps (at inet_ntoa() at 0xf777a860). Has anyone >encountered this before? (I contacted ralerche@lindy.stanford.edu and he >said that atalkad core dumped for him too; at which point he switched to >TOPS for sun). any ideas on what to try next? I gave up at this point too. Note that f7.77.a8.60 is probably a valid IP address on your net. The problem seems to be that the hostname data conventions have changed over the years and that atalkad has to be rewritten to reflect these changes. Funny thing, atalkad works fine on a Decstation -- perhaps it is using some backwards-compatible setup that SunOS lacks. I decided to run K-Star which came with our KFPS-4. It works with CAP -- be careful with Option 11 that maps Appletalk ports to UDP port numbers. It also is stand-alone so it doens't need an atalkad. Note that running without an atalkad may be a bad idea if you have a complex network. Under kip, you might be able to add some static information at the end of the config-gw.srec file so you don't need an atalkad someplace. Hope this helps, Scott jsm%ss01.pppl.gov@ccc.nmfecc.gov
richard@aiai.edinburgh.ac.uk (Richard Tobin) (03/21/90)
> atalkad core dumps (at inet_ntoa() at 0xf777a860)
I recently had a problem with inet_ntoa() - maybe it's the same one.
The argument to inet_ntoa() should be a struct in_addr, but there's some
grungy code (eg in the 4.3 timed, where I noticed it) that passes a u_long
instead. It appears that 4-byte structures are passed differently from
integers on the Sun 4, so this doesn't work.
-- Richard