Linux dhcp client simulation tool

Developed a DHCP client simulation tool sometime back. The tool can be used for testing DHCP server which are part of networking devices such as routers, IP DSLAM, etc.

The tool needs a linux environment with root login since it uses promiscuous sockets for sending and receiving DHCP packets.

Download link – dhtest.tgz (Legacy code)

Latest code – Github repo : https://github.com/saravana815/dhtest

Github download link: https://github.com/saravana815/dhtest/archive/master.zip

Basic usage

root@sargandh-laptop:/home/sargandh/Desktop/dhtest-1.1# ./dhtest
Usage: ./dhtest [ options ] -m mac_address
-r, –release # Releases obtained DHCP IP for corresponding MAC
-I, –option50-ip [ IP_address ] # Option 50 IP address on DHCP discover
-o, –option60-vci [ VCI_string ] # Vendor Class Idendifier string
-v, –vlan [ vlan_id ] # VLAN ID. Range(2 – 4094)
-t, –tos [ TOS_value ] # IP header TOS value
-i, –interface [ interface ] # Interface to use. Default eth0
-T, –timeout [ cmd_timeout ] # Command returns within specified timout in seconds
-b, –bind-ip # Listens on the obtained IP. Supported protocols – ARP and ICMP
-k, –bind-timeout [ timeout ] # Listen timout in seconds. Default 3600 seconds
-f, –bcast_flag # Sets broadcast flag on DHCP discover and request
-V, –verbose # Prints DHCP offer and ack details
dhtest version 1.1

root@sargandh-laptop:/home/sargandh/Desktop/dhtest-1.1# ./dhtest -m 00:00:11:22:33:44
DHCP discover sent – Client MAC : 00:00:11:22:33:44
DHCP offer received – Offered IP : 10.0.2.16
DHCP request sent – Client MAC : 00:00:11:22:33:44
DHCP ack received – Acquired IP: 10.0.2.16

root@sargandh-laptop:/home/sargandh/Desktop/dhtest-1.1# ./dhtest -m 00:00:11:22:33:44 -V
DHCP discover sent – Client MAC : 00:00:11:22:33:44
DHCP offer received – Offered IP : 10.0.2.16

DHCP offer details
———————————————————-
DHCP offered IP from server – 10.0.2.16
Next server IP(Probably TFTP server) – 10.0.2.4
Subnet mask – 255.255.255.0
Router/gateway – 10.0.2.2
DNS server – 72.163.128.140
DNS server – 171.70.168.183
Lease time – 1 Days 0 Hours 0 Minutes
DHCP server – 10.0.2.2
———————————————————-

DHCP request sent – Client MAC : 00:00:11:22:33:44
DHCP ack received – Acquired IP: 10.0.2.16

DHCP ack details
———————————————————-
DHCP offered IP from server – 10.0.2.16
Next server IP(Probably TFTP server) – 10.0.2.4
Subnet mask – 255.255.255.0
Router/gateway – 10.0.2.2
DNS server – 72.163.128.140
DNS server – 171.70.168.183
Lease time – 1 Days 0 Hours 0 Minutes
DHCP server – 10.0.2.2
———————————————————-

root@sargandh-laptop:/home/sargandh/Desktop/dhtest-1.1#

Advertisements

