search

raspberrypi / firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware.
5.15k stars 1.68k forks source link

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

Open arcivanov opened 2 years ago

arcivanov commented 2 years ago

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

Logs Attached.

Additional context None.

arcivanov commented 2 years ago

dhcp_discover_offer_no_request_or_ack.dump.tar.gz

pelwell commented 2 years ago

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

arcivanov commented 2 years ago

There is no failure to boot in my case.

arcivanov commented 2 years ago

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

pelwell commented 2 years ago

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

arcivanov commented 2 years ago

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 commented 2 years ago

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.