What is dnsmasq --dhcp-vendorclass being used for?
Closed this issue · 1 comments
k8s-home/coreos-pxe-install.jsonnet
Lines 390 to 395 in e0cad51
I've been slowly learning about all the things, and now reading dnsmasq docs.
Here you're using --dhcp-vendorclass but the syntax doesn't quite match to the docs. My current guess is that you're setting tags 'BIOS', UEFI etc; but then I don't think you're referencing those tags later on?
/cc @anguslees
It's a while since I set this part up, but iirc this is necessary to set those vendorclass tags when a PXE request arrives with one of those numeric client codes.
You're right - it looks like I don't actually use those tags other than to say they are "not ipxe":
k8s-home/coreos-pxe-install.jsonnet
Line 402 in e0cad51
From memory, the resulting overall flow ends up being something like:
- legacy (non-UEFI) client gets dhcp-boot=undionly.kpxe, then retries with a PXE-capable bios
With PXE services (newer bios, or above after loading undionly) the usual BIOS PXE client gets all of the matching pxe-services, makes a nice menu, and boots the first entry after 5 seconds (pxe-prompt timeout).
The default entry causes:
- older UEFI/X86PC gets pxe-service=undionly and will retry
- newer UEFI gets the right architecture of ipxe binary and retries
Eventually, we're running ipxe and we get the full list of available tag:ipxe boot options (services).
The default is the boot.ipxe script (see ipxe_config earlier in that jsonnet file) which loads the full kernel/initrd over http (much faster than tftp, and you can even boot over the internet if you don't care about security) and then boots into full coreos ramdisk image.
Fwiw, I don't think I ever got the winpe.ipxe bit working - I stumbled across it in a blog post and thought it seemed like a funny idea. It didn't seem to work the first time I tried and I never followed through (I think maybe I had trouble generating the precise wimboot files required?)
Also note this whole setup uses "proxy DHCP", which means it doesn't actually allocate IPs and other important things - that "regular" DHCP flow is handled by my normal home modem (a little openwrt box hooked up to my internet connection). "Proxy DHCP" is a thing where extra unsolicited DHCP reply packets will also just form part of the overall DHCP response, precisely for ancillary services like boot options. I never knew that feature existed before embarking on this, and is rather terrifying - but I guess DHCP is not secure to local network attacks anyway.