head	1.6;
access;
symbols
	RELENG_8_4:1.6.0.2
	RELENG_9_1_0_RELEASE:1.5.62.1.4.2
	RELENG_9_1:1.5.62.1.0.4
	RELENG_9_1_BP:1.5.62.1
	RELENG_8_3_0_RELEASE:1.5.56.1.8.1
	RELENG_8_3:1.5.56.1.0.8
	RELENG_8_3_BP:1.5.56.1
	RELENG_9_0_0_RELEASE:1.5.62.1.2.1
	RELENG_9_0:1.5.62.1.0.2
	RELENG_9_0_BP:1.5.62.1
	RELENG_9:1.5.0.62
	RELENG_9_BP:1.5
	RELENG_7_4_0_RELEASE:1.5.60.1
	RELENG_8_2_0_RELEASE:1.5.56.1.6.1
	RELENG_7_4:1.5.0.60
	RELENG_7_4_BP:1.5
	RELENG_8_2:1.5.56.1.0.6
	RELENG_8_2_BP:1.5.56.1
	RELENG_8_1_0_RELEASE:1.5.56.1.4.1
	RELENG_8_1:1.5.56.1.0.4
	RELENG_8_1_BP:1.5.56.1
	RELENG_7_3_0_RELEASE:1.5.58.1
	RELENG_7_3:1.5.0.58
	RELENG_7_3_BP:1.5
	RELENG_8_0_0_RELEASE:1.5.56.1.2.1
	RELENG_8_0:1.5.56.1.0.2
	RELENG_8_0_BP:1.5.56.1
	RELENG_8:1.5.0.56
	RELENG_8_BP:1.5
	RELENG_7_2_0_RELEASE:1.5.54.1
	RELENG_7_2:1.5.0.54
	RELENG_7_2_BP:1.5
	RELENG_7_1_0_RELEASE:1.5.52.1
	RELENG_6_4_0_RELEASE:1.5.50.1
	RELENG_7_1:1.5.0.52
	RELENG_7_1_BP:1.5
	RELENG_6_4:1.5.0.50
	RELENG_6_4_BP:1.5
	RELENG_7_0_0_RELEASE:1.5
	RELENG_6_3_0_RELEASE:1.5
	RELENG_7_0:1.5.0.48
	RELENG_7_0_BP:1.5
	RELENG_6_3:1.5.0.46
	RELENG_6_3_BP:1.5
	RELENG_7:1.5.0.44
	RELENG_7_BP:1.5
	RELENG_6_2_0_RELEASE:1.5
	RELENG_6_2:1.5.0.42
	RELENG_6_2_BP:1.5
	RELENG_5_5_0_RELEASE:1.5
	RELENG_5_5:1.5.0.40
	RELENG_5_5_BP:1.5
	RELENG_6_1_0_RELEASE:1.5
	RELENG_6_1:1.5.0.38
	RELENG_6_1_BP:1.5
	RELENG_6_0_0_RELEASE:1.5
	RELENG_6_0:1.5.0.36
	RELENG_6_0_BP:1.5
	RELENG_6:1.5.0.34
	RELENG_6_BP:1.5
	RELENG_5_4_0_RELEASE:1.5
	RELENG_5_4:1.5.0.32
	RELENG_5_4_BP:1.5
	RELENG_4_11_0_RELEASE:1.5
	RELENG_4_11:1.5.0.30
	RELENG_4_11_BP:1.5
	RELENG_5_3_0_RELEASE:1.5
	RELENG_5_3:1.5.0.28
	RELENG_5_3_BP:1.5
	RELENG_5:1.5.0.26
	RELENG_5_BP:1.5
	RELENG_4_10_0_RELEASE:1.5
	RELENG_4_10:1.5.0.24
	RELENG_4_10_BP:1.5
	RELENG_5_2_1_RELEASE:1.5
	RELENG_5_2_0_RELEASE:1.5
	RELENG_5_2:1.5.0.22
	RELENG_5_2_BP:1.5
	RELENG_4_9_0_RELEASE:1.5
	RELENG_4_9:1.5.0.20
	RELENG_4_9_BP:1.5
	RELENG_5_1_0_RELEASE:1.5
	RELENG_5_1:1.5.0.18
	RELENG_5_1_BP:1.5
	RELENG_4_8_0_RELEASE:1.5
	RELENG_4_8:1.5.0.16
	RELENG_4_8_BP:1.5
	RELENG_5_0_0_RELEASE:1.5
	RELENG_5_0:1.5.0.14
	RELENG_5_0_BP:1.5
	RELENG_4_7_0_RELEASE:1.5
	RELENG_4_7:1.5.0.12
	RELENG_4_7_BP:1.5
	RELENG_4_6_2_RELEASE:1.5
	RELENG_4_6_1_RELEASE:1.5
	RELENG_4_6_0_RELEASE:1.5
	RELENG_4_6:1.5.0.10
	RELENG_4_6_BP:1.5
	RELENG_4_5_0_RELEASE:1.5
	RELENG_4_5:1.5.0.8
	RELENG_4_5_BP:1.5
	RELENG_4_4_0_RELEASE:1.5
	RELENG_4_4:1.5.0.6
	RELENG_4_4_BP:1.5
	RELENG_4_3_0_RELEASE:1.5
	RELENG_4_3:1.5.0.4
	RELENG_4_3_BP:1.5
	RELENG_4_2_0_RELEASE:1.5
	RELENG_4_1_1_RELEASE:1.5
	PRE_SMPNG:1.5
	RELENG_4_1_0_RELEASE:1.5
	RELENG_3_5_0_RELEASE:1.4.2.1
	RELENG_4_0_0_RELEASE:1.5
	RELENG_4:1.5.0.2
	RELENG_4_BP:1.5
	RELENG_3_4_0_RELEASE:1.4.2.1
	RELENG_3_3_0_RELEASE:1.4.2.1
	RELENG_3_2_PAO:1.4.0.4
	RELENG_3_2_PAO_BP:1.4
	RELENG_3_2_0_RELEASE:1.4
	RELENG_3_1_0_RELEASE:1.4
	RELENG_3:1.4.0.2
	RELENG_3_BP:1.4
	RELENG_2_2_8_RELEASE:1.2
	RELENG_3_0_0_RELEASE:1.4
	RELENG_2_2_7_RELEASE:1.2
	RELENG_2_2_6_RELEASE:1.2
	RELENG_2_2_5_RELEASE:1.2
	RELENG_2_2_2_RELEASE:1.2
	RELENG_2_2_1_RELEASE:1.2
	RELENG_2_2_0_RELEASE:1.2
	RELENG_2_1_7_RELEASE:1.1.1.1
	RELENG_2_1_6_1_RELEASE:1.1.1.1
	RELENG_2_1_6_RELEASE:1.1.1.1
	RELENG_2_2:1.2.0.2
	RELENG_2_2_BP:1.2
	RELENG_2_1_5_RELEASE:1.1.1.1
	v2_4_3:1.1.1.2
	MC:1.1.1
	RELENG_2_1_0_RELEASE:1.1.1.1
	RELENG_2_1_0:1.1.1.1.0.6
	RELENG_2_1_0_BP:1.1.1.1
	RELENG_2_0_5_RELEASE:1.1.1.1
	RELENG_2_0_5:1.1.1.1.0.4
	RELENG_2_0_5_BP:1.1.1.1
	RELENG_2_0_5_ALPHA:1.1.1.1
	RELEASE_2_0:1.1.1.1
	BETA_2_0:1.1.1.1
	ALPHA_2_0:1.1.1.1.0.2
	BETA1_0:1.1.1.1
	NETBSD:1.1.1;
