Bug 21251

Summary:	NIS problem - ypbind does loop in CLNT_BROADCAST
Product:	Base System	Reporter:	mb <mb>
Component:	bin	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description mb 2000-09-13 14:40:00 UTC

Ypbind does loose the NIS domain after some time, then it tries to
retrieve it again with a broadcast network request, but this fails.

Some output of a patched ypbind with debugging information:

./ypbind
Do the broadcast
CLNT_BROADCAST
Cannot send broadcast packet: No buffer space available

and thousands of other requests ...

Because ypbind forks to do the broadcast, it generates a
huge network load. Every other host in the network has to
process the rpc requests and this generates and this eats
30-50% CPU time !

Sep 11 12:40:21 levais last message repeated 302468 times
Sep 11 12:50:23 levais last message repeated 302454 times
Sep 11 13:00:24 levais last message repeated 302707 times 

Here you see how many broadcasts ypbind does, this is very
fatal for the network !

The rpc-requests are done as I can see with tcp-dump, but
CLNT_BROADCAST() does always report an error. So something
must go wrong.

14:20:35.703958 NIS-client.2386 > NIS-server.sunrpc:  udp 136
14:20:35.713419 NIS-server.30693 > NIS-client.2291:  udp 36

A interpreted packet dump is on http://www.attic.ch/debug/ypbind.out

It seems that the response from the PRC-Server does go to the wrong
port. Is that correct ?

Has anybody seen a similar problem with ypbind(8) ?

Fix: 

Not yet known

If you need to have access to my workstation to debug the problem,
just ask me.
How-To-Repeat: Just use NIS and wait, it happens suddently. The load of the
machine will grow then so you cannot work anymore. Sometime it
happens sudenly, sometimes it works 2-3 days. At the moment I can
reproduce the problem.

Comment 1 Stefan.Schmidt 2000-11-15 20:08:28 UTC

Hi,

the same problem surfaces at our site between a 
FreeBSD 4-STABLE (from about 13th Nov 2000) box 
(NIS client) and a (SuSE) Linux server (NIS master). 

I worked around the broadcast floods by specifying *both*
flags -S and -m to ypbind (check the man page for details).
This will avoid the (possibly faulty) broadcast code in 
ypbind.c.

stefan

Comment 2 iedowse freebsd_committer

2002-07-01 00:54:01 UTC

State Changed
From-To: open->closed

Fixed in -STABLE by pmap_rmt.c revision 1.16.2.1, and the bug is 
not present in -CURRENT.