Date: Sun, 7 Feb 1999 17:57:23 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Cc: current@FreeBSD.ORG Subject: Re: NIS woes Message-ID: <199902072257.RAA16298@skynet.ctr.columbia.edu> In-Reply-To: <xzpsocit7ca.fsf@flood.ping.uio.no> from "Dag-Erling Smorgrav" at Feb 7, 99 07:08:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Dag-Erling Smorgrav had to walk into mine and say: > Bill Paul <wpaul@skynet.ctr.columbia.edu> writes: > > Of all the gin joints in all the towns in all the world, Dag-Erling > > Smorgrav had to walk into mine and say: > > > Yes to most of the above. Tcpdump does not work on PLIP links, and I > > > do not use IP aliases at all. > > Explain to me how you concluded that tcpdump doesn't work on point to > > point links, or PLIP in particular. Do a 'grep bpf /sys/dev/ppbus/if_plip.c' > > and look at the references to bpf in the output. At the very least, > > it's supposed to work; if it doesn't, then it's a bug. > > It doesn't. Try it out for yourself. It is a bug, and I know > (conceptually) how to fix it, but I really can't be buggered to track Er... I think you mean 'bothered.' > it down and fix it right now. In any case, I am convinced that tcpdump > will not reveal anything of interest. Well I'm not. Being able to see if the NIS client is actually communicating with the server by looking at the actual traffic on the interface would be incredible useful as far as I'm concerned. That aside, I'm very disappointed to hear that this bug is there with a release only a week away. > The netwok connection *works*. > Luna has four NFS file systems mounted from niobe, and I admin luna > using ssh from niobe. Well, lacking any other diagnostic information, I can only offer a couple of shots in the dark: - Is the loopback interface configured correctly? - Broadcasts don't work across point to point links (at least, I don't think so) which makes it hard for ypbind to work properly. I modified ypbind a while back to use a 'multiple unicast' mode instead of broadcast to try to make ypbind work in such an environment, but it has the disadvantage of requiring the client to know the IP addresses of all the NIS servers on the network ahead of time (which defeats the purpose of ypbind, which is to dynamically locate servers). You're supposed to be able to use ypset to get things working initially; I don't know why it would fail, but you can try this: # ypbind -m -S <IP address of niobe> Before you do this, run ypserv in debug mode on niobe and watch for any requests from luna; you should see at least one call to the ypproc_domain or ypproc_domain_nonack procedures. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902072257.RAA16298>