locks; strict;
comment	@# @;


1.6
date	2012.11.17.01.50.09;	author svnexp;	state Exp;
branches
	1.6.2.1;
next	1.5;

1.5
date	99.08.28.00.09.15;	author peter;	state Exp;
branches
	1.5.2.1
	1.5.34.1
	1.5.44.1
	1.5.50.1
	1.5.52.1
	1.5.54.1
	1.5.56.1
	1.5.58.1
	1.5.60.1
	1.5.62.1;
next	1.4;

1.4
date	97.02.22.14.21.01;	author peter;	state Exp;
branches
	1.4.2.1;
next	1.3;

1.3
date	97.01.14.06.18.24;	author jkh;	state Exp;
branches;
next	1.2;

1.2
date	96.09.22.21.51.52;	author wosch;	state Exp;
branches
	1.2.2.1;
next	1.1;

1.1
date	94.09.30.05.45.03;	author pst;	state Exp;
branches
	1.1.1.1;
next	;

1.6.2.1
date	2012.11.17.01.50.09;	author svnexp;	state dead;
branches;
next	1.6.2.2;

1.6.2.2
date	2013.03.28.13.03.25;	author svnexp;	state Exp;
branches;
next	;

1.5.2.1
date	2012.11.17.07.24.09;	author svnexp;	state Exp;
branches;
next	;

