[Dnsmasq-discuss] dhcp-vendorclass with bootp
Peter Korsgaard
jacmet at sunsite.dk
Thu Apr 11 12:35:53 BST 2013
Hi,
I would like to use dnsmasq to bringup a TI arm SoC which can bootstrap
itself from bootp/tftp. The bootstrap happens in several steps, so
dnsmasq needs to send the correct bootfile depending on the step, which
can be detected by the vendor-class option.
Unfortunately this doesn't currently work :/
The initial bootrequest package looks like this:
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 84:7e:40:dd:c9:ca (oui Unknown), length 364, xid 0x1, Flags [none]
Client-Ethernet-Address 84:7e:40:dd:c9:ca (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
Vendor-Class Option 60, length 15: "DM814x ROM v1.0"
Client-ID Option 61, length 81: hardware-type 5, 01:05:01:81:40:07:02:13:02:01:00:12:15:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:14:21:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:15:09:01:d2:16:71:25:00:00:00:00
Ignore for a second that this isn't valid bootp as the vendor area is
longer than 64 bytes.
I was expecting to simply be able to do something like:
dhcp-vendorclass=set:ti,DM814x
# serve this to the boot rom
dhcp-boot=tag:ti,MLO
# and this to u-boot
dhcp-boot=uImage
But the ti tag never gets set. Looking at rfc2131.c, I see that the
vendor class matching isn't done for bootp requests. I don't really know
my way around the dnsmasq code, but a quick test with copying the vendor
matching code above the log_tags() line for bootp (rc2131.c:446) seems
to do the trick.
Is there any reason why the vendor matching isn't done for bootp?
--
Bye, Peter Korsgaard
More information about the Dnsmasq-discuss
mailing list