raspberrypi
Incorrect arch code sent during network boot using IPv4
Describe the bug IPv4 based network boot sends arch code 0000 (corresponding to x86 BIOS) making it impossible for the dhcp server to identify the client architecture and send the correct dhcp options and binaries for the rpiboot. Therefore, there is no way to network boot rpi and x86 hosts on the same network environment.
To reproduce Enable rpi network boot, capture dhcp discover packet sent from the pi while booting.
Expected behavior
Option 93 = 41 (0x00 0x29)
Option 60 = PXEClient:Arch:00041:UNDI:002001
Actual behavior
Option 93 = 0 (0x00 0x00)
Option 60 = PXEClient:Arch:00000:UNDI:002001
Additional context Iana Processor Architecture Types and raspberry docs for network boot using DHCPv6. I understand strictly speaking there is no option in the IPv4 DHCP PXE specification to match rpiboot or arm64 in RFC 4578, but it is common practice to use the newer ones from v6 in v4, and that would make more sense than the broken "I am x86" behavior.
Duplicate of https://github.com/raspberrypi/rpi-eeprom/issues/182
Option 93 is not particularly useful here since the actual boot-architecture would be 'Broadcom VPU'. The recommended approach are to use the MAC-ADDRESS OUI or use Option 97 which describes Raspberry Pi board revision so it's possible to distinguish between different RPi boards.
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#DHCP_OPTION97
NB That https://github.com/raspberrypi/rpi-eeprom/issues/182 only applies to Pi4 and Pi5.
For Pi1-3 the network boot code is in the bootrom and can not be changed.
(You've chosen to ignore the template's section describing the system you're using).
Good point. Keeping the default behavior consistent with older boards is the reason for the Pi4 / Pi5 behavior. On Pi5 (and probably Pi4) I think it would be ok for the Option93 to be configurable from the EEPROM config with the default remaining unchanged.
Option 93 is not particularly useful here since the actual boot-architecture would be 'Broadcom VPU'
I don't follow. 0x00 0x29 arm rpiboot is already in the spec. Do you mean it is named incorrectly? Why is not useful? Is the single thing letting the server know what to do with it.
(You've chosen to ignore the template's section describing the system you're using).
sorry about that, using Pi4-400 here. Firmware:
Nov 11 2024 15:48:13
Copyright (c) 2012 Broadcom
version 903570ba72a9e117f92e5499de439f59dd96e417 (clean) (release) (start)
The recommended approach are to use the MAC-ADDRESS OUI
I am sorry but that makes no sense. MAC-ADDRESS OUI is, by design, something that can change in future batches of the same model, so match by that is no better solution.
or use Option 97 which describes Raspberry Pi board revision so it's possible to distinguish between different RPi boards.
Again, same issues, plus matching by the so called FourCC code risk matching systems that fully comply with spec and are definitelly not RPi's. If I have to modify the server to match every distinct board from every distinct manufacturer I might as well match by full mac. That is what option93 solves.
Don't get me wrong option 97 does make sense in addition to a correct arch report, but it is not a replacement for it.
Keeping the default behavior consistent with older boards is the reason for the Pi4 / Pi5 behavior.
Honestly I am not entirely sure what is the "default behavior consistency" being preserved.
This is clearly a bug, the bootloader does not inform the correct architecture and does not meet the specification. I understand strictly speaking the specification can not be met, because it does not exist, but the next best thing would be to report 41, by default, which is already the behavior in ipv6. That is also not the case, choosing to report 0, which is completely wrong, and breaking every existing system that do comply with the specification. Therefore any system relying on option93 being 0 is no better than not reading option93 at all, and certainly no one should expect that hack to be reliable.
All Pi1-3 were flashed with a bug, fine, but that is not a reason to do the same in newer, fixable systems that are currently breaking spec.
I think it would be ok for the Option93 to be configurable from the EEPROM config with the default remaining unchanged.
Why be configurable? Why enable more fragmentation?