.\" Copyright (c) 2000-2021, The Trustees of Princeton University.  All rights reserved.
.\"
.TH DHCP_PROBE 8 "Jan 18 2021" "Princeton Univ."
.SH NAME
dhcp_probe \- locate DCHP and BootP servers on a directly-attached network
.SH SYNOPSIS
dhcp_probe
[
.B \-c
.I config_file
]
[
.B \-d
.I debuglevel
]
[
.B \-f
]
[
.B \-h
]
[
.B \-l
.I log_file
]
[
.B \-o
.I capture_file
]
[
.B \-p
.I pid_file
]
[
.B \-Q
.I vlan_id
]
[
.B \-s
.I capture_bufsize
]
[
.B \-T
]
[
.B \-v
]
[
.B \-w
.I cwd
]
.I interface_name
.br
.SH DESCRIPTION
dhcp_probe
attempts to discover DHCP and BootP servers on a directly-attached Ethernet network.
A network administrator can use this tool to locate unauthorized DHCP and BootP servers.
.PP
The program must be run with root privilege.
.PP
The program periodically broadcasts a number of DHCP and BootP request packets out a single
physical interface.
Several different kinds of request packets are sent, as a DHCP or BootP
server may only respond to certain requests, depending on the server's
configuration.
Essentially, 
dhcp_probe
mimics a BootP or DHCP client in a variety of
possible states, attempting to provoke responses from servers.
.PP
After sending each request packet, 
dhcp_probe
listens for responses.
After filtering out responses that do not appear to be in response to the probe,
and responses from known DHCP and BootP servers (identified by their IP source addresses
and optionally by their Ethernet source addresses), 
it logs any responses from unknown servers.
.PP
Optionally, responses from unknown servers may also be written to
a packet capture file.
.PP
Optionally, an external program may be called each time a response
from an unknown server is received.
.PP
dhcp_probe
may not be able to
locate all DHCP and BootP servers; see
LIMITATIONS below.
.PP
As DHCP broadcasts do not ordinarily cross IP routers,
dhcp_probe
will locate only servers that are attached to the same
physical network as the interface specified on the command line.
Although BootP Relay Agents running on this network may help
the broadcasts cross IP routers, these agents typically are configured to
convert the broadcasts to unicasts directed to only the well-known
DHCP or BootP servers located on other physical networks.
As a result, BootP Relay Agents will allow your the servers to
receive the requests issued by 
dhcp_probe,
but will not cause
remote unknown servers to hear these requests.
Therefore, if you have multiple physical networks, you may wish
to run 
dhcp_probe
on each of these networks to discover
unknown DHCP and BootP servers on each of them.
.PP
dhcp_probe
functions on a single Ethernet interface specified on the
command line; it does not listen on multiple interfaces.
However, if the host has multiple physical or logical interfaces, you may run an 
instance of 
dhcp_probe 
on each physical or logical interface.
If your physical interface supports 802.1Q, you can use that to
create a logical (untagged) interface on each VLAN, then run an instance
of dhcp_probe on each logical (untagged) interface.
.PP
dhcp_probe is intended for use by a network administrator.  
Before running dhcp_probe on any network other than one for which you are responsible,
contact that network's administrator to learn if it is acceptable for you
to run this software on that network.    
Running this software on a network where you don't have permission
to do so may violate that network's acceptable use policy.
.SH AVAILABILITY
.PP
dhcp_probe
is a product of the Network Systems Group at
Princeton University's Office of 
Information Technology,
and is available from
https://www.net.princeton.edu/software/dhcp_probe/
.PP
Presently the product builds and runs on Solaris 10 on SPARC with gcc.
The program relies on the
.BR pcap (3)
and
.BR libnet (3)
libraries.
.SH OPTIONS
.TP
.IB \-c \ config_file
Specifies the configuration file.
If not specified, this defaults to
.BR /etc/dhcp_probe.cf .
The configuration file is read at startup, and is re-read
whenever a SIGHUP is received.
See
.BR dhcp_probe.cf (5).
.TP
.BI \-d \ debuglevel
Sets the
.I debuglevel
variable that controls the amount of debugging messages generated.
If not specified, this defaults to 0 (no debugging).
For a summary of the types of messages produced at each
debug level, see DEBUG LEVELS below.
.TP
.B \-f
Specifies that the program should not fork, but instead
remain in the foreground.
Only use this when you are starting the program manually for
testing purposes.
When in the foreground, any messages produced by the program
are written to
.IR stderr
instead of to
.BR syslog (3)
or any 
.I log_file
you might specify with the
.B \-l
option.
.TP
.B \-h
Display a brief usage summary, then exit.
.TP
.BI \-l \ log_file
Log messages to the specified file instead of to
.BR syslog (3).
(This option is ignored if you also specify the
.B \-f
option, as that directs messages to
.IR stderr .)
The log file is opened shortly after the program starts.
It is closed and re-opened when the program receives
a SIGUSR1 signal.
.TP
.BI \-o \ capture_file
When a response packet is received from an unexpected server,
write the packet to the specified file.
The file is opened and truncated shortly after the program starts.
It is closed and re-opened (and truncated) when the program
receives a SIGUSR2 signal.
The file is a 
.BR pcap (3) 
savefile, and may be read with any program
that understands the pcap savefile format; e.g. 
.BR tcpdump (1).
.TP
.BI \-p \ pid_file
Specifies the file that will contain the program's processid.
If not specified, this defaults to
.BR /var/run/dhcp_probe.pid .
The
.I pid_file
is written shortly after the program starts, and is removed
when the program exits under its own control.
.TP
.BI \-Q \ vlan_id
Specifies that when the program constructs a packet to send, 
it should add an 802.1Q tag with the specified vlan_id.
Valid values range from 0 to 4095.
If not specified, the program does not add an 802.1Q tag
to the packets it constructs.
(The operating system or Ethernet driver may still do so.)
.TP
.BI \-s \ capture_bufsize
Specifies the size of the buffer that will be used to
capture all the responses (Ethernet frames) to a single request packet;
responses which do not fit are silently dropped.
The value is specified in bytes, and must fit into your host's
range for an
.IR int ;
values outside that range may result in unpredictable results.
If not specified, this defaults to 30280, which is enough
for twenty maximum-size Ethernet frames (1514*20).
Typical responses are Ethernet frames ranging from 342-590 bytes, so the
default capture buffer size should hold over 50 of them.
.TP
.B \-T
Enables the 'socket receive timeout' feature.
On some platforms, dhcp_probe may ignore the 
.I response_wait_time
(described in 
.BR dhcp_probe.cf (5)), 
instead waiting forever for a response
after it sends a probe packet.
As per
.BR pcap (3),
this is because the read timeout we pass to pcap_open_live()
is not supported on all platforms.
If you encounter this issue, try enabling our 'socket receive timeout' feature;
it might help.
Enabling this feature causes the program to also set a socket receive 
timeout on the socket underlying the pcap capture; we set this timeout to the 
.IR response_wait_time .
On some platforms, the program's socket receive timeout feature does not work;
instead the program will report that it cannot set the receive timeout,
and will exit.
.TP
.B \-v
Display the program's version number, then exit.
.TP
.IB \-w \ cwd
Specifies the working directory; shortly after starting the
program changes its current working directory to this.
If not specified, this defaults to
.IR / .
.TP
.I interface_name
Specifies the name of the interface the program should use;
this argument is required.
This must be an Ethernet interface which is up.
Typically this interface must also have an IP address assigned;
specifying
.B do_not_lookup_enet_and_ip_addresses
in
.BR dhcp_probe.cf (5)
may allow the program to operate
on an interface which lacks an IP address.
.BB 
.SH OPERATION
.PP
After initialization, the program enters its main event loop,
in which it remains until you signal the program to exit
with a SIGINT, SIGTERM, or SIGQUIT.
.PP
The main event loop (a.k.a. the "probe cycle")
consists of the following actions, repeated until
the program receives a request to quit:
.RS 5
.TP
1. 
Handle any signals that have been received.
.TP
2. 
Install a 
.BR pcap (3)
filter to listen for UDP packets destined to the BootP client port
(UDP port 68).
.TP
3. 
Broadcast a DHCP or BootP request packet out the specified interface.
.TP
4. 
Listen for
.I response_wait_time
milliseconds for any responses received by the 
.BR pcap (3)
filter.
(The
.I response_wait_time
defaults to 5000 milliseconds (5 seconds), and may be changed in the
.IR dhcp_probe.cf (5) 
file.)
.sp
Any responses that contains a bootp_chaddr field not equal to the
chaddr used in the probe is ignored, as are any that have 
incorrect bootp_htype or bootp_hlen fields.
These are not responses to our probe.
.sp
Any responses from known DHCP and BootP servers are ignored.
The IP source address for responses from each known server is declared using a
.B legal_server
statement in the
.IR dhcp_probe.cf (5)
file.
Any response with an IP source address that does not appear in a
.B legal_server
statement is treated as an unknown server.
.sp
The Ethernet source address for responses from each known server is also
optionaly declared using a
.B legal_server_ethersrc
statement in the
.IR dhcp_probe.cf (5)
file.
If at least one 
.B legal_server_ethersrc
is specified, then any response with an Ethernet source address
that does not appear in a
.B legal_server_ethersrc
statement is treated as an unknown server.
If no 
.B legal_server_ethersrc
statements appear, then the response's Ethernet source address is not checked.
(The 
.B legal_server_ethersrc
statement is considered experimental in versions 1.3.0 - 1.3.1,
as it has received only limited testing.)
.sp
For each response from an unknown server:
.TP 10
a)
If the reponse packet contains a non-zero
.BI yiaddr 
field, and one or more 
.B lease_network_of_concern
statements were specified,
determine if the 
.B yiaddr
value falls within any of the "Lease Networks of Concern".
.TP 10
a)
Log a message showing the response packet's source IP and Ethernet addresses.
If the response packet's yiaddr is non-zero and falls within a "Lease Networks of Concern",
the log message also reports that.
.TP 10
b)
If the 
.B \-o 
option was specified, the packet is also written to a packet capture file. 
.TP 10
c)
If an
.I alert_program_name
was specified in the
.IR dhcp_probe.cf (5)
file,
that program is executed, with the following arguments in order:
the name of the calling program (e.g.
.BR dhcp_probe ),
the name of the interface on which the unexpected response packet was received,
the IP source address of the packet,
and the Ethernet source address of the packet.
(We do not wait for the
.I alert_program_name
to complete; it runs in a child process.)
.TP 10
d)
If an
.I alert_program_name2
was specified in the
.IR dhcp_probe.cf (5) 
file,
that program is executed, with the following required options:
.nf
   \-p the name of the calling program (e.g. dhcp_probe)
   \-I the name of the interface on which the unexpected response packet was received
   \-i the IP source address of the packet
   \-m and the Ethernet source address of the packet
