Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!glenn
From: glenn@XN.LL.MIT.EDU (Glenn Adams)
Newsgroups: comp.bugs.4bsd
Subject: Re: Bad call to portmap in 4.3+NFS
Message-ID: <583@xn.LL.MIT.EDU>
Date: Mon, 29-Jun-87 13:40:57 EDT
Article-I.D.: xn.583
Posted: Mon Jun 29 13:40:57 1987
Date-Received: Tue, 30-Jun-87 06:23:00 EDT
References: <3858@oddjob.UChicago.EDU>
Organization: MIT Lincoln Laboratory, Lexington, MA
Lines: 25

You will find the culprit in /usr/src/lib/libc/yp/ypxdr.c.  Change
xdr_yp_inaddr() to use xdr_opaque() instead of xdr_u_long() and
change xdr_yp_binding() to use xdr_opaque() instead of xdr_u_short().
You will need to supply the appropriate length parameters to xdr_opaque().

After you have recompiled the C library, relink everything that
uses YP.  If you don't know what uses YP, then relink everything.
I strongly recommend the latter since there are 40 or so programs that
use YP, either directly or, as in most cases, indirectly.

The problem here is in the way that the Internet address and port of
a YP server are being returned from ypbind.  Early SUN implementations
and MtXinu derivations assumed host byte order for both address and port.
This was incorrect as they are supplied in network byte order as specified
in the YPBIND spec.  In order to maintain network byte order, it is 
necessary to encode this data as an opaque object which maintains byte
ordering between hosts (xdr_bytes() could have been used also).  Note
that due to the native SUN byte order, that the encoding with either
xdr_opaque() or xdr_u_long() results in the same byte order on the wire.
It is on the decoding end where things get confused.  If it is decoded
on a VAX as xdr_u_long() then it gets byte swapped, whereas using
xdr_opaque() leaves it in the correct order.

Glenn Adams
MIT Lincoln
to be falth