1.5.34.1
date	2012.11.17.07.40.52;	author svnexp;	state Exp;
branches;
next	;

1.5.44.1
date	2012.11.17.08.03.15;	author svnexp;	state Exp;
branches;
next	;

1.5.50.1
date	2008.10.02.02.57.24;	author kensmith;	state Exp;
branches;
next	;

1.5.52.1
date	2008.11.25.02.59.29;	author kensmith;	state Exp;
branches;
next	;

1.5.54.1
date	2009.04.15.03.14.26;	author kensmith;	state Exp;
branches;
next	;

1.5.56.1
date	2009.08.03.08.13.06;	author kensmith;	state Exp;
branches
	1.5.56.1.2.1
	1.5.56.1.4.1
	1.5.56.1.6.1
	1.5.56.1.8.1;
next	1.5.56.2;

1.5.56.2
date	2012.11.17.10.36.12;	author svnexp;	state Exp;
branches;
next	;

1.5.56.1.2.1
date	2009.10.25.01.10.29;	author kensmith;	state Exp;
branches;
next	;

1.5.56.1.4.1
date	2010.06.14.02.09.06;	author kensmith;	state Exp;
branches;
next	;

1.5.56.1.6.1
date	2010.12.21.17.09.25;	author kensmith;	state Exp;
branches;
next	;

1.5.56.1.8.1
date	2012.03.03.06.15.13;	author kensmith;	state Exp;
branches;
next	1.5.56.1.8.2;

1.5.56.1.8.2
date	2012.11.17.08.24.53;	author svnexp;	state Exp;
branches;
next	;

1.5.58.1
date	2010.02.10.00.26.20;	author kensmith;	state Exp;
branches;
next	;

1.5.60.1
date	2010.12.21.17.10.29;	author kensmith;	state Exp;
branches;
next	1.5.60.2;

1.5.60.2
date	2012.11.17.08.16.52;	author svnexp;	state Exp;
branches;
next	;

1.5.62.1
date	2011.09.23.00.51.37;	author kensmith;	state Exp;
branches
	1.5.62.1.2.1
	1.5.62.1.4.1;
next	1.5.62.2;

1.5.62.2
date	2012.11.17.11.36.28;	author svnexp;	state Exp;
branches;
next	;

1.5.62.1.2.1
date	2011.11.11.04.20.22;	author kensmith;	state Exp;
branches;
next	1.5.62.1.2.2;

1.5.62.1.2.2
date	2012.11.17.08.36.28;	author svnexp;	state Exp;
branches;
next	;

1.5.62.1.4.1
date	2012.08.05.23.54.33;	author kensmith;	state Exp;
branches;
next	1.5.62.1.4.2;

1.5.62.1.4.2
date	2012.11.17.08.47.17;	author svnexp;	state Exp;
branches;
next	;

1.4.2.1
date	99.08.29.15.02.46;	author peter;	state Exp;
branches;
next	;

1.2.2.1
date	99.09.05.11.20.10;	author peter;	state Exp;
branches;
next	;

1.1.1.1
date	94.09.30.05.45.04;	author pst;	state Exp;
branches;
next	1.1.1.2;

1.1.1.2
date	96.01.23.01.33.53;	author pst;	state Exp;
branches;
next	;


desc
@@


1.6
log
@Switching exporter and resync
@
text
@# $FreeBSD: head/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $

Common problems and ways to work around them:

Bootpd complains: "bind: Address already in use" and fails to start.
	You are already running something that has bound the
	BOOTP listening port number.  Check /etc/inetd.conf or
	the equivalent for a bootp line (or in startup files).

