Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="US-ASCII"
MIME-Version: 1.0
Date: Sat, 10 Jun 2017 06:30:07 +0000
From: "Soren Jacobsen" <snj@netbsd.org>
Subject: CVS commit: [netbsd-8] src/external/bsd/dhcp/dist/relay
To: source-changes@NetBSD.org
Message-Id: <20170610063007.F40E2FA9F@cvs.NetBSD.org>
Sender: source-changes-owner@NetBSD.org
Precedence: bulk
Reply-To: source-changes-d@NetBSD.org
Mail-Reply-To: "Soren Jacobsen" <snj@netbsd.org>
Mail-Followup-To: source-changes-d@NetBSD.org

Module Name:	src
Committed By:	snj
Date:		Sat Jun 10 06:30:07 UTC 2017

Modified Files:
	src/external/bsd/dhcp/dist/relay [netbsd-8]: dhcrelay.c

Log Message:
Pull up following revision(s) (requested by manu in ticket #27):
	external/bsd/dhcp/dist/relay/dhcrelay.c: revision 1.7
Fix buggy dhcrelay(8) requirement to stay in foreground
This version of dhcrelay(8) needed to stay inforeground with -d flag in
order to service requests. Running inbackground turned it deaf to DHCP
requests.
This was caused by wrong kqueue(2) usage, where kevent(2) was used with
a file descriptor obtained by a kqueue(2) call done before fork(2).
kqueue(2) man page says "The queue is not inherited by a child created
with fork(2)". As a result, kevent(2) calls always got EBADF.
The fix is to reorder function calls in dhcrelay(8) main() function.
dhcp_context_create(), which causes kqueue(2) to be invoked, is
moved with its dependencies after fork(2). This matches the code layout
of dhclient(8) and dhcpd(8), which do not have the bug.
The fix was not submitted upstream since latest ISC DHCP code was
refactored and does not have the bug anymore.


To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.6.8.1 src/external/bsd/dhcp/dist/relay/dhcrelay.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.