Provided by: dhcp-probe_1.3.0-8_i386 bug

NAME

       dhcp_probe  -  locate  DCHP  and  BootP  servers on a directly-attached
       network

SYNOPSIS

       dhcp_probe [ -c config_file ] [ -d debuglevel ] [ -f ]  [  -h  ]  [  -l
       log_file  ]  [  -o  capture_file  ] [ -p pid_file ] [ -Q vlan_id ] [ -s
       capture_bufsize ] [ -T ] [ -v ] [ -w cwd ] interface_name

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.

       The program must be run with root privilege.

       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.

       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.

       Optionally,  responses  from  unknown  servers may also be written to a
       packet capture file.

       Optionally, an external program may be called each time a response from
       an unknown server is received.

       dhcp_probe  may  not  be able to locate all DHCP and BootP servers; see
       LIMITATIONS below.

       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.

       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 interfaces, you may run an instance of
       dhcp_probe on each interface.   If  your  physical  interface  supports
       802.1Q,  you  can  use that to create a logical interface on each VLAN,
       then run an instance of dhcp_probe on each logical interface.

       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 may violate on a network where you don't have permission to do
       so may violate that network's acceptable use policy.

AVAILABILITY

       dhcp_probe  is  a  product  of  the  Network Systems Group at Princeton
       University's Office of Information Technology, and  is  available  from
       http://www.net.princeton.edu/software/dhcp_probe/

       Presently  the  product builds and runs on Solaris 9 on SPARC with gcc.
       The program relies on the pcap(3) and libnet(3) libraries.

OPTIONS

       -c config_file
              Specifies  the  configuration  file.   If  not  specified,  this
              defaults  to /etc/dhcp_probe.cf.  The configuration file is read
              at startup, and is re-read whenever a SIGHUP is  received.   See
              dhcp_probe.cf(5).

       -d debuglevel
              Sets  the  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.

       -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 stderr
              instead of to syslog(3) or any log_file you might  specify  with
              the -l option.

       -h     Display a brief usage summary, then exit.

       -l log_file
              Log  messages  to  the  specified  file instead of to syslog(3).
              (This option is ignored if you also specify the  -f  option,  as
              that  directs  messages  to  stderr.)   The  log  file is opened
              shortly after the program starts.  It is  closed  and  re-opened
              when the program receives a SIGUSR1 signal.

       -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 pcap(3) savefile, and may be read with
              any program that understands  the  pcap  savefile  format;  e.g.
              tcpdump(1).

       -p pid_file
              Specifies  the  file  that will contain the program's processid.
              If not specified, this defaults to /var/run/dhcp_probe.pid.  The
              pid_file  is  written  shortly  after the program starts, and is
              removed when the program exits under its own control.

       -Q vlan_id
              Specifies that the packets we send  should  be  tagged  with  an
              802.1Q  VLAN ID vlan_id.  Valid values range from 0 to 4095.  If
              not specified, the packets we send  do  not  contain  an  802.1Q
              header.

       -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
              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.

       -T     Enables  the  'socket  receive  timeout'   feature.    On   some
              platforms,   dhcp_probe   may   ignore   the  response_wait_time
              (described in dhcp_probe.cf(5)), instead waiting forever  for  a
              response after it sends a probe packet.  As per 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 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.

       -v     Display the program's version number, then exit.

       -w cwd Specifies the working  directory;  shortly  after  starting  the
              program  changes  its current working directory to this.  If not
              specified, this defaults to /.

       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 and has been assigned an IP address.