Bootpd complains that it "can not get IP addr for HOSTNAME"

	If the entry is a "dummy" (not a real host) used only for
	reference by other entries, put '.' in front of the name.

	If the entry is for a real client and the IP address for
	the client can not be found using gethostbyname(), specify
	the IP address for the client using numeric form.

Bootpd takes a long time to finish parsing the bootptab file:

	Excessive startup time is usually caused by waiting for
	timeouts on failed DNS lookup operations.  If this is the
	problem, find the client names for which DNS lookup fails
	and change the bootptab to specify the IP addresses for
	those clients using numeric form.

	When bootptab entries do not specify an ip address, bootpd
	attempts to lookup the tagname as a host name to find the
	IP address.  To suppress this default action, either make
	the entry a "dummy" or specify its IP numeric address.

	If your DNS lookups work but are just slow, consider either
	running bootpd on the same machine as the DNS server or
	running a caching DNS server on the host running bootpd.

My huge bootptab file causes startup time to be so long that clients
give up waiting for a reply.

	Truly huge bootptab files make "inetd" mode impractical.
	Start bootpd in "standalone" mode when the server boots.

	Another possibility is to run one bootpd on each network
	segment so each one can have a smaller bootptab.  Only one
	instance of bootpd may run on one server, so you would need
	to use a different server for each network segment.

My bootp clients are given responses with a boot file name that is
not a fully specified path.

	Make sure the TFTP directory or home directory tags are set:
	:td=/tftpboot:	(or)
	:hd=/usr/boot:	(for example)

My PC clients running Sun's PC-NFS Pro v1.1 fail to receive
acceptable responses from the bootp server.

	These clients send a request with the DHCP "message length"
	option and the (new) BOOTP "broadcast flag" both set.
	The bootp server (on SunOS) will send a fragmented reply
	unless you override the length with :ms=1024: (or less).
	The "broadcast flag" is not yet supported, but there is
	a simple work-around, just add :ra=255.255.255.255:
	for any clients that need their reply broadcasted.
	You may need to use a differnet broadcast address.
	(Thanks to Ivan Auger <ivan.auger@@wadsworth.org>)

@


1.6.2.1
log
@file Problems was added on branch RELENG_8_4 on 2013-03-28 13:03:25 +0000
@
text
@d1 66
@


1.6.2.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/248810
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@a0 66
# $FreeBSD: releng/8.4/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $

Common problems and ways to work around them:

Bootpd complains: "bind: Address already in use" and fails to start.
	You are already running something that has bound the
	BOOTP listening port number.  Check /etc/inetd.conf or
	the equivalent for a bootp line (or in startup files).

Bootpd complains that it "can not get IP addr for HOSTNAME"

	If the entry is a "dummy" (not a real host) used only for
	reference by other entries, put '.' in front of the name.

	If the entry is for a real client and the IP address for
	the client can not be found using gethostbyname(), specify
	the IP address for the client using numeric form.

Bootpd takes a long time to finish parsing the bootptab file:

	Excessive startup time is usually caused by waiting for
	timeouts on failed DNS lookup operations.  If this is the
	problem, find the client names for which DNS lookup fails
	and change the bootptab to specify the IP addresses for
	those clients using numeric form.

	When bootptab entries do not specify an ip address, bootpd
	attempts to lookup the tagname as a host name to find the
	IP address.  To suppress this default action, either make
	the entry a "dummy" or specify its IP numeric address.

	If your DNS lookups work but are just slow, consider either
	running bootpd on the same machine as the DNS server or
	running a caching DNS server on the host running bootpd.

My huge bootptab file causes startup time to be so long that clients
give up waiting for a reply.

	Truly huge bootptab files make "inetd" mode impractical.
	Start bootpd in "standalone" mode when the server boots.

	Another possibility is to run one bootpd on each network
	segment so each one can have a smaller bootptab.  Only one
	instance of bootpd may run on one server, so you would need
	to use a different server for each network segment.

My bootp clients are given responses with a boot file name that is
not a fully specified path.

	Make sure the TFTP directory or home directory tags are set:
	:td=/tftpboot:	(or)
	:hd=/usr/boot:	(for example)

