File:  [ELWIX - Embedded LightWeight unIX -] / embedaddon / dhcdrop / man / dhcdrop.8
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Feb 21 22:25:35 2012 UTC (12 years, 7 months ago) by misho
Branches: dhcdrop, MAIN
CVS tags: v0_5, HEAD
dhcdrop

.TH DHCDROP 8 "18/08/2009" 
.SH NAME
dhcdrop \- program for searching and suppress false DHCP servers in Ethernet. 
.SH SYNOPSIS
.BI "dhcdrop 
.RB [ " \-h "]
.RB [ " \-D "]
.RB [ " \-t "]
.RB [ " \-y "]
.RB [ " \-r "]
.RB [ " \-b "]
.RB [ " \-a "]
.RB [ " \-A "]
.RB [ " \-f "]
.RB [ " \-R "]
.RB [ " \-q "]
.LP
.RB [ " \-m "
.I count
]
.RB [ " \-c "
.I count
]
.RB [ " \-n " 
.I hostname
]
.RB [ " \-N "
.I clientname
]
.RB [ " \-p "
.I port
]
.RB [ " \-P "
.I port
]
.RB [ " \-w "
.I seconds
]
.LP
.RB [ " \-T "
.I timeout
]
.RB [ " \-M "
.I max-hosts-scan
]
.RB [ " \-l "
.I MAC-address
]
.RB [ " \-L "
.I network
]
.RB [ " \-S "
.I network/mask
]
.RB [ " \-F "
.I from-IP
]
.LP
.RB [ " \-s "
.I server-IP
]
.RB [ " \-C "
.I children count (2 - 32)
]
.LP
.RB [ " \initial-MAC-address " ]
.RB < " \-i "
.I interface-name|interface-index
>
.LP
.SH DESCRIPTION
Suppressing DHCP server is made by
.B dhcdrop
with a help of an attack DHCP 
starvation or with a help of flooding with DHCPDISCOVER messages. 
Look for details below. Besides dhcdrop can be used as a diagnostical 
tool and stress-testing when setting and developing DHCP servers
.SH OPTIONS
.TP
.B "-h"
prints help-message and also codes of program's return.
.TP
.B "-D"
list of available network interfaces. Format - index:name.
.TP
.B "-t"
test mode. Using this mode 
.B dhcdrop
does not execute suppression of server. DHCPDISCOVER is being sent. 
If the answer comes to it from the non\-ignored server then the program is 
completes returning code 200 and printing the string: 
.IP
DHCP SRV: 10.7.7.1 (IP-hdr: 10.7.7.1) SRV ether: 00:02:44:75:77:E4, YIP: 10.7.7.205
.IP
which consists of the MAC address of found false DHCP server.
.TP
.B "-y"
answer 'yes' to all questions.
.TP
.B "-r"
disable ethernet address randomize. Every further source MAC address differs from previous for 1.
.TP
.BI "-b"
points on necessity of using flag  
.B BROADCAST
in DHCP packets sent.
.TP
.B "-a"
always wait for server's response to default DHCP client port (68) even if a 
number of client's port set differs from default value.
.TP
.B "-A"
always wait for server's response from default DHCP server port (67), 
even if a number of client's port set differs from default value.
.TP
.B "-f"
flood mode with DHCPDISCOVER requests. SHOULD BE USED ATTENTIVELY. 
It is convenient for stress-testing of the server. 
In case of using option 
.B "-r"
all the packets sent have the same MAC address.
.TP
.BI "-R"
send DHCPRELEASE from source MAC address specified by 
.B "<initial MAC address>"
and IP address specified by option 
.B "-F" 
to server specified by option 
.B "-s"
.
.TP
.B "-q"
quiet mode.
.TP
.BI "-m" " count" 
maximum number of attempts to receive answer from DHCP server. (default: 5).
.TP
.BI "-c" " count"
maximum number of receiving addresses from DHCP server (default: 255).
.TP
.BI "-n" " hostname"
value of DHCP-option 'HostName' (default: 'DHCP-dropper').
.TP
.BI "-N" " clientname"
value of DHCP-option 'Vendor-Class' (default: 'DHCP-dropper').
.TP
.BI "-p" " port"
set client port value (default: 68).
.TP
.BI "-P" " port"
set server port value (default: 67).
.TP
.BI "-w" " seconds"
set timeout after which the process will be restarted when using 
agressive mode (see option 
.B "-L"
) (default: 60 secs).
.TP
.BI "-T" " timeout"
set timeout of waiting server response in seconds (default: 3).
.TP
.BI "-M" " maximum-hosts"
maximum number of hosts scanned if agressive mode used (option -L).
.TP
.BI "-l" " MAC-address"
ethernet address of DHCP server which need to ignore. 
May be several servers. Need option
.B -l
for each server.
.TP
.BI "-L" " legal-network"
specify legal network(s) on interfase. May be
several networks. If this parameter is set, dhcdrop
uses agressive mode: it scans address range assigned
by DHCP server for searching hosts with incorrect addresses,
sends DHCPRELEASE to server from every found host after
this it restarts process of receiving addreses. Need option
.B -L
for each network.
.TP
.BI "-S" " network/mask"
ARP-scan for network 'network' with network mask 'mask' (CIDR notation). 
Source IP address for scanning specified by option 
.B -F
. 
If source IP is not set - using random IP address from network address range. 
.TP
.BI "-F" " source-ip"
source IP for scanning network or sending DHCPRELEASE (see option  
.B -S
and 
.B -R
).
.TP
.BI "-s" " server-ip-adress"
specify DHCP server IP address. Used with option 
.B -R
.
.TP
.BI "-C" " count"
children number (default: 0, minimal value: 2, maximum: 32). Compatible only with flag  
.B -f
. 
.TP
.B "initial-MAC-address"
specify source MAC address for sending first DHCP message.
If address not set - used random value.
.TP
.BI "-i" " interface"
defines network interface, can be name or index (cannot be 'any'). 
For listing available interfaces use option 
.B -D
.
.SH THEORETICAL BASICS
In DHCP protocol there is an option which specifies duration of leasing an IP address 
(Lease Time). During this time DHCP server gives IP address for client's use. 
After this time period a client have to make an attempt to refresh IP address 
for the purpose of extension the lease. For the server giving out IP address in 
lease means that during the lease this IP address can be given only to an owner 
of the lease and nobody else. Identification of clients is usually done by the 
server on the ground of MAC address. Usually every server has a pool of dynamic 
IP addresses. These are addresses which are not assigned to concrete MAC addresses 
and are given dynamically after any client's request. Pool on SOHO routers with 
default settings is not very big - from tens to about 200 addresses. In case 
of using software which performs the function of DHCP server the size of the pool 
is defined by the one who sets. If the pool of addresses is over then DHCP server 
ignores the requests from new clients (probably documenting this in logs). 
Actually it's not in action.

