DHCP_PROBE(8)

📦
version 1.3.1 · 3 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

💖 dhcp_probe — the DHCP_PROBE(8) manual, but make it make sense 💖

okay bestie, buckle up — this is the System Manager's Manual page for dhcp_probe, and by the end of it you're gonna be sniffing out rogue DHCP servers like it's your job (because, lowkey, it is).

✨ 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 🦋

So here's the tea: dhcp_probe goes out there and tries to discover DHCP and BootP servers sitting on a directly-attached Ethernet network. If you're a network administrator, this is your little detective tool for finding unauthorized DHCP and BootP servers. 🚨

Heads up: the program must be run with root privilege. No root, no vibes. 💅

The program periodically broadcasts a whole bunch of DHCP and BootP request packets out of a single physical interface. And why several kinds, you ask? Because a DHCP or BootP server might only respond to certain requests depending on how it's configured. So basically, dhcp_probe is cosplaying as a BootP or DHCP client in a bunch of different possible states, trying to provoke responses out of servers. main character energy, honestly. 🎭

After sending each request packet, dhcp_probe listens for responses. Then it filters out the responses that don't look like they're actually answering the probe, plus responses from known DHCP and BootP servers (those are identified by their IP source addresses, and optionally by their Ethernet source addresses). Whatever's left — any responses from unknown servers — gets logged. 👑

Optionally, responses from unknown servers can also be written out to a packet capture file. 📦

Optionally, an external program can be called every single time a response from an unknown server comes in. 🔔

Fair warning: dhcp_probe may not be able to locate all DHCP and BootP servers — peep LIMITATIONS below for that whole situation.

Okay so, DHCP broadcasts don't ordinarily cross IP routers. Which means dhcp_probe will only find servers attached to the same physical network as the interface you named on the command line. Now, BootP Relay Agents running on that network might help broadcasts cross IP routers, but those agents are typically configured to convert broadcasts into unicasts aimed only at the well-known DHCP or BootP servers on other physical networks. So the result is: BootP Relay Agents will let the servers receive the requests dhcp_probe issues, but they will not make remote unknown servers hear those requests. 😭 Therefore, if you've got multiple physical networks, you may wanna run dhcp_probe on each one of them so you can discover unknown DHCP and BootP servers on each. 🌈

dhcp_probe functions on a single Ethernet interface specified on the command line — it does not listen on multiple interfaces. That said, if your host has multiple physical or logical interfaces, you can just run one instance of dhcp_probe on each physical or logical interface. And 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. scalable queen 🧚

dhcp_probe is intended for use by a network administrator. And fr fr — before you run dhcp_probe on any network other than one you're responsible for, contact that network's administrator and find out if it's acceptable for you to run this software there. Running this software on a network where you don't have permission may violate that network's acceptable use policy. 🙈 Don't do it, bestie.

🌟 AVAILABILITY 🌟

dhcp_probe is a product of the Network Systems Group at Princeton University's Office of Information Technology, and it's available from:

https://www.net.princeton.edu/software/dhcp_probe/

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

👑 OPTIONS 👑

  • -c config_file — Specifies the configuration file. If you don't specify one, this defaults to /etc/dhcp_probe.cf. The configuration file is read at startup, and it gets re-read whenever a SIGHUP is received. See dhcp_probe.cf(5). 📄
  • -d debuglevel — Sets the debuglevel variable, which controls how many debugging messages get 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're 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, since 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 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.) 🏷️
  • -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. Typically this interface must also have an IP address assigned; specifying do_not_lookup_enet_and_ip_addresses in dhcp_probe.cf(5) may allow the program to operate on an interface which lacks an IP address. 🔌

✨ OPERATION ✨

okay so after initialization, the program enters its main event loop, and it stays there until you signal it to exit with SIGINT, SIGTERM, or SIGQUIT. periodt.

The main event loop (a.k.a. the "probe cycle") is literally these actions on repeat until the program gets 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. (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 optionally 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 versions 1.3.0 - 1.3.1, as it has received only limited testing.) 🧪

For each response from an unknown server: 🚨

  • a) If the response 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.) 👶

  1. Remove the pcap(3) filter installed earlier. 🧹
  2. If any signals have arrived requesting that we quit, exit gracefully. 🚪
  3. Repeat steps 2-6 for each flavor of DHCP and BootP request packet the program supports (see PACKET FLAVORS below). 🔁
  4. Handle any signals that have been received. 💅
  5. 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). 💤

⚠️ bestie warning: 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 🎀

okay bestie, here's the tea: no single request packet is gonna make every BootP and DHCP server on the planet reply to you. like, that's just not how it works. some servers only answer BootP, some only answer DHCP, never both. some are configured to only talk to a tiny little guest list of known clients. and some DHCP servers will only hand out leases to known clients, but they might still clap back (negatively) at unknown clients trying to renew a lease on some nonsense IP address.