My PC clients running Sun's PC-NFS Pro v1.1 fail to receive
acceptable responses from the bootp server.

	These clients send a request with the DHCP "message length"
	option and the (new) BOOTP "broadcast flag" both set.
	The bootp server (on SunOS) will send a fragmented reply
	unless you override the length with :ms=1024: (or less).
	The "broadcast flag" is not yet supported, but there is
	a simple work-around, just add :ra=255.255.255.255:
	for any clients that need their reply broadcasted.
	You may need to use a differnet broadcast address.
	(Thanks to Ivan Auger <ivan.auger@@wadsworth.org>)

@


1.5
log
@$Id$ -> $FreeBSD$
@
text
@d1 1
a1 1
# $FreeBSD$
@


1.5.44.1
log
@Switch importer
@
text
@d1 1
a1 1
# $FreeBSD: stable/7/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $
@


1.5.34.1
log
@Switch importer
@
text
@d1 1
a1 1
# $FreeBSD: stable/6/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $
@


1.5.2.1
log
@Switch importer
@
text
@d1 1
a1 1
# $FreeBSD: stable/4/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $
@


1.5.62.1
log
@SVN rev 225736 on 2011-09-23 00:51:37Z by kensmith

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by:	re (implicit)
@
text
@@


1.5.62.2
log
@## SVN ##
## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/ 242902
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ## r242902 | dteske | 2012-11-11 23:29:45 +0000 (Sun, 11 Nov 2012) | 10 lines
## SVN ##
## SVN ## Fix a regression introduced by SVN r211417 that saw the breakage of a feature
## SVN ## documented in usr.sbin/sysinstall/help/shortcuts.hlp (reproduced below):
## SVN ##
## SVN ## If /usr/sbin/sysinstall is linked to another filename, say
## SVN ## `/usr/local/bin/configPackages', then the basename will be used
## SVN ## as an implicit command name.
## SVN ##
## SVN ## Reviewed by:	adrian (co-mentor)
## SVN ## Approved by:	adrian (co-mentor)
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ##
@
text
@d1 1
a1 1
# $FreeBSD: stable/9/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $
@


1.5.62.1.4.1
log
@SVN rev 239080 on 2012-08-05 23:54:33Z by kensmith

Copy stable/9 to releng/9.1 as part of the 9.1-RELEASE release process.

Approved by:	re (implicit)
@
text
@@


1.5.62.1.4.2
log
@Switch importer
@
text
@d1 1
a1 1
# $FreeBSD: releng/9.1/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $
@


1.5.62.1.2.1
log
@SVN rev 227445 on 2011-11-11 04:20:22Z by kensmith

Copy stable/9 to releng/9.0 as part of the FreeBSD 9.0-RELEASE release
cycle.

Approved by:	re (implicit)
@
text
@@


1.5.62.1.2.2
log
@Switch importer
@
text
@d1 1
a1 1
# $FreeBSD: releng/9.0/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $
@


1.5.60.1
log
@SVN rev 216618 on 2010-12-21 17:10:29Z by kensmith

Copy stable/7 to releng/7.4 in preparation for FreeBSD-7.4 release.

Approved by:	re (implicit)
@
text
@@


1.5.60.2
log
@Switch importer
@
text
@d1 1
a1 1
# $FreeBSD: releng/7.4/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $
@


1.5.58.1
log
@SVN rev 203736 on 2010-02-10 00:26:20Z by kensmith

Copy stable/7 to releng/7.3 as part of the 7.3-RELEASE process.

Approved by:	re (implicit)
@
text
@@


1.5.56.1
log
@SVN rev 196045 on 2009-08-03 08:13:06Z by kensmith

Copy head to stable/8 as part of 8.0 Release cycle.

Approved by:	re (Implicit)
@
text
@@


1.5.56.2
log
@## SVN ##
## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/ 242909
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ## r242909 | dim | 2012-11-12 07:47:19 +0000 (Mon, 12 Nov 2012) | 20 lines
## SVN ##
## SVN ## MFC r242625:
## SVN ##
## SVN ## Remove duplicate const specifiers in many drivers (I hope I got all of
## SVN ## them, please let me know if not).  Most of these are of the form:
## SVN ##
## SVN ## static const struct bzzt_type {
## SVN ##       [...list of members...]
## SVN ## } const bzzt_devs[] = {
## SVN ##       [...list of initializers...]
## SVN ## };
## SVN ##
## SVN ## The second const is unnecessary, as arrays cannot be modified anyway,
## SVN ## and if the elements are const, the whole thing is const automatically
## SVN ## (e.g. it is placed in .rodata).
## SVN ##
## SVN ## I have verified this does not change the binary output of a full kernel
## SVN ## build (except for build timestamps embedded in the object files).
## SVN ##
## SVN ## Reviewed by:	yongari, marius
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ##
@
text
@d1 1
a1 1
# $FreeBSD: stable/8/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $
@


