DHCP offers not being accepted

[dbrb2]

I have this set up on a pi to which a laptop is connected. The pi has a wifi and a wired interface, and the wired interface is connected directly to a laptop.

The pi is running the python DHCP server, whilst the laptop is requesting an IP

I can see the DHCP discovery messages coming in from the laptop to the Pi, and the Pi responds with an offer

However, the offer is never accepted - there seems to be no REQUEST message sent in response by the laptop - so the logs on the pi show a continuous stream of "DHCPDISCOVER", "DHCPOFFER"

discover:
Message Type: 1
client MAC address: 00:0E:C6:CA:BC:35
client IP address: 0.0.0.0
your IP address: 0.0.0.0
next server IP address: 0.0.0.0
client identifier: 01:00:0E:C6:CA:BC
dhcp message type: DHCPDISCOVER
host name: ben-laptop
maximum dhcp message size: 576
parameter request list: [1, 2, 6, 12, 15, 26, 28, 121, 3, 33, 40, 41, 42, 119, 249, 252, 17]

new ip: 192.168.2.6
add 00:0E:C6:CA:BC:35 192.168.2.6 ben-laptop
broadcasting:
Message Type: 2
client MAC address: 00:0E:C6:CA:BC:35
client IP address: 0.0.0.0
your IP address: 192.168.2.6
next server IP address: 0.0.0.0
broadcast address: 255.255.255.255
client identifier: 00:0E:C6:CA:BC:35
dhcp message type: DHCPOFFER
ip address lease time: 300
subnet mask: 255.255.255.0

Running wireshark on the laptop - the one issuing the DISCOVER messages, I can see the DHCPOFFER, but it seems a REQUEST response is never sent

Dynamic Host Configuration Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x2eb6bcda
Seconds elapsed: 0
Bootp flags: 0x0001 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.2.6
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: AsixElec_ca:bc:35 (00:0e:c6:ca:bc:35)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (1) Subnet Mask (255.255.255.0)
Length: 4
Subnet Mask: 255.255.255.0
Option: (28) Broadcast Address (192.168.2.255)
Length: 4
Broadcast Address: 192.168.2.255
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (300s) 5 minutes
Option: (53) DHCP Message Type (Offer)
Length: 1
DHCP: Offer (2)
Option: (61) Client identifier
Length: 6
Type: 0
Client Identifier: \016���5
Option: (255) End
Option End: 255

[niccokunzmann]

Hi, thanks for reporting! I am a bit confused... Could you say who is sending what where and who is receiving what and who should receive what but does not?

[dbrb2]

Sorry for the confusion:

I have the python script running on a raspberryPi
I have a laptop connected to the wired interface of the pi

The laptop is making DHCP DISCOVER messages, which I can see using tshark on the pi
in response to these messages, the pi is sending a DHCP OFFER message to the broadcast IP, which I can see arriving at the laptop using wireshark

However, for some reason that incoming DHCP OFFER is never accepted by the laptop - no REQUEST message is sent from the laptop to the pi in response to the OFFER, and instead a new DISCOVERY is sent

I can't see any obvious problem with the offer message. The only thing that I noticed is that the OFFER is broadcast, rather than unicast. As far as I can see, either should work - though unicast offers (with the destination set to the mac of the client) seem to be a little more common.

[niccokunzmann]

Hm. Thanks for analysing this! I guess, beause it mostly works, I used multicast. It is probably not hard to use unicast. The values should be present when the message is constructed. Would you like to give is a go and modify the code? Do you need a hand finding the lines?

[dbrb2]

Thanks - I always feel bad raising issues on open source projects - I realise time is limited! I might try a little more to verify the problem really is broadcast vs unicast, and then try to see if I can find a fix - though there is definitely a possibility I won't manage to! Thanks either way for all your hard work, Ben

…

On Wed, Jun 15, 2022 at 6:17 PM Nicco Kunzmann ***@***.***> wrote: Hm. Thanks for analysing this! I guess, beause it mostly works, I used multicast. It is probably not hard to use unicast. The values should be present when the message is constructed. Would you like to give is a go and modify the code? Do you need a hand finding the lines? — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFQ4YU3ERO5C4GT3YOVOLVPIF3VANCNFSM5X7WEBSA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[niccokunzmann]

Hm............... I had a thought that for trying out, you could write your MAC address in there statically. (I cannot remember where, though) I do not think that raising issues on open-source projects is any bad: 1. They do not have to answer - I take my time and do it when I like! 2. If you have the possibility to, you will probably report something that a lot of people also have who may not be able to report it in full. 3. We like to hear from users! Totally motivating! Nobody likes haters but you are not a hater. I would rather work on a project with people talking about it than on one that people use and I do not know about it at all. 4. Learning: You report cases I did not think of, like this issue. This is the way that OSS grows in quality. So, welcome and thanks and I hope to hear more from you... Another idea might be capturing the packets that work from other DHCP servers and compare. Your router probably works.... Or does the laptop have problems with waiting for too long? You can reduce the answer time.

[SurajBhari]

I used multicast. It is probably not hard to use unicast.

hey, I tried to run this today with no experince in networking at all. and I had same issue as said by the OP.
but as of the time I am writing this. i can see that you have set the flag to unicast.
am I missing something ?

[niccokunzmann]

oh, it is a while ago that I wrote this program, so if you can make it work by changing the flag, that is nice, PR welcome.

It seems to me that the MAC address should be set to send an offer. Would you like to modify the code and have a look if it solves your problem?

[SurajBhari]

hey, I have tried to set it to both ways multicast and unicast (by changing bootp_flags variable) and also setting up client_mac_address. but it was still the same.

Just to be sure we are on the same page. can you share your testbench?
I am using this on my laptop as server and a desktop running ubuntu 22 by a single LAN wire.

[Xenoamor]

I've encountered the same problem when trying to process a DHCP Discover from an embedded device running a udhcp client. It looks to be that this client does not handle broadcasted DHCP Offers and instead expects the ethernet frame address to be its MAC address

Basically my client insists on a unicast offer with the destination as it's MAC address. It will not listen to a broadcasted multicast offer

Unfortunately python does not natively support setting this low level field on Windows without using something like NpCap. Thus I don't believe this can be done in standard python alone