[src/netbsd-1-4]: src/usr.sbin/dhcp/server Pull up 1.6 (patchlevel 25)

[mellon <mellon%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/2c6f22e313dd
branches:  netbsd-1-4
changeset: 468159:2c6f22e313dd
user:      mellon <mellon%NetBSD.org@localhost>
date:      Fri Apr 09 20:10:51 1999 +0000

description:
Pull up 1.6 (patchlevel 25)

diffstat:

 usr.sbin/dhcp/server/dhcpd.conf.5 |  19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diffs (29 lines):

diff -r ec840acd78b1 -r 2c6f22e313dd usr.sbin/dhcp/server/dhcpd.conf.5
--- a/usr.sbin/dhcp/server/dhcpd.conf.5 Fri Apr 09 20:10:30 1999 +0000
+++ b/usr.sbin/dhcp/server/dhcpd.conf.5 Fri Apr 09 20:10:51 1999 +0000
@@ -719,6 +719,25 @@
 site, you are probably better off not trying to use this flag.
 .PP
 .B The
+.I always-reply-rfc1048
+.B statement
+.PP
+ \fBalways-reply-rfc1048\fR \fIflag\fR\fB;\fR
+.PP
+Some BOOTP clients expect RFC1048-style responses, but do not follow
+RFC1048 when sending their requests.   You can tell that a client is
+having this problem if it is not getting the options you have
+configured for it and if you see in the server log the message
+"(non-rfc1048)" printed with each BOOTREQUEST that is logged.
+.PP
+If you want to send rfc1048 options to such a client, you can set the
+.B always-reply-rfc1048
+option in that client's host declaration, and the DHCP server will
+respond with an RFC-1048-style vendor options field.   This flag can
+be set in any scope, and will affect all clients covered by that
+scope.
+.PP
+.B The
 .I server-identifier
 .B statement
 .PP