DHCP offers not being accepted

[niccokunzmann]

DHCP offers not being accepted

[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