1.5.56.1.8.1
log
@SVN rev 232438 on 2012-03-03 06:15:13Z by kensmith

Copy stable/8 to releng/8.3 as part of 8.3-RELEASE release cycle.

Approved by:	re (implicit)
@
text
@@


1.5.56.1.8.2
log
@Switch importer
@
text
@d1 1
a1 1
# $FreeBSD: releng/8.3/libexec/bootpd/Problems 50476 1999-08-28 00:22:10Z peter $
@


1.5.56.1.6.1
log
@SVN rev 216617 on 2010-12-21 17:09:25Z by kensmith

Copy stable/8 to releng/8.2 in preparation for FreeBSD-8.2 release.

Approved by:	re (implicit)
@
text
@@


1.5.56.1.4.1
log
@SVN rev 209145 on 2010-06-14 02:09:06Z by kensmith

Copy stable/8 to releng/8.1 in preparation for 8.1-RC1.

Approved by:	re (implicit)
@
text
@@


1.5.56.1.2.1
log
@SVN rev 198460 on 2009-10-25 01:10:29Z by kensmith

Copy stable/8 to releng/8.0 as part of 8.0-RELEASE release procedure.

Approved by:	re (implicit)
@
text
@@


1.5.54.1
log
@SVN rev 191087 on 2009-04-15 03:14:26Z by kensmith

Create releng/7.2 from stable/7 in preparation for 7.2-RELEASE.

Approved by:	re (implicit)
@
text
@@


1.5.52.1
log
@SVN rev 185281 on 2008-11-25 02:59:29Z by kensmith

Create releng/7.1 in preparation for moving into RC phase of 7.1 release
cycle.

Approved by:	re (implicit)
@
text
@@


1.5.50.1
log
@SVN rev 183531 on 2008-10-02 02:57:24Z by kensmith

Create releng/6.4 from stable/6 in preparation for 6.4-RC1.

Approved by:	re (implicit)
@
text
@@


1.4
log
@Revert $FreeBSD$ to $Id$
@
text
@d1 1
a1 1
#	$Id$
@


1.4.2.1
log
@$Id$ -> $FreeBSD$
@
text
@d1 1
a1 1
# $FreeBSD$
@


1.3
log
@Make the long-awaited change from $Id$ to $FreeBSD$

This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.

Boy, I'm glad we're not using sup anymore.  This update would have been
insane otherwise.
@
text
@d1 1
a1 1
#	$FreeBSD$
@


1.2
log
@add forgotten $Id$
@
text
@d1 1
a1 1
#	$Id$
@


1.2.2.1
log
@$Id$ -> $FreeBSD$
@
text
@d1 1
a1 1
# $FreeBSD$
@


1.1
log
@Initial revision
@
text
@d1 1
d5 5
d53 13
@


1.1.1.1
log
@Rearrange bootpd
@
text
@@


1.1.1.2
log
@Import bootpd-2.4.3 from ftp.mc.com
@
text
@a3 5
Bootpd complains: "bind: Address already in use" and fails to start.
	You are already running something that has bound the
	BOOTP listening port number.  Check /etc/inetd.conf or
	the equivalent for a bootp line (or in startup files).

a46 13

My PC clients running Sun's PC-NFS Pro v1.1 fail to receive
acceptable responses from the bootp server.

	These clients send a request with the DHCP "message length"
	option and the (new) BOOTP "broadcast flag" both set.
	The bootp server (on SunOS) will send a fragmented reply
	unless you override the length with :ms=1024: (or less).
	The "broadcast flag" is not yet supported, but there is
	a simple work-around, just add :ra=255.255.255.255:
	for any clients that need their reply broadcasted.
	You may need to use a differnet broadcast address.
	(Thanks to Ivan Auger <ivan.auger@@wadsworth.org>)
@
