Note that there are some explanatory texts on larger screens.

plurals
  1. POno DHCP ACK after sending a DHCP REQUEST
    primarykey
    data
    text
    <p>[Solved] I am manually constructing DHCP packets as a client to the DHCP server. So far I am able to send a DHCPDISCOVER packet and receive a DHCPOFFER from the server in return. However, when I send DHCPREQUEST, I don't receive the expected DHCPACK at all. </p> <p>DHCPDISCOVER: <a href="http://digitalphoenix.info/uploads/so/dhcpDiscover.jpg" rel="nofollow">http://digitalphoenix.info/uploads/so/dhcpDiscover.jpg</a><p> DHCPOFFER: <a href="http://digitalphoenix.info/uploads/so/dhcpOffer.jpg" rel="nofollow">http://digitalphoenix.info/uploads/so/dhcpOffer.jpg</a><p> DHCPREQUEST: <a href="http://digitalphoenix.info/uploads/so/dhcpReq.jpg" rel="nofollow">http://digitalphoenix.info/uploads/so/dhcpReq.jpg</a></p> <p>(in the above the Honeypot daemon is 192.168.0.2, DHCP server 192.168.0.1, client A (192.168.0.6) trying to probe 192.168.0.106 which doesn't exist. Attempting to acquire a lease for '192.168.0.106')</p> <p>I'm inferring that the DHCP server does not send an ACK at all because:<p> 1) the DHCP server shows no active lease for 192.168.0.106 <p> 2) the DHCP server usually sends an ARP request to the requested IP prior to sending ACKs to probe availability (tested) (no ARP req sent)</p> <p>therefore the problem lies in the DHCP Request packet being dropped or rejected...? I don't even get a NACK</p> <p>Background: I am writing a Honeypot daemon that dynamically allocates IP addresses on behalf of virtual high-interaction Honeypots (VM). It listens for unanswered ARP requests, takes the dest. IP and attempts to lease that specific dest. IP address from the DHCP server for the next unbound Honeypot to use. When the lease has been acknowledged, the daemon finally returns an ARP reply to the source. The Honeypots exist on a separate subnet and the goal is to logically place them within the same subnet as the host machine. From thereon, the daemon is responsible for all outgoing/incoming traffic for the bound Honeypots(s). The ethernet frame src addr is the MAC of the Honeypot daemon / host. However, the MAC specified in the bootp is completely arbitrary.</p> <p>edit: just noticed the UDP checksum is empty, didn['t notice this because of wireshark disabling udp checksum validation. is this necessary? the DHCPDISCOVER didn't have it but got response anyway? Even small suggestions as to what may be causing the problem would be appreciated, thanks guys</p> <p>edit2: corrected the UDP checksum, problem still exists</p> <p>extra info: 192.168.0.0/24 lease range 2-254</p> <p>wireshark capture / pcap: <a href="http://digitalphoenix.info/uploads/so/honeyPotCapture.pcap" rel="nofollow">http://digitalphoenix.info/uploads/so/honeyPotCapture.pcap</a> (same as above except the fake MAC and target IP is 192.168.0.109 instead of x.x.x.106)</p> <p>FINAL EDIT: Fixed. I'm blind. Turns out the server IP addr field was filled in when RFC says not to. Amazing what a good night's sleep can do.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload