From owner-freebsd-current Sun Feb 7 09:40:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA19784 for freebsd-current-outgoing; Sun, 7 Feb 1999 09:40:58 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA19768 for ; Sun, 7 Feb 1999 09:40:53 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id MAA15905; Sun, 7 Feb 1999 12:47:46 -0500 From: Bill Paul Message-Id: <199902071747.MAA15905@skynet.ctr.columbia.edu> Subject: Re: NIS woes To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Sun, 7 Feb 1999 12:47:45 -0500 (EST) Cc: current@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Feb 7, 99 06:26:02 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 writes: > > Of all the gin joints in all the towns in all the world, Dag-Erling > > Smorgrav had to walk into mine and say: > > > Luna, however, seems absolutely allergic to NIS. Everything is > > > configured correctly as far as I can see > > [chop] > > > > Sure, that's what they all say. The N in NIS stands for Network. This > > means that you should be concentrating your diagnostic efforts on the > > network. Are you using an insane amount of IP aliases? Did you try > > to run tcpdump on the interface that connects the two machines together? > > From both sides? Are your netmasks correct? > > > > Did you check to see if 'domainname' returns the correct information? > > 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. > Network problems would not explain why rpcinfo, ypset and ypwhich > hang. It would if they're trying to do an NIS lookup as part of their operation. Rpcinfo could be trying to read from the rpc.byname map. The others may be doing similar things. > Tcpdump, tcpdump and more tcpdump. > > Useless on PLIP links. No it isn't. -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