1DHCP_PROBE(8) System Manager's Manual DHCP_PROBE(8)
2
6 dhcp_probe - locate DCHP and BootP servers on a directly-attached net‐
7 work
8
10 dhcp_probe [ -c config_file ] [ -d debuglevel ] [ -f ] [ -h ] [ -l
11 log_file ] [ -o capture_file ] [ -p pid_file ] [ -Q vlan_id ] [ -s cap‐
12 ture_bufsize ] [ -T ] [ -v ] [ -w cwd ] interface_name
13
15 dhcp_probe attempts to discover DHCP and BootP servers on a directly-
16 attached Ethernet network. A network administrator can use this tool
17 to locate unauthorized DHCP and BootP servers.
18 The program must be run with root privilege.
20 The program periodically broadcasts a number of DHCP and BootP request
22 packets out a single physical interface. Several different kinds of
23 request packets are sent, as a DHCP or BootP server may only respond to
24 certain requests, depending on the server's configuration. Essen‐
25 tially, dhcp_probe mimics a BootP or DHCP client in a variety of possi‐
26 ble states, attempting to provoke responses from servers.
27 After sending each request packet, dhcp_probe listens for responses.
29 After filtering out responses that do not appear to be in response to
30 the probe, and responses from known DHCP and BootP servers (identified
31 by their IP source addresses and optionally by their Ethernet source
32 addresses), it logs any responses from unknown servers.
33 Optionally, responses from unknown servers may also be written to a
35 packet capture file.
36 Optionally, an external program may be called each time a response from
38 an unknown server is received.
39 dhcp_probe may not be able to locate all DHCP and BootP servers; see
41 LIMITATIONS below.
42 As DHCP broadcasts do not ordinarily cross IP routers, dhcp_probe will
44 locate only servers that are attached to the same physical network as
45 the interface specified on the command line. Although BootP Relay
46 Agents running on this network may help the broadcasts cross IP
47 routers, these agents typically are configured to convert the broad‐
48 casts to unicasts directed to only the well-known DHCP or BootP servers
49 located on other physical networks. As a result, BootP Relay Agents
50 will allow your the servers to receive the requests issued by
51 dhcp_probe, but will not cause remote unknown servers to hear these
52 requests. Therefore, if you have multiple physical networks, you may
53 wish to run dhcp_probe on each of these networks to discover unknown
54 DHCP and BootP servers on each of them.
55 dhcp_probe functions on a single Ethernet interface specified on the
57 command line; it does not listen on multiple interfaces. However, if
58 the host has multiple physical interfaces, you may run an instance of
59 dhcp_probe on each interface. If your physical interface supports
60 802.1Q, you can use that to create a logical interface on each VLAN,
61 then run an instance of dhcp_probe on each logical interface.
62 dhcp_probe is intended for use by a network administrator. Before run‐
64 ning dhcp_probe on any network other than one for which you are respon‐
65 sible, contact that network's administrator to learn if it is accept‐
66 able for you to run this software on that network. Running this soft‐
67 ware may violate on a network where you don't have permission to do so
68 may violate that network's acceptable use policy.
69
71 dhcp_probe is a product of the Network Systems Group at Princeton Uni‐
72 versity's Office of Information Technology, and is available from
73 http://www.net.princeton.edu/software/dhcp_probe/
74 Presently the product builds and runs on Solaris 9 on SPARC with gcc.
76 The program relies on the pcap(3) and libnet(3) libraries.
77
79 -c config_file
80 Specifies the configuration file. If not specified, this
81 defaults to /etc/dhcp_probe.cf. The configuration file is read
82 at startup, and is re-read whenever a SIGHUP is received. See
83 dhcp_probe.cf(5).
84 -d debuglevel
86 Sets the debuglevel variable that controls the amount of debug‐
87 ging messages generated. If not specified, this defaults to 0
88 (no debugging). For a summary of the types of messages produced
89 at each debug level, see DEBUG LEVELS below.
90 -f Specifies that the program should not fork, but instead remain
92 in the foreground. Only use this when you are starting the pro‐
93 gram manually for testing purposes. When in the foreground, any
94 messages produced by the program are written to stderr instead
95 of to syslog(3) or any log_file you might specify with the -l
96 option.
97 -h Display a brief usage summary, then exit.
99 -l log_file
101 Log messages to the specified file instead of to syslog(3).
102 (This option is ignored if you also specify the -f option, as
103 that directs messages to stderr.) The log file is opened
104 shortly after the program starts. It is closed and re-opened
105 when the program receives a SIGUSR1 signal.
106 -o capture_file
108 When a response packet is received from an unexpected server,
109 write the packet to the specified file. The file is opened and
110 truncated shortly after the program starts. It is closed and
111 re-opened (and truncated) when the program receives a SIGUSR2
112 signal. The file is a pcap(3) savefile, and may be read with
113 any program that understands the pcap savefile format; e.g.
114 tcpdump(1).
115 -p pid_file
117 Specifies the file that will contain the program's processid.
118 If not specified, this defaults to /var/run/dhcp_probe.pid. The
119 pid_file is written shortly after the program starts, and is
120 removed when the program exits under its own control.
121 -Q vlan_id
123 Specifies that the packets we send should be tagged with an
124 802.1Q VLAN ID vlan_id. Valid values range from 0 to 4095. If
125 not specified, the packets we send do not contain an 802.1Q
126 header.
127 -s capture_bufsize
129 Specifies the size of the buffer that will be used to capture
130 all the responses (Ethernet frames) to a single request packet;
131 responses which do not fit are silently dropped. The value is
132 specified in bytes, and must fit into your host's range for an
133 int; values outside that range may result in unpredictable
134 results. If not specified, this defaults to 30280, which is
135 enough for twenty maximum-size Ethernet frames (1514*20). Typi‐
136 cal responses are Ethernet frames ranging from 342-590 bytes, so
137 the default capture buffer size should hold over 50 of them.
138 -T Enables the 'socket receive timeout' feature. On some plat‐
140 forms, dhcp_probe may ignore the response_wait_time (described
141 in dhcp_probe.cf(5)), instead waiting forever for a response
142 after it sends a probe packet. As per pcap(3), this is because
143 the read timeout we pass to pcap_open_live() is not supported on
144 all platforms. If you encounter this issue, try enabling our
145 'socket receive timeout' feature; it might help. Enabling this
146 feature causes the program to also set a socket receive timeout
147 on the socket underlying the pcap capture; we set this timeout
148 to the response_wait_time. On some platforms, the program's
149 socket receive timeout feature does not work; instead the pro‐
150 gram will report that it cannot set the receive timeout, and
151 will exit.
152 -v Display the program's version number, then exit.
154 -w cwd Specifies the working directory; shortly after starting the pro‐
156 gram changes its current working directory to this. If not
157 specified, this defaults to /.
158 interface_name
160 Specifies the name of the interface the program should use; this
161 argument is required. This must be an Ethernet interface which
162 is up and has been assigned an IP address.
163
165 After initialization, the program enters its main event loop, in which
166 it remains until you signal the program to exit with a SIGINT, SIGTERM,
167 or SIGQUIT.
168 The main event loop (a.k.a. the "probe cycle") consists of the follow‐
170 ing actions, repeated until the program receives a request to quit:
171 1. Handle any signals that have been received.
173 2. Install a pcap(3) filter to listen for UDP packets destined
175 to the BootP client port (UDP port 68).
176 3. Broadcast a DHCP or BootP request packet out the specified
178 interface.
179 4. Listen for response_wait_time milliseconds for any
181 responses received by the pcap(3) filter. (The
182 response_wait_time defaults to 5000 milliseconds (5 sec‐
183 onds), and may be changed in the dhcp_probe.cf(5) file.)
184 Any responses that contains a bootp_chaddr field not equal
186 to the chaddr used in the probe is ignored, as are any that
187 have incorrect bootp_htype or bootp_hlen fields. These are
188 not responses to our probe.
189 Any responses from known DHCP and BootP servers are
191 ignored. The IP source address for responses from each
192 known server is declared using a legal_server statement in
193 the dhcp_probe.cf(5) file. Any response with an IP source
194 address that does not appear in a legal_server statement is
195 treated as an unknown server.
196 The Ethernet source address for responses from each known
198 server is also optionaly declared using a
199 legal_server_ethersrc statement in the dhcp_probe.cf(5)
200 file. If at least one legal_server_ethersrc is specified,
201 then any response with an Ethernet source address that does
202 not appear in a legal_server_ethersrc statement is treated
203 as an unknown server. If no legal_server_ethersrc state‐
204 ments appear, then the response's Ethernet source address
205 is not checked. (The legal_server_ethersrc statement is
206 considered experimental in version 1.3.0, as it has
207 received only limited testing.)
208 For each response from an unknown server:
210 a) If the reponse packet contains a non-zero yiaddr field,
212 and one or more lease_network_of_concern statements were
213 specified, determine if the yiaddr value falls within
214 any of the "Lease Networks of Concern".
215 a) Log a message showing the response packet's source IP
217 and Ethernet addresses. If the response packet's yiaddr
218 is non-zero and falls within a "Lease Networks of Con‐
219 cern", the log message also reports that.
220 b) If the -o option was specified, the packet is also writ‐
222 ten to a packet capture file.
223 c) If an alert_program_name was specified in the
225 dhcp_probe.cf(5) file, that program is executed, with
226 the following arguments in order: the name of the call‐
227 ing program (e.g. dhcp_probe), the name of the inter‐
228 face on which the unexpected response packet was
229 received, the IP source address of the packet, and the
230 Ethernet source address of the packet. (We do not wait
231 for the alert_program_name to complete; it runs in a
232 child process.)
233 d) If an alert_program_name2 was specified in the
235 dhcp_probe.cf(5) file, that program is executed, with
236 the following required options:
237 -p the name of the calling program (e.g. dhcp_probe)
238 -I the name of the interface on which the unexpected response packet was received
239 -i the IP source address of the packet
240 -m and the Ethernet source address of the packet
241 If the response packet's yiaddr is non-zero and falls
242 within a "Lease Networks of Concern", the following
243 optional options are also passed:
244 -y the non-zero yiaddr value
245 (We do not wait for the alert_program_name2 to complete;
246 it runs in a child process.)
247 5. Remove the pcap(3) filter installed earlier.
249 6. If any signals have arrived requesting that we quit,
251 exit gracefully.
252 7. Repeat steps 2-6 for each flavor of DHCP and BootP
254 request packet the program supports (see PACKET FLAVORS
255 below).
256 8. Handle any signals that have been received.
258 9. Sleep for cycle_time seconds. (The cycle_time defaults
260 to 300 seconds, and and may be changed in the
261 dhcp_probe.cf(5) file.)
262 The pcap(3) filter the program installs normally does not specify that
264 the interface should be placed into promiscuous mode (although it is
265 possible the interface is already in promiscuous mode for some other
266 reason). However, if in the dhcp_probe.cf(5) file you specify a chaddr
267 or ether_src value other than the interface's actual hardware address,
268 then the pcap filter will specify that the interface should be placed
269 into promiscuous mode.
270 Although the filter used with pcap(3) specifies only UDP packets des‐
272 tined to port bootpc should be collected, on systems where bpf isn't
273 part of the kernel, pcap(3) must implement bpf as part of the applica‐
274 tion. This can increase the number of packets that must be passed from
275 the kernel to user space to be filtered. The program attempts to mini‐
276 mize the side-effects of this by removing the pcap(3) filter when it
277 isn't actually listening for responses. In particular, the filter is
278 not installed during the time the program sleeps between each probe
279 cycle (the cycle_time).
280 If you do specify an alert_program_name, take care that the program you
282 specify is safe for a privileged user to run; it is executed with the
283 same (i.e. root) privileges as the calling program.
284
286 No single request packet is likely to provoke a response from every
287 possible BootP and DHCP server. Some servers may only response to
288 either BootP, or DHCP, but not both. Some servers may be configured to
289 only respond to a small set of known clients. Some DHCP servers will
290 only provide leases to a small set of known clients, but may be willing
291 to respond (negatively) to unknown clients that request a lease renewal
292 on an inappropriate IP address. Therefore, dhcp_probe actually sends
293 not one, but five different flavor request packets, in the hopes of
294 provoking responses from a wider variety of unknown servers.
295 The packet flavors are:
297 BOOTPREQUEST
299 This packet is typical of a BootP client requesting an IP
300 address.
301 It will typically provoke a BOOTPREPLY from a BootP server will‐
303 ing to respond to any BootP client. (BootP servers configured
304 to only respond to a set of known clients may not respond.)
305 DHCPDISOVER (INIT)
307 This packet is typical of a DHCP client in the INIT state.
308 The options field contains a DHCP Message Type specifying
310 DHCPDISCOVER.
311 The options field contains a DHCP Client Identifier, which is
313 computed by prepending 0x'01' to the value of chaddr. (The
314 value chaddr is specified in the dhcp_probe.cf(5) file, other‐
315 wise it defaults to the interface's Ethernet address.)
316 This packet will typically provoke a DHCPOFFER from a DHCP
318 server willing to respond to any DHCP client. (DHCP servers
319 configured to only offer leases to a set of known clients may
320 not respond.)
321 DHCPREQUEST (SELECTING):
323 This packet is typical of a DHCP client in the SELECTING state;
324 i.e. a client which has previously issued a DHCPDISCOVER, then
325 received a DHCPOFFER from some DHCP server.
326 The options field contains a DHCP Message Type specifying
328 DHCPREQUEST.
329 The options field contains a DHCP Client Identifier, which is
331 computed by prepending 0x'01' to the value of chaddr. (The
332 value chaddr is specified in the dhcp_probe.cf(5) file, other‐
333 wise it defaults to the interface's Ethernet address.)
334 The options field contains a DHCP Server Identifier specifying
336 server_id, which should be an IP address that does not corre‐
337 spond to any valid DHCP Server Identifier on your network. (The
338 value server_id is specified in the dhcp_probe.cf(5) file, oth‐
339 erwise it defaults to 10.254.254.254.)
340 The options field contains a DHCP Requested IP Address specify‐
342 ing client_ip_address, which should be an IP address that does
343 not correspond to any valid IP address on your network. (The
344 value client_ip_address is specified in the dhcp_probe.cf(5)
345 file, otherwise it defaults to 172.31.254.254.)
346 This packet occassionally provokes a response from a broken DHCP
348 server that fails to respect the DHCP Server Identifier option.
349 DHCPREQUEST (INIT-REBOOT):
351 This packet is typical of a DHCP client in the INIT-REBOOT
352 state; i.e. a client which has obtained a DHCP lease in the
353 past, is bringing up its IP stack, and hopes to obtain (or
354 extend) a DHCP lease on the same IP address as in the past.
355 The options field contains a DHCP Message Type specifying
357 DHCPREQUEST.
358 The options field contains a DHCP Client Identifier, which is
360 computed by prepending 0x'01' to the value of chaddr. (The
361 value chaddr is specified in the dhcp_probe.cf(5) file, other‐
362 wise it defaults to the interface's Ethernet address.)
363 The options field contains a DHCP Requested IP Address specify‐
365 ing client_ip_address, which should be an IP address that does
366 not correspond to any valid IP address on your network; ideally
367 it should be one that is topologically inappropriate for your
368 network. (The value client_ip_address is specified in the
369 dhcp_probe.cf(5) file, otherwise it defaults to 172.31.254.254.)
370 If the Requested IP Address option is topologically inappropri‐
372 ate for your network, this packet may provoke a DHCPNAK from any
373 DHCP server that believes it is authoritative for the network's
374 IP topology.
375 DHCPREQUEST (REBINDING)
377 This packet is typical of a DHCP client in the REBINDING state;
378 i.e. a client which has obtained a DHCP lease which is between
379 its DHCP T2 and expiration time.
380 The options field contains a DHCP Message Type specifying
382 DHCPREQUEST.
383 The options field contains a DHCP Client Identifier, which is
385 computed by prepending 0x'01' to the value of chaddr. (The
386 value chaddr is specified in the dhcp_probe.cf(5) file, other‐
387 wise it defaults to the interface's Ethernet address.)
388 The ciaddr field contains client_ip_address, which should be an
390 IP address that does not correspond to any valid IP address on
391 your network; ideally it should be one that is topologically
392 inappropriate for your network. (The value client_ip_address is
393 specified in the dhcp_probe.cf(5) file, otherwise it defaults to
394 172.31.254.254.)
395 If the value of ciaddr is topologically inappropriate for your
397 network, this packet will provoke a DHCPNAK from any DHCP server
398 that believes it is authoritative for the network's IP topology.
399 All the request packets sent by the program share the following common
401 characteristics:
402 Ethernet Header
404 destination: ff:ff:ff:ff:ff:ff
405 source: ether_src from dhcp_probe.cf(5), else interface hard‐
406 ware address
407 type: ETHERTYPE_IP (0x0800)
408 IP Header
410 version: 4
411 header length: 5
412 tos: 0
413 total length: 328 (20-byte IP header + 8-byte UDP header +
414 300-byte BootP/DHCP payload)
415 identifier: 1
416 flags: 0
417 fragment offset: 0
418 ttl: 60
419 protocol: IPPROTO_UDP (17)
420 header checksum: (computed)
421 source address: 0.0.0.0
422 destination address: 255.255.255.255
423 options: (none)
424 UDP Header
426 source port: PORT_BOOTPC (68)
427 dest port: PORT_BOOTPS (67)
428 checksum: (computed)
429 BootP/DHCP Payload
431 op: BOOTREQUEST (1)
432 htype: HTYPE_ETHER (1)
433 hlen: HLEN_ETHER (6)
434 hops: 0
435 xid: 1
436 secs: 0
437 flags: 0
438 ciaddr: 0.0.0.0 (except for DHCPREQUEST (REBINDING) packets
439 it is client_ip_address from dhcp_probe.cf(5), else
440 172.31.254.254)
441 siaddr: 0.0.0.0
442 giaddr: 0.0.0.0
443 chaddr: chaddr from dhcp_probe.cf(5), else interface hardware
444 address
445 sname: (all 0's)
446 file: (all 0's)
447 options: RFC1048 cookie (0x63825363), possibly followed by
448 DHCP options, followed by END option (0xFF), followed by PAD
449 options (0x00) to bring the field to 64 bytes
450
452 Although dhcp_probe only supports monitoring a single physical inter‐
453 face, you may run an instance of the program on each physical inter‐
454 face; each monitors a different physical network.
455 When running multiple copies of dhcp_probe, be sure to specify a dif‐
457 ferent pid_file for each instance.
458 If you specify a log_file and/or a capture_file, be sure to specify a
460 different one for each instance.
461 You may specify a different config_file for each instance. If you
463 don't need to customize the settings in that file for each instance,
464 you may use the same configuration file for all instances.
465 If you have multiple logical interfaces on the same physical interface,
467 or multiple logical IP networks running on a single physical network,
468 there is no need to run multiple instances of dhcp_probe to monitor
469 each logical interfaces or logical network. A single instance of the
470 program running on a physical interface is sufficient to provoke any
471 servers on that physical network that might be willing to respond.
472 If your physical interface supports 802.1Q, you can use a single physi‐
474 cal interface to monitor multiple VLANs. Use your operating system to
475 create a logical interface on each VLAN, then run an instance of the
476 program on each logical interface. Since the program is responsible
477 for constructing Ethernet frame headers, you will probably need to
478 specify the -Q option to instruct it to add to outgoing frames an
479 802.1Q VLAN header with the appropriate VLAN ID.
480
482 The program will respond to a number of signals:
483 SIGUSR1
485 If logging to a file, close and re-open it. If the program is
486 in the middle of a probe cycle, handling the signal is deferred
487 until the end of the cycle. (Has no effect if logging to sys‐
488 log(3) or if the -f option was specified.)
489 SIGUSR2
491 If capturing to a file, close and re-open it. If the program is
492 in the middle of a probe cycle, handling the signal is deferred
493 until the end of the cycle. (Has no effect if the -o option was
494 not specified.)
495 Because re-opening the capture file causes the file to be trun‐
497 cated and a new pcap(3) header to be written to it, if you want
498 to save the prior contents of the capture file, move the exist‐
499 ing capture file aside before sending the signal.
500 SIGHUP Reread the configuration file. If the program is in the middle
502 of a probe cycle, handling the signal is deferred until the end
503 of the cycle.
504 SIGTERM, SIGINT, SIGQUIT
506 Exit gracefully. If the program is in the middle of a probe
507 cycle, handling the signal is deferred until the program fin‐
508 ishes sending and receiving responses for the current flavor
509 request packet.
510
512 Most rogue BootP/DHCP servers distribute private IP addresses to
513 clients, or send DHCPNAK messages to legitimate clients. Some even
514 more disruptive rogue BootP/DHCP servers may distribute IP addresses
515 that fall within your own networks' IP ranges. The "Lease Networks of
516 Concern" feature is intended to help you identify these particularly
517 disruptive servers.
518 You may activate the feature by specifying the lease_network_of_concern
520 statement in your configuration file. Use the statement multiple times
521 to specify all your legitimate network ranges.
522 When a rogue BootP/DHCP server is detected, if the rogue's response
524 packet contains a non-zero yiaddr value, the value is compared to the
525 "Lease Networks of Concern" you specified. If the value falls within
526 any of those network ranges, the message logged by dhcp_probe is
527 extended to make note of this, and to report the yiaddr value. Fur‐
528 thermore, if you are using the alert_program_name2 feature, the alert
529 program is called with an extra -y yiaddr option so that alert program
530 can take any additional action desired.
531
533 The program produces increasingly detailed output as the debuglevel
534 increases. Under normal circumstances, you can run at debuglevel 0.
535 Here's roughly what messages are added at each debuglevel.
536 0 Display the IP source (and Ethernet source) of each unexpected
538 DHCP or BootP response packet.
539 Startup and shutdown notice.
541 Non-fatal errors in the configuration file.
543 Fatal errors.
545 1 At startup, show some information about the program's configura‐
547 tion.
548 2 Show each time we start and finish (re-)reading the configuration
550 file.
551 Show each time we close and re-open the logfile or capture file.
553 Report on response packets that could not be parsed (e.g. trun‐
555 cated).
556 3 Each time we (re-)read the configuration file, echo the informa‐
558 tion we obtain from it.
559 7 For each parsable response packet, show the Ethernet source and
561 destination, the IP source and destination, and indicate when the
562 IP source is a legal (known) server.
563 11 For each probe cycle, show when the cycle begins and ends, when
565 we write a packet, and when we begin and end listening for
566 response packets.
567
569 The program was written by Irwin Tillman of Princeton University's OIT
570 Network Systems Group. It was written to run on Solaris, relying on
571 the generally-available pcap(3) and libnet(3) libraries.
572
574 /etc/dhcp_probe.cf
575 Configuration file read by the program. See dhcp_probe.cf(5).
576 The name of this file can be overriden by a command-line option.
577 /etc/dhcp_probe.pid
579 Contains the program's processid. The name of this file can be
580 overriden by a command-line option.
581
583 dhcp_probe is not guaranteed to locate all unknown DHCP and BootP
584 servers attached to a network. If a BootP server is configured so it
585 only responds to certain clients (e.g. those with certain hardware
586 addresses), it will not respond to the BOOTPREQUEST packet we sent. If
587 a DHCP server is configured so it only responds to certain clients
588 (e.g. those with certain hardware addresses or DHCP Client Identi‐
589 fiers), it will not respond to the packets we send that mimic DHCP
590 clients in the INIT state. If a DHCP server is configured so it does
591 not send DHCPNAK packets to clients requesting topologically-inappro‐
592 priate IP addresses, it will not respond the packets we send that mimic
593 DHCP clients in the INIT-REBOOT and REBINDING states.
594 The upshot is that it is possible that dhcp_probe will be unable to
596 provoke some BootP and DHCP servers into responding at all.
597 Flushing out such servers can be extremely difficult. One approach is
599 to capture all UDP/IP packet destined to the BootP client port which
600 cross your network; since most of these packets are unicast at Layer 2,
601 capturing is only effective if all such packets must pass by your cap‐
602 ture device's Ethernet interface (e.g. the capture device is located at
603 a network choke point, or the network does not involve any Layer 2
604 switching). Another approach is to do UDP port scanning for all
605 devices listening on the BootP server port, and assume that those which
606 are listening on that port are running a BootP or DHCP server.
607 Malicious BootP or DHCP servers that forge the IP source address (and
609 possibly the Ethernet source address) of their responses to match the
610 values specified by legal_server and legal_server_ethersrc statements
611 will not be detected.
612
614 The packet capture buffer size is limited; if a single request packet
615 provokes more responses than will fit into the buffer, those that do
616 not fit are silently dropped, without any diagnostic indicating that
617 the buffer was too small. You can adjust the size of the packet cap‐
618 ture buffer size using the -s capture_bufsize option.
619 We do not support non-Ethernet interfaces.
621 Because (re-)opening a packet capture file causes the file to be opened
623 for writing (not appending), the contents of any existing packet cap‐
624 ture file of the same name is lost when the program starts or receives
625 a SIGUSR2 signal. If the file's previous contents should be preserved,
626 move the old file aside before starting the program or sending it a
627 SIGUSR2 signal. (This "feature" exists because opening a pcap(3) save‐
628 file always involves writing a pcap header record to the start of the
629 file, so pcap always opens the file using mode "w".)
630 Because pcap(3) opens the packet capture file with a simple fopen(3)
632 without checking to see if the file already exists, dhcp_probe may be
633 tricked into overwriting or corrupting an existing file. As dhcp_probe
634 is run with root privileges, this is a serious concern. To avoid this
635 problem, if you use the -o option, ensure that the directory that will
636 contain the capture file is writable only by root.
637 The packet capture file that is written is unparseable after the first
639 packet. E.g. if read with tcpdump(8), it reports: tcpdump: pcap_loop:
640 truncated dump file.
641 On platforms where pcap(3) is unable to support the timeout argument to
643 pcap_open_live, the program may not reliably detect responses from DHCP
644 and BootP servers, or may not function at all.
645
647 dhcp_probe.cf(5)
648 pcap(3) (a.k.a. libpcap, a packet capture library), available from
650 http://www.tcpdump.org. (An older version is available from
651 ftp://ftp.ee.lbl.gov/libpcap.tar.Z.)
652 libnet(3) (a.k.a libwrite, a packet writing library), available from
654 http://www.packetfactory.net/libnet
655Princeton Univ. Mar 9 2009 DHCP_PROBE(8)