DHCP and manual IP

Dear Ex.

I made dhcpd.conf as below, trying to not let any other client in network to get IP manually.... if he tried... get a messege from DHCP Server that e is not allow to get a manual IP.

But it is not working!!!???? can you plz help.

ddns-update-style ad-hoc;

subnet netmask {
        deny unknown-clients;
        default-lease-time 600;
        max-lease-time 7200;
        option subnet-mask;
        option broadcast-address;
        option routers;
        option domain-name-servers,,;

host InToucSec {
        hardware ethernet 00:06:4f:02:09:e2;
        option host-name "intouch_sec";



Osama El-Shiekh
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


DHCP is only for allowing automated ip-configuration. You are trying to deny clients to set their IP manually which is not possible with DHCP only.
So in short the answer to your question is:

"what you have configured is okay, DHCP just does not deny manual configuration."

I don't know what kind of a network you have (smal/medium/large office or just a small home network?
What sort of operating systems is running on the clients?
Do you have manageable routers and/or switches in your network?

Redfeather is very right. However You may try detecting such situation - and punishing noughty users ;)
princeofsudanAuthor Commented:
I want to deny client to get IP from DHCP IP range.

Other wise, what is the reason from 'authoritative' option???
OWASP: Threats Fundamentals

Learn the top ten threats that are present in modern web-application development and how to protect your business from them.

First of all: You cannot deny a client to use manually an IP from the DHCP IP range.

Then about the authoritative statement:


        not authoritative;

       The DHCP server will normally assume that  the  configura­
       tion information about a given network segment is known to
       be correct and is authoritative.   So if a client requests
       an  IP  address on a given network segment that the server
       knows is not valid  for  that  segment,  the  server  will
       respond with a DHCPNAK message, causing the client to for­
       get its IP address and try to get a new one.

       If a DHCP server is being configured by  somebody  who  is
       not  the  network administrator and who therefore does not
       wish to assert this level of authority, then the statement
       "not  authoritative"  should be written in the appropriate
       scope in the configuration file.

       Usually, writing not authoritative; at the  top  level  of
       the file should be sufficient.   However, if a DHCP server
       is to be set up so that it is aware of some  networks  for
       which  it  is authoritative and some networks for which it
       is not, it may be more appropriate to declare authority on
       a per-network-segment basis.

       Note that the most specific scope for which the concept of
       authority makes any sense is the physical network  segment
       -  either a shared-network statement or a subnet statement
       that is not contained within a  shared-network  statement.
       It is not meaningful to specify that the server is author­
       itative for some subnets within a shared network, but  not
       authoritative  for others, nor is it meaningful to specify
       that the server is authoritative for  some  host  declara­s
       tions and not others.

(source: http://lrp2.steinkuehler.net/Packages/man/dhcpd.conf.5.man.htm)

After reading this you will also conclude like me that: authoritative just allows a server to deny a client requesting an IP for a wrong subnet. Which in turn has got nothing to do with your problem.
nociSoftware EngineerCommented:
If dhcp uses a subrange of a network, it will check using a ping if the address is valid
(ie not in use) using a ping.

look for the config items ping-timeout.
(man dhcpd.conf    # look for: ping-timecout, it's 1 second may be too short, try to set it to 2 or 3)

This is not done on whole networks, only if subranges are used. and if the dhcp server thinks the address is

       The DHCP server checks IP addresses to see if they are in use before allocating them to clients.   It does
       this by sending an ICMP Echo request message to the IP address being allocated.   If no ICMP Echo reply is
       received within a second, the address is assumed to be free.  This is only done for leases that have  been
       specified  in  range  statements, and only when the lease is thought by the DHCP server to be free - i.e.,
       the DHCP server or its failover peer has not listed the lease as in use.

       If a response is received to an ICMP Echo request, the DHCP server assumes that there is  a  configuration
       error  -  the  IP  address is in use by some host on the network that is not a DHCP client.   It marks the
       address as abandoned, and will not assign it to clients.

       If a DHCP client tries to get an IP address, but none are available, but there are abandoned IP addresses,
       then  the  DHCP server will attempt to reclaim an abandoned IP address.   It marks one IP address as free,
       and then does the same ICMP Echo request check described previously.   If there is no answer to  the  ICMP
       Echo request, the address is assigned to the client.

       The  DHCP server does not cycle through abandoned IP addresses if the first IP address it tries to reclaim
       is free.   Rather, when the next DHCPDISCOVER comes in from the client, it will attempt a  new  allocation
       using the same method described here, and will typically try a new IP address.

It will log such things, from the log i would expect you should be able to find the culprit.
otherwise ping the ip address involved and lookup the mac-address with arp -a
or use arping to get the MAC address, and then find the system involved.

nociSoftware EngineerCommented:
A solution you could lookinto is:

scan the leased address files...
ping all addresses not in use, and if you have a hit

add an iptables entry to block the address to your server/firewall.
Then the owner of that system will complain...

whereas the neighbours having dhcp have no trouble at all.
nociSoftware EngineerCommented:
Run this kind of script regularly, otherwise you will get false positives if violators
reset their systems back to dhcp.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
princeofsudanAuthor Commented:
Thanks for all your helps and supports.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.