59 Responses to “Linux dhcp client simulation tool”

  1. Nicolas Says:

    Marvelous! Works like a charm on Mint 9, this was just what I was looking to troubleshoot a DHCP issue. Thanks a lot for sharing!

  2. Claes Says:

    perfect!

  3. dx Says:

    Perfect for testing dhcp server, thanks!

  4. john Says:

    i so wish this would test option 66 and 67 and report what the dhcp server sent back. i’m going crazy trying to figure out how to do that.

  5. JM Says:

    Hi, this is really what I’ve been looking for but it doesn’t work all way. The release part fails to send the packet…
    root@dhcpstorm:/usr/local/src/dhtest-1.1# ./dhtest -m 00:dd:02:11:55:08 -i eth1.1000 -f
    DHCP discover sent – Client MAC : 00:dd:02:11:55:08
    DHCP offer received – Offered IP : 10.254.200.99
    DHCP request sent – Client MAC : 00:dd:02:11:55:08
    DHCP ack received – Acquired IP: 10.254.200.99
    root@dhcpstorm:/usr/local/src/dhtest-1.1# ./dhtest -m 00:dd:02:11:55:08 -i eth1.1000 -f -r
    Paket send failure: Socket operation on non-socket
    Tried to look into the code but C is not my cup of tea. Running on Ubuntu. Any ideas?

    • saravana815 Says:

      Hi JM,

      I tried almost the same arguments on my system and it works.

      [root@CentOS dhtest-1.1]# ./dhtest -m 00:dd:02:11:55:08 -f
      DHCP discover sent – Client MAC : 00:dd:02:11:55:08
      DHCP offer received – Offered IP : 10.142.98.105
      DHCP request sent – Client MAC : 00:dd:02:11:55:08
      DHCP ack received – Acquired IP: 10.142.98.105
      [root@CentOS dhtest-1.1]# ./dhtest -m 00:dd:02:11:55:08 -f -r
      DHCP release sent – Client MAC : 00:dd:02:11:55:08

      The only difference I see is the use of vlan interface for getting and releasing the IP address.
      Instead of trying the vlan interface, can you specify the vlan id for the tool itself
      like ./dhtest -m 00:dd:02:11:55:08 -f -v 1000 and ./dhtest -m 00:dd:02:11:55:08 -f -r -v 1000

      • JM Says:

        I downgraded to Ubuntu 10 from Ubuntu 12 and then release works fine. Any plans for “DHCP renew”? Would be really nice to have.
        Cheers, //JM

      • saravana815 Says:

        Hi JM,
        I am not working on this tool for a long time, so plans to add/improve the tool as of now. 🙂
        Regards,
        Saravana

  6. Dell tester Says:

    How do you make it send multiple DHCP requests using this tool to test a DHCP server?

    • saravana815 Says:

      For every DHCP request, run the tool with different mac address as a background process.
      Ex.
      ./dhtest -m 00:00:11:22:33:44 &
      ./dhtest -m 00:00:11:22:33:45 &

      The better way is to write a shell script and iterate through mac address field.

      • Nicolas Chaigneau Says:

        For multiple parallel calls you should slightly alter “set_rand_dhcp_xid” function, so that you don’t get the same xid if several calls occur in the same second.
        For instance, change :
        srand(time(NULL));
        To :
        srand(time(NULL) ^ (getpid()<<16));

        Regards,
        Nicolas.

      • saravana815 Says:

        Hi Nicolas,
        Thanks for the info and updated the set_rand_dhcp_xid function.

        – srand(time(NULL));
        + srand(time(NULL) ^ (getpid() << 16));
        dhcp_xid = rand() % 0xffffffff;

        Regards,
        Saravana

  7. Nicolas Chaigneau Says:

    Hello,

    Thanks for sharing this tool which proved very handy 🙂

    Just a note : on Linux Red Hat (build with gcc 4.1.2), it doesn’t work as is (seg faults on call to inet_ntoa).
    I had to change the following:

    1) add the following include:
    #include

    2) change all inet_ntoa calls, for instance :
    /*fprintf(stdout, “DHCP offered IP from server – %s\n”, inet_ntoa(dhcph_g->dhcp_yip));*/
    struct in_addr ipaddr;
    ipaddr.s_addr=dhcph_g->dhcp_yip;
    fprintf(stdout, “DHCP offered IP from server – %s\n”, inet_ntoa(ipaddr));

    Regards,
    Nicolas.

    • saravana815 Says:

      Hi Nicolas,

      Thanks for sharing the info.
      I am having cent os 5 with gcc 4.12 and could not see any segmentation fault with verbose enabled.
      Yes, the header file arpa/inet.h is not included and I don’t know how it got missed. May be since calls the atoi, inet_ntoa calls worked simply without inet.h

      I am suspecting it might be due to platform. My VM is 32 bit x86 and i think you might be using 64 bit.

      Regards,
      Saravana

      • Nicolas Chaigneau Says:

        Thank you for your answer.
        Indeed, I’m using a 64 bit x86 as test client.

    • Gerold Says:

      Could you send me a working source or binary?

      Regards
      Gerold

  8. Alex Says:

    Hi,
    Noticed that function.c doesn’t recognize DHCP-OFFER packet type if Broadcast flag=1 in the packets from server.
    Trying to handle. If somebody know the solution will appreciate.
    Thanks.

    • saravana815 Says:

      Hi Alex,
      There is no check based on broadcast flag AFAIK for receiving DHCP offer or any DHCP msg from server. Something else might be the issue.
      Regards,
      Saravana

      • Alex Says:

        Hi Saravana,
        Thanks for the fast response!
        I dumped the packets during client – server exchange with BF=0 and BF=1. In the first cause everything passed well. When i received DHCP-OFFER with BF=1 DHCP-REQUEST was not generated according to the capture. Also i noticed that the packets length are different in this two causes, 342B and 336B respectively.
        Maybe this is the reason.
        Very useful utility but can’t use in my test environment.
        Thanks!

  9. Kazi Rahman Says:

    Hi Sargandh,
    Thanks for this tool. Couple of questions:
    – You mentioned some changes needed for 64-bit machine. Do you have linux version of that?
    – Can I give a range of mac address (e.g. 00:11:22:33:44:55 to 00:11:22:33:66:77 ) to test
    client scale?

    Kazi

    • saravana815 Says:

      Hi kazi,

      Can you try the latest version from github for 64 bit machine? I hope it works.
      Currently the command line can take only a single mac address. One way to do the mac address scale is to create a bash script and run the tool for each mac address inside the script.

      Regards,
      Saravana

  10. michel.marcon Says:

    I wanted to configure a DCHP server only on eth1 and not eth0 interface (for secure goals). This tols provided the solution in testing and configuraing the dnsmasq configuration file. Very well written code, indeed
    DHTEST running on an old 2.6.18.xx kernel from Suse 10.2 (32b)
    Kudos !

    Cheers

    michel marcon (aka cmic)

  11. Daniel Sjöblom Says:

    Hey, excellent tool for DHCP monitoring and error solving. Thanks!!!

  12. Sibi Alex Jacob. Says:

    Sarvanan,

    Thanks , Its a very useful tool.
    Do you have plans to make it available for IPV6 DHCP ? 🙂

    Regards,
    Sibi Alex Jacob

    • saravana815 Says:

      Hi Sibi Alex Jacob,
      I have noted few new features including IPv6 for the tool which are very useful. But currently not doing any new changes to the tool.
      May be on best effort basis.

      Regards,
      Saravana

  13. Bicio Says:

    Works perfectly on Ubuntu (12.4 and 14.4). Thank you very much!

  14. yassin Says:

    Thanks alot. this was of a big help for me

  15. chetan Says:

    hi can we send individual message using this tool, like i want to send only dhcp ack or dhcp decline message individual without sending discover., request messages, if possible tell me way how to do it

  16. JP Says:

    I may not have the proper use case for this tool. I want to use it to detect a rogue DHCP-server.
    The machine already acquired an IP, but I just want to make a DHCP-request with some fantasy MAC and then I want to detect a rogue DHCP-server. I don’t want it to act upon the OFFER, I just want to see the IP/MAC of the device that’s offering me one.
    If I run this tool with another MAC than its own, I’m not getting any offers.

    It seems this tool isn’t made for that.
    I would really like to have such a tool

    • saravana815 Says:

      Hi,
      The tool can be run with any mac-address. But it is upto the server to reply with the offer. In your case, I think the server is doing mac-address check and could be due do that the server replies for the actual mac address.

      If you are not concerned about the dhcp state machine, then you can use libnet library to send individual dhcp packets.
      libnet link – http://libnet.sourceforge.net/

      Regards,
      Saravana

  17. Martin Says:

    Hi all,
    Idownloades the latest code from git, and tried dhtest with the new kea dhcp Server from ISC. a dhcpdump showed kea server is sending an offer, but dhtest did not show the offer packet.
    exactly the same setup, using the old isc-dhcp and dttest dhtest did work perfect.
    dhclient and kea server do work perfect too. doen with vmware and debian.
    any ideas?
    BR Martin

    • saravana815 Says:

      Hi Martin,
      We need to see the DHCP offer packet contents to know why the offer packet is getting dropped.
      You can share the packet capture details.

      Regards,
      Saravana

    • S. M. Hossein Hamidi Says:

      There is a problem with the way dhtest processes DHCP options. After analyzing the code, I understood there are false assumptions about positioning of option message type. There is no predefined order about DHCP options. The check_packet() function wrongly assumes message type is placed at (dhopt_pointer_g + 2).

      The order of serializing DHCP options differs in Kea implementation.

  18. CarlK Says:

    Hi Saravana,
    Is there a way for the tool to generate the DHCP packet where the client MAC specified on the CLI comes from the -m parameter but the source MAC of the actual packet on the wire comes from the host’s MAC and the destination MAC is either specified or maybe uses the destination MAC of the next hop router? I’m trying to have the generated request look like it is coming from a DHCP relay agent. I got close with:

    ./dhtest -m 00:11:22:33:44:00 -u -g 10.252.56.22 -S 10.255.14.199

    Where the destination IP is the server IP specified and the source IP is the host IP. But the source MAC was the one from -m and the destination MAC was all ff’s.

    Thanks,
    Carl

    • saravana815 Says:

      Hi Carl,

      What you ask can be done certainly.
      option #1 – Get the host mac address and gateway mac address from command line itself and use them. use dmac variable for destination mac and add a new variable for host_mac and use it as part of function build_dhpacket. This one is easy to implement. But for automated cases, this is not useful.

      option #2 – Get the host mac using structure sockaddr_ll and nexthop mac address from arp table and use them. This needs more code.

      If you are looking for quick fix, option #1 is easy and i think you can add them easily for your use.

      Regards,
      Saravana

      • CarlK Says:

        Thanks Saravana. To confirm in option #1, are you saying use the current dmac variable (which is pulled in from the CLI using the -m switch) as the one to populate the outer packet and then new variable host_mac for the client mac address in the DHCP packet? Or the reverse of that?

        Also, I see both dmac and dhmac being defined in the dhtest.c. What is dhmac defining?

        Regards,
        Carl

      • saravana815 Says:

        Hi Carl,

        dmac variable is the broadcast mac (ffff.ffff.ffff).
        int build_dhpacket(int pkt_type)
        {
        u_int32_t dhcp_packet_size = dhcp_hdr_size + dhopt_size;
        if(!dhcp_release_flag) {
        u_char dmac_tmp[ETHER_ADDR_LEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
        memcpy(dmac, dmac_tmp, ETHER_ADDR_LEN);
        }
        dhmac is the client mac address used (used as l2 packet source mac address and as DHCP client mac address).

        * So use the dhmac variable to populate the outer mac address (Inside DHCP header).
        * Add two more command line argument. One for host/VM actual mac address and second for gateway mac address.
        * Use host/VM mac address as L2 packet source mac and gateway mac as L2 packet dest. mac.

        Try it yourself or otherwise I can add easily the option #1.

        Regards,
        Saravana

  19. CarlK Says:

    Thanks again Saravana. I see how it works now and have made the changes I needed!

  20. Vishnu Says:

    Hi Saravana,

    I need to perform load testing on dhcp server with random mac addresses as you are passing static mac address in the argument, so how can i achieve that with the help of this.

    Regards,
    Vishnu

  21. Ludovic Landucci Says:

    Hi Saravana,

    Thanks for your tool ! Very usefull.

    We need to use it with an interface on wich we put on multicast (ip link set eth3.300 multicast on).
    Then “ip link show eth3.300” shows :
    6: eth3.300@eth3: mtu 1500 qdisc noqueue state UP link/ether e4:11:5b:9a:0f:8f brd ff:ff:ff:ff:ff:ff

    Then we try dhtest with this : dhtest -i eth3.300
    We’ve got this answer so dhtest work well :
    DHCP discover sent – Client MAC : e4:16:5d:9a:0f:8e
    DHCP offer received – Offered IP : 192.168.222.10
    DHCP request sent – Client MAC : e4:16:5d:9a:0f:8e
    DHCP ack received – Acquired IP: 192.168.222.10

    But when we check again our interface configuration with “ip link show eth3.300” we got :
    6: eth3.300@eth3: mtu 1500 qdisc noqueue state UP
    link/ether e4:11:5b:9a:0f:8f brd ff:ff:ff:ff:ff:ff

    We can see that MULTICAST configuration is dropped when we use dhtest.

    Can you reproduce this ?

    Thanks for your help.

    Regards,

    • saravana815 Says:

      Hi Ludovic,
      The dhtest tool is not going to touch or modify any configs set on the interface. This is a tool to simulate a virtual dhcp client.

      Regards,
      Saravana

  22. Rok Says:

    I have added option55 request parameters. Do you want me to send you a patch? In what way do you accept contributions?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: