🚀 go-pugleaf

In article <30342@bu-cs.BU.EDU> eap@bu-it.bu.edu (Eric Pearce) writes:
>In article <11553@udenva.cair.du.edu> mbrookov@udenva.cair.du.edu (Matthew B. Brookover) says:
>>4) Rup, rusers, and rwall do not work correctly.  rup and rusers is
>>fine between the 2 RTs, but the output from rstatd on the rt is garbage
>>when read by rup on a VAX 11/750's running BSD 4.3 Unix from Mt Xinu.
>>Rup on the RT does net even see the Vax on the net.  Rwall prints the
>>message 3 times to the users on the specified host, and then says that
>>the host, (including the host that rwall was ran form) did not get the
>>message!
>
>  All of these worked right out of the box for me.  Are you sure you
>  ifconfig'd the interface correctly?  We have 4 RT's sharing a
>  subnet with Sun3's, Sun4's and Sun386i's running 4.0 and an SGI IRIS
>  4D. They all recognize the rwho/ruptime info correctly between each other.

Rwho and ruptime are not the same as rusers and rup.  Rusers and rup use
Sun's RPC routines.  I've actually found rusers to work just fine, but
rup (or any other program that uses rstat(3) ) definitely has problems.

The situation: rstat() works fine if the local and remote machines are
RTs, but if the remote machine is a Sun and the local machine is an RT,
rstat() complains that it got unusable information from the remote
machine.  In the reverse instance, the Sun will accept the data from
the RT, but it's obviously bogus.  For example, here's the output from
"rsh tim rup tim"  (tim being an RT) -- have an RT use rstat() to query
itself:

         tim    up 30 days, 22:30,    load average: 0.08, 0.02, 0.00

Okay, no problem.  In fact, any RT querying any other RT has no
problems.  Now let's just do a plain "rup tim" -- that is, have the Sun
I'm logged into use rstat() to query an RT:

         tim    up 7026 days, 18:23,    load average: 6.57, 1.88, 0.00

Not *quite* right...

I've mentioned this in a previous posting, which got no responses, both
here and on comp.sys.next, as it turns out that NeXTs exhibit identical
behavior -- RTs and NeXTs return valid results amongst themselves in any
combination, but any RT <--> Sun or NeXT <--> Sun interaction does not
work.

I've taken a cursory glance at both the RT code and the Sun RPC source,
and they appear to be nigh-on to identical.  Does anyone have any
clues?
-- 
Larry Wake, CSUN Computer Center		lkw@csun.edu
Northridge, CA 91330         			csun!lkw
"And every one of them words rang true..." -- R. Zimmerman