[Dnsmasq-discuss] dhcp-vendorclass with bootp

Simon Kelley simon at thekelleys.org.uk
Thu Apr 11 13:58:22 BST 2013


On 11/04/13 12:35, Peter Korsgaard wrote:
> 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?

As far as I remember, the reason was simply that I considered such 
options as DHCP options, and not part of the bootp spec. That's 
obviously wrong, just by looking at the title of RFC2132: "DHCP Options 
and BOOTP Vendor Extensions"

So, no good reason at all. I'll add it to the list for attention once 
the current 2.66 release is on it's way.


Cheers,

Simon.

>




More information about the Dnsmasq-discuss mailing list