[no subject]

As I was -- and I am still -- unable to get the cube to acknowledge the
existence of ypserv.log (which would likely just contain the number 42 in a
higly succesful attempt to frustrate me further), I decided to attempt to
capture and analyze the rpc calls as they were being made.  This brought my
attention to ipfilter, which in turn made me aware of ipnat (wow, NAT --
think of the possibilities).  Unable to get ipmon to work (more on this and
other ipfilter woes in a bit), I admitted partial defeat and started to
scour the web and the OpenBSD and NetBSD mailing list archives for clues.
Well, OpenBSD pr #232 looked promising: it told of an old ULTRIX server
that was having problems that sounded similar.

Hmm, it was beginning to look like time to upgrade the IIci to OpenBSD 2.1.
Nah, it would be Too Much Trouble (I had recently been dropped from two
T1's back to 28.8, as I had quit my job with the ISP, and just couldn't
bear the thought of downloading the 2.1 release -- I'm still recovering).

Becoming more and more disheveled by each yp lookup, I decided to focus my
attention on getting ipfilter working.  Unaware of the presence of
/usr/lkm/ipl.o, and knowing that the GENERIC config file for OpenBSD/mac68k
didn't have ipfilter defined (nor LKM, I think), I  decided to compile my
own kernel, which would have the added benfit of turning the IIci into an
nfs server.  I had obtained more storage space in the form of the overly
cool, albeit flakey, NeXT optical disks, so things looked like they might
be getting better Real Soon Now.  Not so. :-(  Encountering compiliation
problems in the 2.0 kernel sources too horrid to detail in such a family
oriented list as this, I decided to upgrade to the OS and the kernel
sources to 2.1.  Imagine my delight when I saw that one of the changes in
2.1 was the addition of the -insecure flag to ypbind!  Maybe things were
going to get better after all -- the 2.1 GENERIC kernel even had ipfilter
compiled in by default.  Cool.

The OS upgrade went okay.  While digging through the IIci's filesystem to
back up all the important stuff -- just in case -- I noticed
/usr/lkm/ipl.o.  Doh!  A few bumps while untarring the tarballs -- in the
form of tar/pax coring due to invalid system calls (if I remember
correctly) while trying to set the permissions on
./{dev/scan0,etc/termios,usr/include/{varargs.h,errno.h}} -- to name a few.
But I got around it by re-untaring the files after booting into 2.1
(besides, I met my newest command line friend, pax, because of it).  I've
yet to upgrade to etc21, however, as I'm assuming that it's not critical
(please let me know if that's not the case.)  The OS upgrade took place a
few days ago.

After the upgrade was completed, the first thing I tried was using the new
-insecure flag with ypbind.  Unfortunately, ypbind (and the man pages) are
unaware of the existence of this new flag.  Hmph.  Turning my attention to
ipfilter, I discovered that it wouldn't work either.  Just to be sure that
the 2.1 kernel's ipfilter support wasn't broken, I compiled my own kernels
with support for ipfilter as an LKM and as part of the kernel.  In either
case ipnat, upon being told to add some rules to the rule list responds with

	ioctl(SIOCADNAT): invalid argument

ipfstat resonds similarly:

	ioctl(SIOCGETFS): invalid argument

Bah.  To top all that off, nfsd also refuses to work, dumping its core and
complaining of an illegal instruction.  Oh well, at least I've now learned
of tcpdump.

In sum:

<SUMMARY>

I cannot get my NEXTSTEP 2.0 yp server and my OpenBSD 2.1 yp client to talk
to each other.  The bindings are in place, ypcat and ypmatch both work, and
there is network activity during the times when yp calls should be made.
passwd lookups sort of work, but that's complicated to explain.  I suspect
some sort of incompatibility that the yp library routines silently ignore.
I have had this problem since 2.0.

ipfilter doesn't work as either an LKM or as part of the kernel.  All calls
made to ipfilter by its userland utilities seem to fail on an invalid
argument to ioctl().  This problem also occurred with 2.0.

nfsd doesn't work.  Compiled a new kernel with it enabled; however, it
refuses to work, dumping its core and complaining of an illegal
instruction.  Although this problem did not arise until after the 2.1
upgrade, I suspect it would have occured with 2.0 as well. ;-)

</SUMMARY>

Please help.  I'm all burnt out on UN*X because of this; I put in less than
an hour on my UN*X machines over the course of the last three days.
Normally I put in at least 4 a day.  And I still have to write all those
PRs! <smacks hand on forehead>  Oh well.  Thanks in advance for any help
you all may be able to provide -- I'll really appreciate it!

--------------------------------------------------------------------------------
       mailto:jmoyer_(_at_)_cortland_(_dot_)_com      |   Show your dogcow that you love it;
    http://genesis.tiac.net/jmoyer/    |     give it a can of Mountain Dew.
--------------------------------------------------------------------------------
       Geek Code Version: 3.1
       Last updated: a long time ago
       GU d--()>+ s>+: !a C++++(++)$ UB++$>++++ P>+++ !L- !E---> W++$
       N(++) o? K-? w(--)$>--- !O>++ M++(+)$ !V-- PS+(++)@ PE(--) Y+>++
       !PGP>++ t+@ !5+(-) X+ R>+* tv-(+) b+>+++ DI(++)>+++ !D--- G>++++
       e->++_(_at_)_* h--?>++! r@ y+(++)
--------------------------------------------------------------------------------