matt@oddjob.UChicago.EDU (Schizophrenic Solipsist) (06/29/87)
Every so often I notice that some process on my machine has
sent a UDP packet to port 111 (sunrpc) at an address which
is this machine's address byte-swapped. I notice because I
see a destination unreachable message come bac from the out-
side world.
Has anyone else seen this problem? Do you know which program
is the culprit in 4.3+NFS (with YP running)?
________________________________________________________
Matt University matt@oddjob.uchicago.edu
Crawford of Chicago {astrovax,ihnp4}!oddjob!mattglenn@XN.LL.MIT.EDU (Glenn Adams) (06/29/87)
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