.fi
If the response packet's yiaddr is non-zero and falls within a "Lease Networks of Concern",
the following optional options are also passed:
.nf
   \-y the non-zero yiaddr value
.fi
(We do not wait for the
.I alert_program_name2
to complete; it runs in a child process.)
.TP
5.
Remove the 
.BR pcap(3)
filter installed earlier.
.TP
6.
If any signals have arrived requesting that we quit, exit gracefully.
.TP
7. 
Repeat steps 2-6  for each flavor of DHCP and BootP request packet the
program supports (see PACKET FLAVORS below).
.TP
8. 
Handle any signals that have been received.
.TP
9. 
Sleep for 
.I cycle_time
seconds.
(The
.I cycle_time
defaults to 300 seconds, and 
and may be changed in the
.IR dhcp_probe.cf (5)
file.)
.RE
.PP
The 
.BR pcap (3)
filter the program installs normally does not specify that the interface should be
placed into promiscuous mode (although it is possible the interface is already in promiscuous
mode for some other reason).
However, if in the
.BR dhcp_probe.cf (5)
file you specify a
.I chaddr
or
.I ether_src
value other than the interface's actual hardware address,
then the pcap filter
.I will
specify that the interface should be placed into promiscuous mode.
.PP
Although the filter used with
.BR pcap (3)
specifies only UDP packets destined to port 
.I bootpc
should be collected,
on systems where
.I bpf
isn't part of the kernel,
.BR pcap (3)
must implement
.I bpf
as part of the application.
This can increase the number of packets that must be passed from
the kernel to user space to be filtered.
The program attempts to minimize the side-effects of this by
removing the 
.BR pcap (3)
filter when it isn't actually listening for responses.
In particular, the filter is not installed during the time the
program sleeps between each probe cycle
(the
.IR cycle_time ).
.PP
If you do specify an 
.IR alert_program_name ,
take care that the program you specify is safe for a privileged
user to run; it is executed with the same (i.e. root) privileges as
the calling program.
.SH "PACKET FLAVORS"
No single request packet is likely to provoke a response
from every possible BootP and DHCP server.
Some servers may only response to either BootP, or DHCP, but
not both.
Some servers may be configured to only respond to a small
set of known clients.
Some DHCP servers will only provide leases to a small
set of known clients, but may be willing to respond
(negatively) to unknown clients that 
request a lease renewal on an inappropriate IP address.
Therefore, 
dhcp_probe
actually sends not one, but five different
flavor request packets, in the hopes of provoking responses
from a wider variety of unknown servers.
.PP
The packet flavors are:
.TP
BOOTPREQUEST
This packet is typical of a BootP client requesting an IP address.
.sp
It will typically provoke a BOOTPREPLY from a BootP server willing to
respond to any BootP client.
(BootP servers configured to only respond to a set of known clients
may not respond.)
.TP
DHCPDISOVER (INIT)
This packet is typical of a DHCP client in the INIT state.
.sp
The options field contains a DHCP Message Type specifying DHCPDISCOVER.
.sp
The options field contains a DHCP Client Identifier, which is computed
by prepending 0x'01' to the value of
.IR chaddr . 
(The value
.I chaddr
is specified in the
.BR dhcp_probe.cf (5)
file, otherwise it defaults to the interface's Ethernet address.)
.sp
This packet will typically provoke a  DHCPOFFER from a DHCP server willing to
respond to any DHCP client.
(DHCP servers configured to only offer leases to a set of known clients
may not respond.)
.TP
DHCPREQUEST (SELECTING):
This packet is typical of a DHCP client in the SELECTING state; i.e. a client
which has previously issued a DHCPDISCOVER, then received a DHCPOFFER from
some DHCP server.
.sp
The options field contains a DHCP Message Type specifying DHCPREQUEST.
.sp
The options field contains a DHCP Client Identifier, 
which is computed 
by prepending 0x'01' to the value of
.IR chaddr .
(The value
.I chaddr
is specified in the
.BR dhcp_probe.cf (5)
file, otherwise it defaults to the interface's Ethernet address.)
.sp
The options field contains a DHCP Server Identifier specifying 
.IR server_id ,
which should be an IP address that does not correspond to any valid DHCP Server Identifier
on your network.
(The value
.I server_id
is specified in the
.BR dhcp_probe.cf (5)
file, otherwise it defaults to 10.254.254.254.)
.sp
The options field contains a DHCP Requested IP Address specifying 
.IR client_ip_address ,
which should be an IP address that does not correspond to any valid IP address
on your network.
(The value
.I client_ip_address
is specified in the
.BR dhcp_probe.cf (5)
file, otherwise it defaults to 172.31.254.254.)
.sp
This packet occassionally provokes a response from a broken DHCP server
that fails to respect the DHCP Server Identifier option.
.TP
DHCPREQUEST (INIT-REBOOT):
This packet is typical of a DHCP client in the INIT-REBOOT state; i.e. a client
which has obtained a DHCP lease in the past, is bringing up its IP stack,
and hopes to obtain (or extend) a DHCP lease on the same IP address as in the past.
.sp
The options field contains a DHCP Message Type specifying DHCPREQUEST.
.sp
The options field contains a DHCP Client Identifier, 
which is computed 
by prepending 0x'01' to the value of
.IR chaddr .
(The value
.I chaddr
is specified in the
.BR dhcp_probe.cf (5)
file, otherwise it defaults to the interface's Ethernet address.)
.sp
The options field contains a DHCP Requested IP Address specifying
.IR client_ip_address ,
which should be an IP address that does not correspond to any valid IP address
on your network; ideally it should be one that is topologically inappropriate
for your network.
(The value
.I client_ip_address
is specified in the
.BR dhcp_probe.cf (5)
file, otherwise it defaults to 172.31.254.254.)
.sp
If the Requested IP Address option is topologically inappropriate for your network,
this packet may provoke a DHCPNAK from any DHCP server that 
believes it is authoritative for the network's IP topology.
.TP
DHCPREQUEST (REBINDING)
This packet is typical of a DHCP client in the REBINDING state; i.e. a client
which has obtained a DHCP lease which is between its DHCP T2 and expiration time.
.sp
The options field contains a DHCP Message Type specifying DHCPREQUEST.
.sp
The options field contains a DHCP Client Identifier, 
which is computed 
by prepending 0x'01' to the value of
.IR chaddr .
(The value
.I chaddr
is specified in the
.BR dhcp_probe.cf (5)
file, otherwise it defaults to the interface's Ethernet address.)
.sp
The ciaddr field contains
.IR client_ip_address ,
which should be an IP address that does not correspond to any valid IP address
on your network; ideally it should be one that is topologically inappropriate
for your network.
(The value
.I client_ip_address
is specified in the
.BR dhcp_probe.cf (5)
file, otherwise it defaults to 172.31.254.254.)
.sp
If the value of ciaddr is topologically inappropriate for your network,
this packet will provoke a DHCPNAK from any DHCP server that 
believes it is authoritative for the network's IP topology.
.PP
All the request packets sent by the program
share the following common characteristics:
.RS 5
.sp
Ethernet Header
.RS 5
destination: ff:ff:ff:ff:ff:ff
.br
source: 
.IR ether_src 
from 
.IR dhcp_probe.cf (5),
else interface hardware address
.br
type: ETHERTYPE_IP (0x0800)
.RE
.sp
IP Header
.RS 5
version: 4
.br
header length: 5
.br
tos: 0
.br
total length: 328 (20-byte IP header + 8-byte UDP header + 300-byte BootP/DHCP payload)
.br
identifier: 1
.br
flags: 0
.br
fragment offset: 0
.br
ttl: 60
.br
protocol: IPPROTO_UDP (17)
.br
header checksum: (computed)
.br
source address: 0.0.0.0
.br
destination address: 255.255.255.255
.br
options: (none)
.RE
.br
.sp
UDP Header
.RS 5
source port: PORT_BOOTPC (68)
.br
dest port:  PORT_BOOTPS (67)
.br
checksum: (computed)
.RE
.sp
BootP/DHCP Payload
.RS 5
op: BOOTREQUEST (1)
.br
htype: HTYPE_ETHER (1)
.br
hlen: HLEN_ETHER (6)
.br
hops: 0
.br
xid: 1
.br
secs: 0
.br
flags: 0
.br
ciaddr: 0.0.0.0 (except for DHCPREQUEST (REBINDING) packets it is
.I client_ip_address
from
.BR dhcp_probe.cf (5),
else 172.31.254.254)
.br
siaddr: 0.0.0.0
.br
giaddr: 0.0.0.0
.br
chaddr: 
.I chaddr 
from 
.IR dhcp_probe.cf (5), 
else interface hardware address
.br
sname: (all 0's)
.br
file: (all 0's)
.br
options: RFC1048 cookie (0x63825363), 
possibly followed by DHCP options, 
followed by END option (0xFF), 
followed by PAD options (0x00) to bring the field to 64 bytes
.RE
.RE
.SH "MULTIPLE INTERFACES"
Although dhcp_probe only supports monitoring a single physical or logical interface,
you may run an instance of the program on each physical or logical interface;
each monitors a different network.
.PP
When running multiple copies of dhcp_probe, be sure to specify
a different 
.I pid_file
for each instance.
.PP
If you specify a
.I log_file 
and/or a
.IR capture_file ,
be sure to specify a different one for each instance.
.PP
You may specify a different
.I config_file
for each instance.
If you don't need to customize the settings in that file for each
instance, you may use
the same configuration file for all instances.
.PP
If you have multiple logical interfaces on the same VLAN on the same physical 
interface, or multiple logical IP networks on the same VLAN running on a single
physical network, there is no need to run multiple instances
of dhcp_probe to monitor each logical interface or logical network.
A single instance of the program running on a physical interface or logical interface
is sufficient to provoke any servers on that one VLAN on that physical (or logical) network
that might be willing to respond.
.PP
If your physical interface supports 802.1Q, you can use a single
physical interface to monitor multiple VLANs.
Use your operating system to create a logical interface (on the same physical interface) for each VLAN.
When frames arrive on the physical interface containing the 802.1Q tag you specified
for the logical interface, your operating system is responsible for
delivering those frames to the logical interface with the 802.1Q tag removed.
(Some Ethernet drivers will retain the 802.1Q tag but change the VLAN ID to 0;
we understand that format.)
Run an instance of the program on each logical interface.
If your operating system and network driver does not automatically add
an 802.1Q header to the packets we transmit, you will also need to specify the \-Q
option to instruct the program to add an 802.1Q header to the packets
it constructs.
(If the operating system or network driver automatically adds the 802.1Q
header to these packets, then specifying \-Q will likely not do what you want.
Selecting the wrong choice often means that the packets we construct will
be transmitted incorrectly, or may be silently discarded by
the operating system or the Ethernet switch.)
.SH SIGNALS
The program will respond to a number of signals:
.TP
.B SIGUSR1
If logging to a file, close and re-open it.
If the program is in the middle of a probe cycle, handling
the signal is deferred until the end of the cycle.
(Has no effect if logging to
.BR syslog (3)
or if the
.B \-f
option was specified.)
.TP
.B SIGUSR2
If capturing to a file, close and re-open it.
If the program is in the middle of a probe cycle, handling
the signal is deferred until the end of the cycle.
(Has no effect if the
.B \-o
option was not specified.)
.sp
Because re-opening the capture file causes the 
file to be truncated and a new 
.BR pcap (3)
header to be
written to it, if you want to save the 
prior contents of the capture file, move the existing
capture file aside before sending the signal.
.TP
.B SIGHUP
Reread the configuration file.
If the program is in the middle of a probe cycle, handling
the signal is deferred until the end of the cycle.
.TP
.B SIGTERM, SIGINT, SIGQUIT
Exit gracefully.
If the program is in the middle of a probe cycle, handling
the signal is deferred until the program finishes
sending and receiving responses for the current flavor
request packet.
.SH "LEASE NETWORKS OF CONCERN"
Most rogue BootP/DHCP servers distribute private IP addresses to
clients, or send DHCPNAK messages to legitimate clients.
Some even more disruptive rogue BootP/DHCP servers may distribute IP addresses
that fall within your own networks' IP ranges.
The "Lease Networks of Concern" feature is intended to help you
identify these particularly disruptive servers.
.PP
You may activate the feature by specifying the
.B lease_network_of_concern 
statement in your configuration file.
Use the statement multiple times to specify all your legitimate network ranges.
.PP
When a rogue BootP/DHCP server is detected, 
if the rogue's response packet contains a non-zero 
.B yiaddr 
value, the value is compared to the "Lease Networks of Concern" you specified.
If the value falls within any of those network ranges, the message
logged by
.B dhcp_probe
is extended to make note of this, and to report the 
.B yiaddr
value.
Furthermore, if you are using the
.B alert_program_name2
feature, the alert program is called with an extra 
.B "\-y yiaddr"
option so that alert program can take any additional action desired.
.PP
.SH "DEBUG LEVELS"
The program produces increasingly detailed output as the
.I debuglevel
increases. 
Under normal circumstances, you can run at 
.IR debuglevel
0.
Here's roughly what messages are added at each
.IR debuglevel .
.LP
.TP 6
0
Display the IP source (and Ethernet source) of each unexpected DHCP or BootP response packet.
.sp
Startup and shutdown notice.
.sp
Non-fatal errors in the configuration file.
.sp
Fatal errors.
.TP 6
1
At startup, show some information about the program's configuration.
.TP 6
2
Show each time we start and finish (re-)reading the configuration file.
.sp
Show each time we close and re-open the logfile or capture file.
.sp
Report on response packets that could not be parsed (e.g. truncated).
.TP 6
3
Each time we (re-)read the configuration file, echo the information we obtain from it.
.TP 6
7
For each parsable response packet, show the Ethernet source and destination, the IP source and destination,
and indicate when the IP source is a legal (known) server.
.TP 6
11
For each probe cycle, show when the cycle begins and ends, when we write a packet, and
when we begin and end listening for response packets.
.SH AUTHOR
The program was written by Irwin Tillman
of Princeton University's OIT Network Systems Group.
It was written to run on Solaris, 
relying on the generally-available
.BR pcap (3)
and
.BR libnet (3)
libraries.
.SH FILES
.TP
.B /etc/dhcp_probe.cf
Configuration file read by the program.
See
.BR dhcp_probe.cf (5).
The name of this file can be overridden by a command-line option.
.TP
.B /etc/dhcp_probe.pid
Contains the program's processid.
The name of this file can be overridden by a command-line option.
.SH LIMITATIONS
dhcp_probe
is not guaranteed to locate all unknown DHCP and BootP
servers attached to a network.
If a BootP server is configured so it only responds to certain clients
(e.g. those with certain hardware addresses), it will not respond
to the BOOTPREQUEST packet we sent.
If a DHCP server is configured so it only responds to certain clients
(e.g. those with certain hardware addresses or DHCP Client Identifiers),
it will not respond to the packets we send that mimic DHCP clients
in the INIT state.
If a DHCP server is configured so it does not send DHCPNAK packets 
to clients requesting topologically-inappropriate IP addresses,
it will not respond the packets we send that mimic DHCP clients
in the INIT-REBOOT and REBINDING states.
.PP
The upshot is that
it is possible that 
dhcp_probe
will be unable to
provoke some BootP and DHCP servers into responding at all.
.PP
Flushing out such servers can be extremely difficult. 
One approach is to capture all UDP/IP packet destined to the BootP client
port which cross your network; since most of these packets are unicast at Layer 2,
capturing is only effective if 
.I all 
such packets must pass by your
capture device's Ethernet interface (e.g. the capture device is
located at a network choke point, or the network
does not involve any Layer 2 switching).
Another approach is to do UDP port scanning for all devices 
listening on the BootP server port, and assume that those
which are listening on that port are running a BootP or DHCP server.
.PP
Malicious BootP or DHCP servers that forge the IP source address
(and possibly the Ethernet source address) of their responses
to match the values specified by
.B legal_server
and
.B legal_server_ethersrc
statements
will not be detected.
.PP
If the network contains any Ethernet switch which selectively filters
(rather than floods) layer 2 broadcasts sent by DHCP/BootP clients,
dhcp_probe will be unable to locate DHCP and BootP servers 
on the far side of that Ethernet switch.
Such switches prevent the probe packets from reaching rogue DHCP/BootP servers.
For example, some Cisco Nexus(R) switch/routers models configured to act as a network's IPv4 router
and BootP Relay Agent may not flood such frames, instead delivering them only
to the router's embedded BootP Relay Agent.
.SH BUGS
The packet capture buffer size is limited; if a single request packet
provokes more responses than will fit into the buffer, those that do
not fit are silently dropped, without any diagnostic indicating
that the buffer was too small.
You can adjust the size of the packet capture buffer size using the
.BI \-s \ capture_bufsize
option.
.PP
We do not support non-Ethernet interfaces.
.PP
Because (re-)opening a packet capture file causes the file to be opened
for writing (not appending),
the contents of any existing packet capture file of the same name is lost when the
program starts or receives a SIGUSR2 signal.
If the file's previous contents should be preserved, move the old
file aside before starting the program or sending it a SIGUSR2 signal.
(This "feature" exists because opening a 
.BR pcap (3) 
savefile
always involves writing a pcap header record to the start of the file, so
pcap always opens the file using mode "w".)
.PP
Because 
.BR pcap (3)
opens the packet capture file with a simple 
.BR fopen (3)
without checking to see if the file already exists, dhcp_probe
may be tricked into overwriting or corrupting an existing file.
As dhcp_probe is run with root privileges, this is a serious concern.
To avoid this problem, if you use the 
.B \-o
option, ensure that the directory that
will contain the capture file is writable only by root.
.PP
The packet capture file that is written is unparseable after
the first packet.
E.g. if read with
.BR tcpdump (8),
it reports:
.IR "tcpdump: pcap_loop: truncated dump file" .
.PP
On platforms where 
.BR pcap (3)
is unable to support the 
.I timeout
argument to
.IR pcap_open_live ,
the program may not reliably detect responses from DHCP and BootP servers,
or may not function at all.
.SH "SEE ALSO"
.LP
.BR dhcp_probe.cf (5)
.TP 10
.BR pcap (3)
(a.k.a. libpcap, a packet capture library),
available from
http://www.tcpdump.org.
(An older version is available from
ftp://ftp.ee.lbl.gov/libpcap.tar.Z.) 
.TP 10
.BR libnet (3)
(a.k.a libwrite, a packet writing library),
available from
http://www.packetfactory.net/libnet
.SH "TRADEMARKS"
.LP
.TP 10
Cisco Nexus(R) is a trademark of Cisco Systems.