Thereby in case of appearance false DHCP they can be supressed rather easy. 
It's necessary to receive lease for every IP address available on this server 
sending requests from unique clients every time. The more Lease Time is in server 
settings, the bigger period of DHCP server suppression in case of exhaustion of 
dynamical pool is. For most of SOHO routers Lease time comes to a number of days 
or even weeks. In case of using WinGate, dhcpd and other similar soft as DHCP 
server the lease time depends on the fantasy of the man who launched false DHCP server.
.SH PRINCIPLE OF DHCDROP OPERATION
The program opens the interface specified in command line options using promiscuous 
mode then forms DHCP message (DHCPDISCOVER) using random source MAC address 
(if another conduct isn't specified) and sends it to the interface:

.nf
01:58:04.681600 00:70:de:3b:b9:05 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), 
length 342: (tos 0x10, ttl 64, id 33964, offset 0, flags [none], 
proto UDP (17), length 328) 
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:70:de:3b:b9:05, 
length 300, xid 0xcc1cfc5c, Flags [none]
          Client-Ethernet-Address 00:70:de:3b:b9:05
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Parameter-Request Option 55, length 3:
              Domain-Name-Server, Default-Gateway, Subnet-Mask
            Hostname Option 12, length 12: "DHCP-dropper"
            Vendor-Class Option 60, length 12: "DHCP-dropper"
            Client-ID Option 61, length 7: ether 00:70:de:3b:b9:05
