[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