@Jeremy That capture is the answer we’ve been missing. Thank you — text from a terminal is exactly what I needed.
Read it with me:
13:58:46.427 and 13:58:46.457: two packets from 88:a2:9e:53:34:c0, 30 ms apart. That’s the Pi firmware’s DHCP: discover, then request. A clean, complete exchange in under a second (the offer and ack come back unicast, so the FOG server doesn’t see those, which is fine). 13:59:53.647: one packet. That’s during U-Boot’s phase. But your screen shows U-Boot broadcasting fifteen or more times across its retry cycles. Only one of them reached the network segment the FOG server is on, and that one wasn’t answered as far as U-Boot could tell.So: the DHCP server is fine, the reservation is fine, ethaddr is correct (thanks for checking), and FOG’s side is proven. What’s broken is that almost every frame U-Boot sends is disappearing between the Pi and the rest of the LAN, while the firmware’s frames, seconds earlier on the same cable, all get through. That is not a FOG problem and not an OPNsense problem. It’s either the managed switch port treating U-Boot’s traffic differently (broadcast storm control, DHCP snooping rate limits, port security, or STP re-evaluating the port), or U-Boot’s Ethernet driver failing to put most of its packets on the wire. Both are real possibilities, and one test separates them, which is the one I asked for on the 4th and still haven’t seen:
Put a cheap unmanaged switch between the Pi and the wall. Wall cable into the little switch, Pi into the little switch. Power-cycle the Pi with the same tcpdump running on the FOG server.
If U-Boot’s DHCP now binds and you see its broadcasts arriving in the capture → the managed port is the problem. Give your colleagues the two captures side by side (with and without the little switch) and the port number; that’s everything they need. If it still fails and the capture still shows almost nothing from the Pi during U-Boot’s phase → it’s U-Boot’s driver on this board, and we look at which U-Boot build you’re running (version at the prompt, paste the first two lines).One more piece for Monday, since it’s free: ask whoever runs OPNsense to look at its DHCP log for 88:a2:9e:53:34:c0 around 13:59:53 today. If OPNsense saw that one packet and sent an offer that never made it back, that’s the switch dropping traffic in both directions, and it’s another line of evidence for the port.