so dhcp_probe doesn't send one packet — it sends FIVE different flavor packets, all in the hopes of provoking replies from a way wider variety of unknown servers. five courses, one vibe check. 💅

the packet flavors are:

🦋 BOOTPREQUEST

this one is your classic BootP client asking for an IP address.

it'll typically provoke a BOOTPREPLY from a BootP server that's willing to respond to literally any BootP client. (bootp servers configured to only respond to a set of known clients? yeah they might just ghost you. 🙈)

🦋 DHCPDISOVER (INIT)

this one is your typical DHCP client chilling 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 is your typical DHCP client in the SELECTING state — i.e. a client that already sent out a DHCPDISCOVER, then got a DHCPOFFER back from some DHCP server. main character who already got noticed. ✨

  • 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 occasionally provokes a response from a broken DHCP server that fails to respect the DHCP Server Identifier option. messy of them, honestly.

🦋 DHCPREQUEST (INIT-REBOOT):

this is your typical DHCP client in the INIT-REBOOT state — i.e. a client that got a DHCP lease in the past, is bringing its IP stack back up, and is hoping to grab (or extend) a DHCP lease on the same IP address it had before. it's giving "hey remember me?? 🥺"

  • 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 is your typical DHCP client in the REBINDING state — i.e. a client whose DHCP lease is somewhere between its DHCP T2 and expiration time. clock's ticking bestie ⏰

  • 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. (note: will, not may. she commits. 👑)

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 🌈

okay so dhcp_probe only supports monitoring a single physical or logical interface — that's the limit, no cap. BUT you can totally run an instance of the program on each physical or logical interface, and each one monitors a different network. one girlie per party. 🫶

when you're running multiple copies of dhcp_probe, be sure to specify a different pid_file for each instance. fr fr, don't skip this one.

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

you may specify a different config_file for each instance. and if you don't need to customize the settings in that file per-instance, you can just use the same configuration file for all instances. sharing is caring. 💖

now, here's the part where people do extra work for no reason: if you've got 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 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. periodt. 💅

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. we see you. 👀)

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. this one bites, bestie — double check before you send it. 💀

✨ SIGNALS ✨

bestie, dhcp_probe is so responsive to signals, it's giving main character energy 🎀. Here's the whole vibe:

  • SIGUSR1 — if you're logging to a file, it closes that file and re-opens it. 🫶 And if the program is mid-probe-cycle when the signal lands? It waits, like a polite queen, and handles it at the end of the cycle. (Heads up: this does nothing if you're logging to syslog(3), or if the -f option was specified. 💅)
  • SIGUSR2 — if you're capturing to a file, it closes and re-opens it. Same deal — if a probe cycle is in progress, handling is deferred until the end of the cycle. (No effect if the -o option was not specified, iykyk.)
⚠️ okay so this one matters: re-opening the capture file truncates it and writes a fresh pcap(3) header to it. So if you want to keep the old contents of the capture file, move the existing capture file aside before you send the signal. fr fr, don't skip this step 😭
  • SIGHUP — rereads the configuration file. 🔁 If the program is in the middle of a probe cycle, handling is deferred until the end of the cycle.
  • SIGTERM, SIGINT, SIGQUIT — exits gracefully. 🌈 And if a probe cycle is happening, handling is deferred until the program finishes sending and receiving responses for the current flavor request packet. so chill, it finishes its sentence first ✨

💜 LEASE NETWORKS OF CONCERN 💜

okay so picture this: most rogue BootP/DHCP servers hand out private IP addresses to clients, or they send DHCPNAK messages to legit clients. Rude. 😤 But some rogue BootP/DHCP servers are extra disruptive and may distribute IP addresses that fall within your own networks' IP ranges. The "Lease Networks of Concern" feature exists to help you spot these particularly chaotic servers. 👑

You activate it by specifying the lease_network_of_concern statement in your configuration file. Use the statement multiple times to spell out all your legitimate network ranges. 💅

When a rogue BootP/DHCP server gets detected, and the rogue's response packet contains a non-zero yiaddr value, that value gets compared against 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 note this and to report the yiaddr value. 🦋 And on top of that — if you're using the alert_program_name2 feature, the alert program gets called with an extra -y yiaddr option, so that alert program can take whatever additional action it wants. slay.

🌸 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 get 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. iconic.

🎀 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 💀

ngl, dhcp_probe is not guaranteed to locate all unknown DHCP and BootP servers attached to a network. Here's the tea:

  • 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 to the packets we send that mimic DHCP clients in the INIT-REBOOT and REBINDING states.

The upshot? It's 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 packets 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. 💀

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

🐛 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. And since 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 🌈

⭐ TRADEMARKS ⭐

Cisco Nexus(R) is a trademark of Cisco Systems.

okay bestie that's the whole page, you ate it, periodt 💅✨ — this fine piece of documentation is from Princeton Univ., dated Jan 18 2021, and it's the DHCP_PROBE(8) manual page. go probe some rogue servers responsibly, love u 🫶🎀

📦 where this page comes from