OPERATION

       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.

       The main  event  loop  (a.k.a.  the  "probe  cycle")  consists  of  the
       following  actions,  repeated  until  the program receives a request to
       quit:

            1.     Handle any signals that have been received.

            2.     Install a pcap(3) filter to listen for UDP packets destined
                   to the BootP client port (UDP port 68).

            3.     Broadcast  a DHCP or BootP request packet out the specified
                   interface.

            4.     Listen  for   response_wait_time   milliseconds   for   any
                   responses   received   by   the   pcap(3)   filter.    (The
                   response_wait_time  defaults  to   5000   milliseconds   (5
                   seconds), and may be changed in the dhcp_probe.cf(5) file.)

                   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.

                   Any  responses  from  known  DHCP  and  BootP  servers  are
                   ignored.   The  IP  source  address for responses from each
                   known server is declared using a legal_server statement  in
                   the  dhcp_probe.cf(5) file.  Any response with an IP source
                   address that does not appear in a legal_server statement is
                   treated as an unknown server.

                   The  Ethernet  source address for responses from each known
                   server    is    also    optionaly    declared    using    a
                   legal_server_ethersrc  statement  in  the  dhcp_probe.cf(5)
                   file.  If at least one legal_server_ethersrc is  specified,
                   then any response with an Ethernet source address that does
                   not appear in a legal_server_ethersrc statement is  treated
                   as   an   unknown   server.   If  no  legal_server_ethersrc
                   statements appear,  then  the  response's  Ethernet  source
                   address   is   not   checked.   (The  legal_server_ethersrc
                   statement is considered experimental in version  1.3.0,  as
                   it has received only limited testing.)

                   For each response from an unknown server:

            a)        If  the reponse packet contains a non-zero yiaddr field,
                      and one or more lease_network_of_concern statements were
                      specified,  determine  if  the yiaddr value falls within
                      any of the "Lease Networks of Concern".

            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.

            b)        If  the  -o  option  was  specified,  the packet is also
                      written to a packet capture file.

            c)        If  an   alert_program_name   was   specified   in   the
                      dhcp_probe.cf(5)  file,  that  program is executed, with
                      the following  arguments  in  order:  the  name  of  the
                      calling  program  (e.g.   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  alert_program_name  to  complete; it runs in a
                      child process.)

            d)        If  an  alert_program_name2   was   specified   in   the
                      dhcp_probe.cf(5)  file,  that  program is executed, with
                      the following required options:
                         -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
                      If the response packet's yiaddr is  non-zero  and  falls
                      within  a  "Lease  Networks  of  Concern", the following
                      optional options are also passed:
                         -y the non-zero yiaddr value
                      (We do not wait for the alert_program_name2 to complete;
                      it runs in a child process.)

            5.        Remove the pcap(3) filter installed earlier.

            6.        If  any  signals  have  arrived requesting that we quit,
                      exit gracefully.

            7.        Repeat steps 2-6  for each  flavor  of  DHCP  and  BootP
                      request  packet the program supports (see PACKET FLAVORS
                      below).

            8.        Handle any signals that have been received.

            9.        Sleep for cycle_time seconds.  (The cycle_time  defaults
                      to   300   seconds,  and  and  may  be  changed  in  the
                      dhcp_probe.cf(5) file.)

       The 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 dhcp_probe.cf(5) file you specify a chaddr
       or ether_src value other than the interface's actual hardware  address,
       then  the  pcap filter will specify that the interface should be placed
       into promiscuous mode.

       Although the filter  used  with  pcap(3)  specifies  only  UDP  packets
       destined to port bootpc should be collected, on systems where bpf isn't
       part of  the  kernel,  pcap(3)  must  implement  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 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 cycle_time).

       If you do specify an 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.

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.

       The packet flavors are:

       BOOTPREQUEST
              This packet is typical  of  a  BootP  client  requesting  an  IP
              address.

              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.)

       DHCPDISOVER (INIT)
              This packet is typical of a DHCP client in the INIT state.

              The options  field  contains  a  DHCP  Message  Type  specifying
              DHCPDISCOVER.

              The  options  field  contains a DHCP Client Identifier, which is
              computed by prepending 0x'01' to  the  value  of  chaddr.   (The
              value   chaddr   is  specified  in  the  dhcp_probe.cf(5)  file,
              otherwise it defaults to the interface's Ethernet address.)

              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.)

       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.

              The  options  field  contains  a  DHCP  Message  Type specifying
              DHCPREQUEST.

              The options field contains a DHCP Client  Identifier,  which  is
              computed  by  prepending  0x'01'  to  the value of chaddr.  (The
              value  chaddr  is  specified  in  the   dhcp_probe.cf(5)   file,
              otherwise it defaults to the interface's Ethernet address.)

              The  options  field contains a DHCP Server Identifier specifying
              server_id,  which  should  be  an  IP  address  that  does   not
              correspond  to any valid DHCP Server Identifier on your network.
              (The value server_id is specified in the dhcp_probe.cf(5)  file,
              otherwise it defaults to 10.254.254.254.)

              The   options   field  contains  a  DHCP  Requested  IP  Address
              specifying client_ip_address, which should be an IP address that
              does  not  correspond  to  any valid IP address on your network.
              (The   value   client_ip_address    is    specified    in    the
              dhcp_probe.cf(5) file, otherwise it defaults to 172.31.254.254.)

              This packet occassionally provokes a response from a broken DHCP
              server that fails to respect the DHCP Server Identifier option.

       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.

              The  options  field  contains  a  DHCP  Message  Type specifying
              DHCPREQUEST.

              The options field contains a DHCP Client  Identifier,  which  is
              computed  by  prepending  0x'01'  to  the value of chaddr.  (The
              value  chaddr  is  specified  in  the   dhcp_probe.cf(5)   file,
              otherwise it defaults to the interface's Ethernet address.)

              The   options   field  contains  a  DHCP  Requested  IP  Address
              specifying 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 client_ip_address is specified in the
              dhcp_probe.cf(5) file, otherwise it defaults to 172.31.254.254.)

              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.

       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.

              The  options  field  contains  a  DHCP  Message  Type specifying
              DHCPREQUEST.

              The options field contains a DHCP Client  Identifier,  which  is
              computed  by  prepending  0x'01'  to  the value of chaddr.  (The
              value  chaddr  is  specified  in  the   dhcp_probe.cf(5)   file,
              otherwise it defaults to the interface's Ethernet address.)

              The  ciaddr field contains 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 client_ip_address is
              specified in the dhcp_probe.cf(5) file, otherwise it defaults to
              172.31.254.254.)

              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.

       All the request packets sent by the program share the following  common
       characteristics:

            Ethernet Header
                 destination: ff:ff:ff:ff:ff:ff
                 source:   ether_src  from  dhcp_probe.cf(5),  else  interface
                 hardware address
                 type: ETHERTYPE_IP (0x0800)

            IP Header
                 version: 4
                 header length: 5
                 tos: 0
                 total length: 328 (20-byte IP header + 8-byte  UDP  header  +
                 300-byte BootP/DHCP payload)
                 identifier: 1
                 flags: 0
                 fragment offset: 0
                 ttl: 60
                 protocol: IPPROTO_UDP (17)
                 header checksum: (computed)
                 source address: 0.0.0.0
                 destination address: 255.255.255.255
                 options: (none)

            UDP Header
                 source port: PORT_BOOTPC (68)
                 dest port:  PORT_BOOTPS (67)
                 checksum: (computed)

            BootP/DHCP Payload
                 op: BOOTREQUEST (1)
                 htype: HTYPE_ETHER (1)
                 hlen: HLEN_ETHER (6)
                 hops: 0
                 xid: 1
                 secs: 0
                 flags: 0
                 ciaddr:  0.0.0.0  (except for DHCPREQUEST (REBINDING) packets
                 it   is   client_ip_address   from   dhcp_probe.cf(5),   else
                 172.31.254.254)
                 siaddr: 0.0.0.0
                 giaddr: 0.0.0.0
                 chaddr: chaddr from dhcp_probe.cf(5), else interface hardware
                 address
                 sname: (all 0's)
                 file: (all 0's)
                 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

MULTIPLE INTERFACES

       Although  dhcp_probe  only  supports  monitoring  a   single   physical
       interface,  you  may  run  an  instance of the program on each physical
       interface; each monitors a different physical network.

       When running multiple copies  of  dhcp_probe,  be  sure  to  specify  a
       different pid_file for each instance.

       If  you  specify a log_file and/or a capture_file, be sure to specify a
       different one for each instance.

       You may specify a different 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.

       If you have multiple logical interfaces on the same physical interface,
       or  multiple  logical IP networks running on a single physical network,
       there is no need to run multiple instances  of  dhcp_probe  to  monitor
       each  logical  interfaces or logical network.  A single instance of the
       program running on a physical interface is sufficient  to  provoke  any
       servers on that physical network that might be willing to respond.

       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 each VLAN, then run an instance
       of the program  on  each  logical  interface.   Since  the  program  is
       responsible  for constructing Ethernet frame headers, you will probably
       need to specify the -Q option to instruct it to add to outgoing  frames
       an 802.1Q VLAN header with the appropriate VLAN ID.

SIGNALS

       The program will respond to a number of signals:

       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
              syslog(3) or if the -f option was specified.)

       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 -o option was
              not specified.)

              Because  re-opening  the  capture  file  causes  the  file to be
              truncated and a new 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.

       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.

       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.

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.

       You may activate the feature by specifying the lease_network_of_concern
       statement in your configuration file.  Use the statement multiple times
       to specify all your legitimate network ranges.

       When a rogue BootP/DHCP server is detected,  if  the  rogue's  response
       packet  contains  a non-zero 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 dhcp_probe is
       extended to make  note  of  this,  and  to  report  the  yiaddr  value.
       Furthermore,  if  you  are  using  the alert_program_name2 feature, the
       alert program is called with an extra -y yiaddr option  so  that  alert
       program can take any additional action desired.

DEBUG LEVELS

       The  program  produces  increasingly  detailed output as the debuglevel
       increases.  Under normal circumstances, you can run  at  debuglevel  0.
       Here's roughly what messages are added at each debuglevel.

       0     Display  the  IP  source (and Ethernet source) of each unexpected
             DHCP or BootP response packet.

             Startup and shutdown notice.

             Non-fatal errors in the configuration file.

             Fatal errors.

       1     At  startup,  show   some   information   about   the   program's
             configuration.

       2     Show each time we start and finish (re-)reading the configuration
             file.

             Show each time we close and re-open the logfile or capture file.

             Report on  response  packets  that  could  not  be  parsed  (e.g.
             truncated).

       3     Each   time   we  (re-)read  the  configuration  file,  echo  the
             information we obtain from it.

       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.

       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.

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 pcap(3) and libnet(3) libraries.

FILES

       /etc/dhcp_probe.cf
              Configuration file read by the program.   See  dhcp_probe.cf(5).
              The  name  of  this  file  can  be  overridden by a command-line
              option.

       /etc/dhcp_probe.pid
              Contains the program's processid.  The name of this file can  be
              overridden by a command-line option.

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.

       The  upshot  is  that  it is possible that dhcp_probe will be unable to
       provoke some BootP and DHCP servers into responding at all.

       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  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.

       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 legal_server and  legal_server_ethersrc  statements
       will not be detected.

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 -s capture_bufsize option.

       We do not support non-Ethernet interfaces.

       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
       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".)

       Because pcap(3) opens the packet capture file with  a  simple  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 -o option, ensure that the directory that  will
       contain the capture file is writable only by root.

       The  packet capture file that is written is unparseable after the first
       packet.  E.g. if read with tcpdump(8), it reports: tcpdump:  pcap_loop:
       truncated dump file.

       On platforms where pcap(3) is unable to support the timeout argument to
       pcap_open_live, the program may not reliably detect responses from DHCP
       and BootP servers, or may not function at all.

SEE ALSO

       dhcp_probe.cf(5)

       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.)

       libnet(3) (a.k.a  libwrite,  a  packet writing library), available from
                 http://www.packetfactory.net/libnet