Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
RPi 3 "diskless" network boot ignores DHCPOFFER #894
I have not been able to make this work reliably with my desired setup:
DHCP server (router) - 192.168.102.1
Tried setting in the DHCPOFFER:
Both work intermittently.
Akin to #862 where it was mentioned that a random broadcast ping on the subnet usually fixes the Pi's behavior, I noticed that where the router makes an ARP request between the Pi's DHCPDISCOVER and its DHCPOFFER response as in
But if the Pi is being reset when the lease is in "bound" status, the ARP request is not sent, just a DHCPOFFER for each DHCPDISCOVER (4).
I can make it work with
Could someone confirm whether this is possible to be resolved at all given this seems entirely 1st stage bootloader-bound?
Does adding the dhcp-reply-delay fix the problem reliably?
If it does then the problem is to do with a bad bit of logic in the code where I check the ip_address, tftp_address and timeout in the dhcp_reply function (i.e. waiting for a reply from a dhcp server)
Unfortunately this means it will keep repeating the loop until the timeout has elapsed even it it has already received an IP address and TFTP boot address. When you combine this with a bug in the wait_rx_packet() which means it only checks it's timeout when you receive a packet from the network. So no other devices on the network -> no network traffic -> no packets received -> no timeout -> never completing the wait_rx_packet -> never exiting this function!
The solution should be to make sure the device receives the odd broadcast packet (has to be broadcast otherwise it'll not make it through the packet filter), which I've tried in the past until ping -b but not absolutely sure this always works...
I only noticed this by looking at the
I guess this could be another possible bug in
It will take the first IP address it is offered... Although I'm surprised it doesn't also overwrite with the second one.
Are you sure the dnsmasq isn't just enabled as a proxy and is therefore not providing a second IP address?
I'll add it to a list of things to test if I ever write a newer version of this!
For reference: firmware version used was https://github.com/raspberrypi/firmware/tree/384559354762f36aa55584560d8749fc66a4cfd0