@Seydoo said in No DHCP after PxE Menu:
I am really convinced of a network problem (snapping tree for example), but I can’t prove it and it annoys me because without it, I can’t ask the network team to solve my problem.
Well that dumb switch is the easiest and best way to prove it. What I suspect is going on here is as the pxe booting computer boots, it will momentarily drop the network link ask each kernel hands off control to the next one. You will see this network “wink” when the PXE boot ROM hands over control to the iPXE boot kernel, and then again when iPXE hands over control to the FOS kernel (bzImage).
Now where spanning tree comes into play is if standard spanning tree is used, standard spanning tree uses pessimistic blocking in that it won’t forward any data until 27 seconds after the link goes up. During this 27 seconds its listening for duplicate BPDU packets. If it hears none then it starts forwarding data. If one of the fast spanning tree protocols are used (fast-stp, rstp, mstp, etc) they use optimistic blocking in that they start forwarding right away while listening for a duplicate BPDU packet.
The problem is this, if standard spanning tree is used, that 27 second delay before forwarding to too long of a time. FOS boots and is ready to go so fast, but the time 27 seconds come and the port starts forwarding data FOS has already given up trying to get a network address. But if you boot into debug mode and issue the udhcpc command, that is probably after the 27 second timeout and it gets an IP address like it should.
That is at least that’s the way I see why it’s not working.