While ypserv on FreeBSD works as slave NIS server, this ypserv incorrectly handles null key entry in a specific (buggy) NIS-map. (compared with SunOS 4 ypserv). My master NIS server runs on Sun3, SunOS 4.1.1_U1. When I insert a blank line to /etc/protocols, Sun's NIS system makes BAD protocols.bynumber map which contains entry: key="". Other slave NIS servers on Sun, handle this bad map without any problem. But FreeBSD's NIS server can not handle the map like Sun's in following case: * NIS client asks NIS server to get next entry of the bad entry (key=""). Sun returns correct entry, which is a just next of (key=""). FreeBSD returns first entry in the map. This results NIS clients to go loop! I believe that most incorrect player of this problem is Sun's NIS master server environment, but I wish that FreeBSD could treat this buggy map correctly with some proper fixes... Fix: /usr/src/gnu/usr.sbin/ypserv/server.c line 346 will be fixed.. How-To-Repeat: I do not know whether FreeBSD's NIS master server environment (Makefile, tools) will make these bad map or not, so I can not answer... Of caurse, I can repeat the problem in my environment easily :-)
State Changed From-To: open->suspended Awaiting committer
State Changed From-To: suspended->open FreeBSD's non-GPL YP seems to have a maintainer these days.
Responsible Changed From-To: freebsd-bugs->wpaul Bill, if this is no longer an issue, let me know and I'll close the PR for you.
State Changed From-To: open->closed Original submitter says it's OK to close this PR.