NetBSD Problem Report #15014

Received: (qmail 6070 invoked from network); 21 Dec 2001 02:50:34 -0000
Message-Id: <20011220185033.A59009@best.com>
Date: Thu, 20 Dec 2001 18:50:33 -0800
From: Chuck Kane <ckane@best.com>
To: gnats-bugs@gnats.netbsd.org
Subject: ypserv misidentifies requesting system in domain_nonack_2 log message
X-Send-Pr-Version: 3.95

>Number:         15014
>Category:       bin
>Synopsis:       ypserv misidentifies requesting system in domain_nonack_2 log message
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 21 02:51:00 +0000 2001
>Closed-Date:    Sat Dec 31 05:15:36 +0000 2022
>Last-Modified:  Sat Dec 31 05:15:36 +0000 2022
>Originator:     C Kane
>Release:        NetBSD 1.5.2 with NetBSD-1.5ZA kernel
>Organization:
>Environment:
		System: NetBSD 1.5ZA NetBSD 1.5ZA #5: Wed Dec 19 22:53:57 UTC 2001 root@wws008 i386


>Description:
	syslog receives the following message from ypserv:

	ypserv[508]: domain_nonack_2: request from localhost, domain mydomain, served FALSE

	This request did not come from localhost.  ypserv should be able to properly log which
	system really made the requst.  The correct hostname is logged for some other ypserv
	messages, notably "xfr_2":

	ypserv[591]: xfr_2: request from mysystem, domain mydomain, tid 1008814514, prog 1073741825, port 0, map group.byname

>How-To-Repeat:
        Start "ypserv -dl" and wait for a system on the LAN to broadcast for a YP server.

>Fix:
        None provided.
>Release-Note:
>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/15014: ypserv misidentifies requesting system in
	domain_nonack_2 log message
Date: Mon, 23 Jun 2008 06:06:49 +0000

 Unfortunately, the handling of the requesting system name in xfr_2 and
 domain_nonack_2 is, and has been, exactly the same. I suspect this
 means the request is being forwarded by portmap/rpcbind and that the
 problem is thus unfixable. (Cranking up logging in rpcbind might help,
 though.)

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 31 Dec 2022 05:15:36 +0000
State-Changed-Why:
Apparently a portmap/rpcbind interaction, unfixable. Also from 2001.
If there's anyone still listening and you still have a problem,
please file a new PR.


>Unformatted:

Home	PR Database Search