.fi

After this it starts to wait for server's answer (DHCPOFFER). If the answer with 
offering IP address lease is received then the next DHCP message (DHCPREQUEST) 
is send to the interface. On this message server answers with DHCPACK-packet 
which confirms the possibility of using the IP address by a client. 
This completes the operation of receiving IP address suggested by the server. 
The program changes source MAC address and sends DHCPDISCOVER again. 
After that all the above operations of receiving the lease of a new 
IP address are repeated. It's worth paying attention that the program 
changes not only the client's MAC address in DHCP message but also the 
MAC address in the header of Ethernet-frame. This possibility brings the work 
of the program maximally nearer to the work of real DHCP client (and also 
allows to avoid DHCP snooping).

Cycle of receiving IP addresses from server comes to an end when the maximum 
number of IP addresses set by the option is received or in case of exhausting 
dynamical pool of the server. In the second case you gained a victory. 
In the first case if you have an aim to reject the DHCP server then there 
is a point to set another value of maximum number of leased address option.
.SH USAGE OF THE PROGRAM
\fIInterfaces listing\fP
.sp
First of all it's necessary to understand how the network interface, 
where there is DHCP server, is called. This is easy to understand in UNIX-like OS 
by outputting ifconfig command. But in Windows OS it is not so evident. 
Because of this let's launch the program with  
.B -D
option first of all:

.nf
C:\>dhcdrop -D
Available interfaces:
1:\\Device\\NPF_GenericDialupAdapter
  descr: Adapter for generic dialup and VPN capture
