bootcode incompliant with DHCP RFC2131 - DISCOVER & OFFER but no REQUEST or ACK

[arcivanov]

Describe the bug Netbootcode in bootcode.bin is not behaving in an RFC 2131-compliant manner when booting BOOTP/PXE.

1. A DHCPDISCOVER is sent by RPi.
2. A DHCPOFFERs are collected. Once the one carrying SIADDR and/or(?) Option 66 containing TFTP reference has been observed RPi netbootcode stops following any semblance of prescribed procedure, configures the offered IP address and goes for the TFTP server.

To reproduce

1. Place latest bootcode.bin on the SD card.
2. Configure DHCP with TFTP options.
3. Launch tcpdump/wireshark on DHCP server or anywhere on the network (DISCOVER, OFFER and REQUEST are all broadcasts) and observe captured traffic.
4. Run the RPi on.

Expected behaviour RFC2131 Section 3.1.3 and 3.1.4 clearly mandate what should happen next:

1. RPI netbootcode should consume a DHCPOFFER and send a DHCPREQUEST to the server that produced it to actually request that IP from the server.
2. The server in turn will reply with DHCPACK confirming IP selection or DHCPNAK if the previously offered IP has been allocated.
3. Then and only then, should netbootcode actually go for TFTP server having received confirmation it can use the offered IP.

Actual behaviour Without confirming with the DHCP that offered it the requested configuration, RPi netbootcode uses the IP offered. Problem is, in a busy environment this may result in conflicts, offer thrashing and mess on the network where offered IPs are reused and doubly allocated.

System

• Which model of Raspberry Pi? Pi3B+, Pi2Bv1.1
• Which OS and version (cat /etc/rpi-issue)? bootcode.bin https://github.com/raspberrypi/firmware/blob/a6496ae5cd5e9b4cd5b38f7274fa94dce315fa7a/boot/bootcode.bin
• Which firmware version (vcgencmd version)? N/A
• Which kernel version (uname -a)? N/A

Logs Attached.

Additional context None.

[arcivanov]

dhcp_discover_offer_no_request_or_ack.dump.tar.gz

[pelwell]

Duplicate of #991, which was declared "unfixable" - presumably because the DHCP handling is in the ROM.

[arcivanov]

There is no failure to boot in my case.

[arcivanov]

@pelwell ah, I think you meant this: https://github.com/raspberrypi/firmware/issues/986 ?

[pelwell]

No - I meant #911 because of the discussion between maxnet and ghollingworth, ending in the "unfixable" comment.

[arcivanov]

No - I meant #911

You mean #991 :smile: Thing is, there are a lot of issues in that single bug. Not sure which one referred to as "unfixable" plus it was 4 years since, you could always send a DHCPREQUEST from bootcode.bin before TFTP kicks in even if ROM ends its DHCP stack at receiving an OFFER.

[arcivanov]

That is TFTP code was for sure entirely replaced by bootcode.bin (ROM TFTP doesn't use options at all, while bootcode.bin one does RRQ with tsize option). In that case even if DHCP is entirely in ROM, the continuation of the REQUEST/ACK combo could be added prior to TFTP and if NACK is received you simply reboot and try again from ROM in hopes that you get another IP and that one sticks.