[Kea-users] Use perfdhcp to test IoT DHCP server?

Marcin Siodelski marcin at isc.org
Mon May 6 15:39:03 UTC 2019


The DHCPv4 protocol requires that the server sends packets to the
directly connected clients which don't have an address yet and the
clients without an address should be able to receive the DHCPACK. In
order to simulate directly connected clients, perfdhcp would need to
include extra complexity which doesn't seem to be worth the effort.

In order to overcome this problem, we implemented perfdhcp in such a way
that it simulates relayed traffic (sets giaddr to the IP address of the
local interface via which perfdhcp sends traffic). In relayed
configurations, the traffic is typically unicast to the server.

The perfdhcp tool accepts optional 'server' argument which can be
appended at the end of the command line which defaults to
255.255.255.255. I suggest that you try specifying a unicast address
where the DHCP server can be contacted instead of using the default
broadcast address. If you use the default, perfdhcp may not handle it
very well (depending on what the server sets as the source and
destination IP address in the DHCPACK).

Marcin Siodelski
DHCP Software Engineer,
ISC



On 05/05/2019 00:44, Rick Graham wrote:
> I compiled/installed v1.5 and I need a bit more help using perfdhcp.
> 
> With Wireshark I can see packets going to and from the DHCP server, but
> perfdhcp doesn't seem to see them.  It's very possible that I'm not
> using it correctly or that there is some other configuration that needs
> to be made.  I looked a little bit for a perfdhcp tutorial but didn't
> find one.
> 
> How should I use perfdhcp? Are there any requirements/setups required
> for the host where the command is run? ... or for the DHCP server?
> 
> Your help is greatly appreciated.
> Rick
> 
>     [perfdhcp Command and Output]
>     $ perfdhcp -xaeistT -r1 -n1 -B -L 6767 -l wlp8s0
>     Running: perfdhcp -x aeistT -r 1 -n 1 -B -L 6767 -l wlp8s0
>     IPv4
>     lease-type=address-only (IA_NA option added to the client's request)
>     rate[1/s]=1
>     num-request[0]=1
>     drop-time[0]=1
>     drop-time[1]=1
>     aggressivity=1
>     local-port=6767
>     broadcast
>     elp-offset=-1
>     sid-offset=-1
>     rip-offset=-1
>     diagnostic-selectors=aeistT
>     interface=wlp8s0
>     server=255.255.255.255
>     Set MAC to 00::0c::01::02::03::04
>     Set DUID to 000100012460cc9e000c01020304
>     Reached max requests limit.
>     ***Rate statistics***
>     Rate: 0 4-way exchanges/second, expected rate: 1
>     ***Statistics for: DISCOVER-OFFER***
>     sent packets: 1
>     received packets: 0
>     drops: 1
>     min delay: inf ms
>     avg delay: Delay summary unavailable! No packets received.
>     ***Statistics for: REQUEST-ACK***
>     sent packets: 0
>     received packets: 0
>     drops: 0
>     min delay: inf ms
>     avg delay: Delay summary unavailable! No packets received.
>     Late received packets: 0
>     Late sent packets: 2
>     Multiple packets receives: 0
>     Short waits for packets: 2
>     ***Timestamps for packets: DISCOVER-OFFER***
>     Unavailable! No packets received.
>     ***Timestamps for packets: REQUEST-ACK***
>     Unavailable! No packets received.
>     Interrupted
>     xid-offset=4
>     random-offset=35
>     contents: 
>     0000   01010601000000000000000000000000
>     0020   00000000000000000a14640c000c0102
>     0040   03040000000000000000000000000000
>     0060   00000000000000000000000000000000
>     0080   00000000000000000000000000000000
>     00a0   00000000000000000000000000000000
>     00c0   00000000000000000000000000000000
>     00e0   00000000000000000000000000000000
>     0100   00000000000000000000000000000000
>     0120   00000000000000000000000000000000
>     0140   00000000000000000000000000000000
>     0160   00000000000000000000000000000000
>     0180   00000000000000000000000000000000
>     01a0   00000000000000000000000000000000
>     01c0   00000000000000000000000063825363
>     01e0   3501013707011c02030f060c3d070100
>     0200   0c01020304ff
>     xid-offset=4
>     random-offset=35
>     srvid-offset=54
>     time-offset=8
>     ip-offset=240
>     contents: 
>     [Wireshark summary]
>       No.     Time           Source                HW Src Addr         
>      Destination           HW Dst Addr         Protocol Length Info
>            26 6.517873909    10.20.100.12          IntelCor_52:39:7e   
>      255.255.255.255       Broadcast           DHCP     304    DHCP
>     Discover - Transaction ID 0x0
>       Frame 26: 304 bytes on wire (2432 bits), 304 bytes captured (2432
>     bits) on interface 0
>       Ethernet II, Src: IntelCor_52:39:7e (44:85:00:52:39:7e), Dst:
>     Broadcast (ff:ff:ff:ff:ff:ff)
>       Internet Protocol Version 4, Src: 10.20.100.12, Dst: 255.255.255.255
>       User Datagram Protocol, Src Port: 6767, Dst Port: 67
>       Dynamic Host Configuration Protocol (Discover)
>       No.     Time           Source                HW Src Addr         
>      Destination           HW Dst Addr         Protocol Length Info
>            27 6.809201927    10.20.100.10          ZyxelCom_4c:3c:40   
>      10.20.100.12          IntelCor_52:39:7e   DHCP     326    DHCP
>     Offer - Transaction ID 0x0
>       Frame 27: 326 bytes on wire (2608 bits), 326 bytes captured (2608
>     bits) on interface 0
>       Ethernet II, Src: ZyxelCom_4c:3c:40 (5c:6a:80:4c:3c:40), Dst:
>     IntelCor_52:39:7e (44:85:00:52:39:7e)
>       Internet Protocol Version 4, Src: 10.20.100.10, Dst: 10.20.100.12
>       User Datagram Protocol, Src Port: 67, Dst Port: 67
>       Dynamic Host Configuration Protocol (Offer)
>       No.     Time           Source                HW Src Addr         
>      Destination           HW Dst Addr         Protocol Length Info
>            28 6.809242186    10.20.100.12          IntelCor_52:39:7e   
>      10.20.100.10          ZyxelCom_4c:3c:40   ICMP     354   
>     Destination unreachable (Host administratively prohibited)
>       Frame 28: 354 bytes on wire (2832 bits), 354 bytes captured (2832
>     bits) on interface 0
>       Ethernet II, Src: IntelCor_52:39:7e (44:85:00:52:39:7e), Dst:
>     ZyxelCom_4c:3c:40 (5c:6a:80:4c:3c:40)
>       Internet Protocol Version 4, Src: 10.20.100.12, Dst: 10.20.100.10
>       Internet Control Message Protocol
> 
> 
> 
> 
> 
> On Fri, May 3, 2019 at 12:53 PM Thomas Markwalder <tmark at isc.org
> <mailto:tmark at isc.org>> wrote:
> 
>     Hello:
> 
>     Perfdhcp is server agnostic.  It communicates using standard DHCP
>     and DHCPv6 messages and should work with an RFC compliant server.
> 
>     Cheers,
> 
>     Thomas Markwalder
>     ISC Software Engineering
> 
> 
> 
>     On 5/3/19 3:05 AM, Rick Graham wrote:
>>     I would like to test the DHCP server of an IoT device on my local
>>     network.  Is KEA's perfdhcp appropriate for this?  Is there a
>>     better way/tool to test a (probably) non-KEA DHCP server?
>>
>>     Thanks and regards,
>>     Rick
>>
>>
>>     _______________________________________________
>>     Kea-users mailing list
>>     Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>
>>     https://lists.isc.org/mailman/listinfo/kea-users
> 
>     _______________________________________________
>     Kea-users mailing list
>     Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/kea-users
> 
> 
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> 




More information about the Kea-users mailing list