2:\\Device\\NPF_{0C796DB5-22D9-46AB-9301-9C7ADC2304AF}
  descr: ZyXEL GN650 1000Base-T Adapter          (Microsoft's Packet Scheduler)
  iaddr: 192.168.1.2/24  bcast: 255.255.255.255
  iaddr: 10.7.7.7/24  bcast: 255.255.255.255
.fi

According to the output information it's evident that we need the second interface. 
As an argument for program's option 
.B -i
any index of the second interface or its name 
.B "\\\\Device\\\\NPF_{0C796DB5-22D9-46AB-9301-9C7ADC2304AF}"
can be set. To my mind it's more easy to use index and to launch the 
program with pointing index instead of a name. For example: 
.B dhcdrop -i 2

\fIInteractive mode, by default\fP
.sp
The easiest way of using the program for searching and choosing the rejected 
server manually:

.nf
$ sudo dhcdrop -i eth1
Using interface: 'eth1'
Got response from server 10.7.7.1 (IP-header 10.7.7.1), server ethernet address: 00:02:44:75:77:E4, lease time: 1.1h (3960s)
Got BOOTREPLY (DHCPOFFER) for client ether: 00:16:09:D8:CF:60 You IP: 10.7.7.201/24
Drop him? [y/n] n
Searching next server...
Got response from server 192.168.1.1 (IP-header 192.168.1.1), server ethernet address: 00:1E:2A:52:C8:CA, lease time: 24h (86400s)
Got BOOTREPLY (DHCPOFFER) for client ether: 00:16:09:D8:CF:60 You IP: 192.168.1.2/24
Drop him? [y/n] y
1. Got BOOTREPLY (DHCPACK) for client ether: 00:16:09:D8:CF:60 You IP: 192.168.1.2/24
2. Got BOOTREPLY (DHCPACK) for client ether: 00:A2:FA:12:41:F7 You IP: 192.168.1.3/24
3. Got BOOTREPLY (DHCPACK) for client ether: 00:56:EA:F8:1C:B0 You IP: 192.168.1.4/24
4. Got BOOTREPLY (DHCPACK) for client ether: 00:EA:91:1A:C8:A8 You IP: 192.168.1.5/24
5. Got BOOTREPLY (DHCPACK) for client ether: 00:83:8A:25:C7:1C You IP: 192.168.1.6/24
6. Got BOOTREPLY (DHCPACK) for client ether: 00:CA:A7:FF:C1:70 You IP: 192.168.1.7/24
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Finished.
.fi

As it's seen from the example when receiving an answer from DHCP server  
.B dhcdrop 
reports information from the server about given IP address and asks of necessity 
to suppress this server. Receiving a negative answer it goes on searching for 
servers in the network ignoring the server discovered before. In case of 
receiving a positive answer it starts a process for rejecting the server with a 
method shown above.
 
\fIAutomatical suppresion mode of all the servers except the legitimate one\fP
.sp
In case of knowing (and usually we know) MAC address of the legal DHCP server in our 
network the operation of suppressing illegal servers can be simplified:

.nf
$ sudo dhcdrop -i eth1 -y -l 00:02:44:75:77:E4
Using interface: 'eth1'
Got response from server 192.168.1.1 (IP-header 192.168.1.1), server ethernet address: 00:1E:2A:52:C8:CA, lease time: 24h (86400s)
Got BOOTREPLY (DHCPOFFER) for client ether: 00:37:C5:10:BE:16 You IP: 192.168.1.2/24
1. Got BOOTREPLY (DHCPACK) for client ether: 00:37:C5:10:BE:16 You IP: 192.168.1.2/24
2. Got BOOTREPLY (DHCPACK) for client ether: 00:94:26:88:33:BD You IP: 192.168.1.3/24
3. Got BOOTREPLY (DHCPACK) for client ether: 00:E5:AC:7B:79:BB You IP: 192.168.1.4/24
<skipped>
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Finished.
.fi

In this version of using  
.B dhcdrop 
rejects any server except that ones states with 
.B -l 
option without asking additional questions (due to using option 
.B -y
).

\fITest mode\fP
.sp
Test mode (
.B -t
) is comfortable to use for execution the program from code in computer-aided mode. 
An example of the simplest code is below: 

.nf
00 #!/bin/bash
01 LEGAL_SERVER="00:11:22:33:44:55"	
02 DROPPER="/usr/sbin/dhcdrop"
03 IFNAME="eth1"

04 $DROPPER -i $IFNAME -t -l $LEGAL_SERVER -m 3

05 if [ $? = 200 ]
06 then
07    echo Illegal server found\! Dropping him\!
08    $DROPPER -i eth1 -l $LEGAL_SERVER -y
09 else
10    echo Illegal server not found.
11 fi
.fi

In the forth line launching of 
.B dhcdrop 
is being executed in a test mode with setting an option of legal DHCP server 
for the network (
.B -l
), an option of testing (
.B -t
) and an option of setting maximum number of attempts of sending DHCPDISCOVER 
in mode of searching the server (
.B -m).
If there is no answer for all the requests been sent then the program 
ends with 0 code. If there is answer for the server without 
.B -l
option then the program ends with 200 code which leads to the further
launching of the program with options describing suppression of any DHCP server 
in the network except the legal one.

\fIUsage of aggressive mode for receiving addresses\fP
.sp
As you can guess from the description of DHCP protocol - if a client received 
the configuration from illegal DHCP server then the server wouldn't give 
this configuration iteratively to another client until the period of lease expires. 
So a simple exhaustion of IP addresses' pool won't save clients who have already 
received incorrect configuration. The server will give these addresses only to 
the clients who requested them initially and will ignore requests from 
.B dhcdrop
. When trying to refresh the address once more the clients will receive 
information from illegal DHCP server again and it would be continued until 
illegal DHCP server switched off. For solving such a problem there were added 
the aggressive mode of receiving IP addresses in dhcdrop starting with version 0.5.
It is activated with
.B -L
option which points a legitimate IP subnet for the given Etherner segment of the network. 
Here is the algorithm of its operation: 
.B dhcdrop
launches an ordinary mode of suppression and exhausts the whole IP addresses' 
pool of illegal DHCP server. Analyzes the first DHCPOFFER received from illegal 
DHCP, with a help of the network mask and client's IP address given out by the 
server receives the address of IP network attended by this server. 
Launches ARP-scanning of received subnet for the purpose of exposing hosts 
which received incorrect configurational information, default number of scanned 
hosts is limited to 512 (can be changed with
.B -M
option), some servers gives out configurational set with a mask /8 which 
conforms to approximately 16 million of hosts - scanning of such an address range 
will take a lot of time. Sends messages DHCPRELEASE to the DHCP server from every 
found host (except the server itself). Waits 60 seconds 
(default value can be changed with
.B -w
option), after then restarts the process of receiving IP addresses.
As an example let's launch
.B dhcdrop
with the same options as in the previous example but 
additionally state legal IP network 10.7.7.0:

.nf
$ sudo dhcdrop -i eth1 -y -l 00:02:44:75:77:E4 -L 10.7.7.0
Using interface: 'eth1'
Got response from server 192.168.1.1 (IP-header 192.168.1.1), server ethernet address: 00:1E:2A:52:C8:CA, lease time: 24h (86400s)
Got BOOTREPLY (DHCPOFFER) for client ether: 00:BC:BF:D6:39:2E You IP: 192.168.1.5/24
1. Got BOOTREPLY (DHCPACK) for client ether: 00:BC:BF:D6:39:2E You IP: 192.168.1.5/24
2. Got BOOTREPLY (DHCPACK) for client ether: 00:FB:E7:A4:19:EC You IP: 192.168.1.6/24
3. Got BOOTREPLY (DHCPACK) for client ether: 00:CB:44:F9:A8:6F You IP: 192.168.1.7/24
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Trying to use agressive mode.
Starting ARP scanning network in range: 192.168.1.0 - 192.168.1.255...
Illegal DHCP server perhaps assigned IP adresses to the following hosts:
1. Received ARP-reply from: 00:1e:2a:52:c8:ca (192.168.1.1) - itself DHCP server.
2. Received ARP-reply from: 00:03:ff:15:52:90 (192.168.1.3)
3. Received ARP-reply from: 00:03:ff:14:52:90 (192.168.1.4)
4. Received ARP-reply from: 00:a0:c5:30:52:90 (192.168.1.200)
Sending DHCPRELEASE for invalid clients:
Send DHCPRELEASE for host 00:03:ff:15:52:90 (192.168.1.3).
Send DHCPRELEASE for host 00:03:ff:14:52:90 (192.168.1.4).
Send DHCPRELEASE for host 00:a0:c5:30:52:90 (192.168.1.200).
Restart dropping DHCP server after 60 seconds timeout...
1. Got BOOTREPLY (DHCPACK) for client ether: 00:BC:BF:D6:39:2E You IP: 192.168.1.5/24
2. Got BOOTREPLY (DHCPACK) for client ether: 00:F1:32:14:60:A3 You IP: 192.168.1.3/24
3. Got BOOTREPLY (DHCPACK) for client ether: 00:2D:1C:80:ED:12 You IP: 192.168.1.4/24
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.
Wait DHCPOFFER timeout. Resending DHCPDISCOVER.

WARNING: Failed to take away all the IP addresses assigned by DHCP server.
Perhaps DHCP server checks availability of IP addresses by sending ARP-request
before assigning them. Try to restart dhcpdrop later. If it doesn't help
try to disconnect problem hosts temporarily, then send manually DHCPRELEASE
from address of this hosts (use option -R) and restart dhcdrop.

Finished.
.fi

Explanation of the program operation's results.

After outputting the inscription "Trying to use aggressive mode" ARP-scanning of subnet, 
serviced by illegal DHCP server in the stated range, starts. 
As a result 4 hosts are found including the DHCP server itself (the first host). 
Then dhcdrop sends DHCPRELEASE message to the server 192.168.1.1 from addresses 
(Ethernet & IP) of all the hosts found in the subnet except DHCP server itself and stops 
execution for 60 seconds. Timeout is necessary because some DHCP servers hold giving out 
IP addresses to a new client during little period of time after receiving DHCPRELEASE from
a previous client. In case of necessity timeout's value can be changed with
.B -w
option. On the expiry of timeout dhcdrop launches the process of receiving released IP addresses. 
We succeeded in receiving IP addresses 192.168.1.5 (it was received initially when 
starting the program), 192.168.1.3 and 192.168.1.4. The last two addresses were 
successfully released by the server after receiving DHCPRELEASE messages generated by 
dhcdrop. Failed to receive the address 192.168.1.200, in spite of presence of this host
in the network, and the fact that from its address DHCPRELEASE message was send. One of 
the reasons of failure was described in warning in the end of the program's output: 
DHCP server before giving out the addresses can check if the host with the requested IP 
address exists and only after this it can give out the address if such a host is absent 
in the network. If not, a new lease for this address will not be given out. In this 
situation switching off the problem hosts fron the network manually and sending DHCPRELEASE 
messages from these hosts' addresses to the server (see an example below) can be helpful.
After this it's necessary to restart the process of receiving IP addresses.
But in our case the problem isn't hidden here. The host 192.168.1.200 has a statically set 
IP address and because of this it has never requested the configuration from DHCP server. 
The necessity itself of stating the legal network for launching the aggressive mode is 
necessary to check of the address range given out by illegal DHCP server crosses the 
address range of the subnet where it was discovered. If the address ranges cross each 
other then ARP-scanning will be done with the hosts, which have the correct configuration 
and will output the incorrect information. Because of this in case of discovering crossing 
of the address ranges aggressive mode will not be launched.

\fISending DHCPRELEASE message\fP
.sp
You will probably have a necessity to send DHCPRELEASE message manually. For example, 
because of the reason mentioned in the previous example. You can do it with a help of 
.B -R
option:

.nf
$ sudo dhcdrop -i eth1 -R -s 192.168.1.1 -F 192.168.1.4 00:2D:1C:80:ED:12
Using interface: 'eth1'
Send DHCPRELEASE from 00:2D:1C:80:ED:12 client IP 192.168.1.4 to DHCP server 192.168.1.1
Finished.
.fi

Option
.B -s
sets server's IP address,
.B -F
set DHCP client's IP address, 00:2D:1C:80:ED:12 set client's  Ethernet address. 
As a result such a sort of packet will be send in the network:
.nf

16:13:43.887735 00:2d:1c:80:ed:12 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 
(tos 0x10, ttl 64, id 29807, offset 0, flags [none], proto UDP (17), length 328) 
0.0.0.0.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:2d:1c:80:ed:12, 
length 300, xid 0xb2f04a28, Flags [none]
    Client-IP 192.168.1.4
    Client-Ethernet-Address 00:2d:1c:80:ed:12
    Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Release
    Server-ID Option 54, length 4: 192.168.1.1
    Client-ID Option 61, length 7: ether 00:2d:1c:80:ed:12
.fi

\fIScanning the network's segment\fP
.sp
You can use ARP-scanning of the network for searching clients who received incorrect configurational information. It is realized with a help of
.B -S
option:

.nf
$ dhcdrop -i eth1 -S 192.168.1.0/24
Using interface: 'eth1'
Starting ARP-scanning for subnet 192.168.1.0/24.
IP address range 192.168.1.0 - 192.168.1.255.
WARNING: Source IP is not set (use option -F).
Using random value for source IP address: 192.168.1.195
1. Received ARP-reply from: 00:1e:2a:52:c8:ca (192.168.1.1).
2. Received ARP-reply from: 00:a0:c5:30:52:90 (192.168.1.200).
Finished.
.fi

According to the warning, which was printed by the program, when launching, the source 
IP address wasn't set. Because of this dhcdrop chooses a random IP address from address 
range of a stated subnet. If you need to set a source address then use
.B -F
option. For this kind of scanning factual settings of routing in your network aren't 
important. Interface set by an option
.B -i
will always be used accepting that hosts of the 
mentioned subnet are in the same Ethernet segment with the host where dhcdrop 
is being launched. Also this option allows to discover duplication of IP addresses in 
the same segment of the network even if the scanning is being done from the host 
which IP address is being duplicated by another host.
.SH AUTHOR
This program was written by Roman Chebotarev <roma@ultranet.ru>
.SH REPORTING BUGS
Any bugs/remarks/suggestions/wishes concerning this program please send to 
<roma@ultranet.ru>
.SH MAN FILE
Guidance page was made by Andrew Clark <andyc@altlinux.org>, 
basing on the articles of the author of the program, 
web page http://www.netpatch.ru/en/dhcdrop.html
.SH TRANSLATION
The translation from Russian into English was made by Anna Makhtinger <mailmnoo@rambler.ru>

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>