[Dnsmasq-discuss] vendorclass

Simon Kelley simon at thekelleys.org.uk
Thu Feb 23 09:30:12 GMT 2006


Dirk Stichling wrote:
> Hi.
> 
> 
>>>I have the following problem:
>>>My DHCP-client has a two stage boot procedure. During the first stage it
>>>sends a BOOTP-Request with no vendorclass. During the second stage it
>>>sends another BOOTP-Request with a vendorclass (containing the word
>>>box). During the first stage dnsmasq shall answer with a bootfile
>>>"u-boot" und during the second stage it shall answer with a bootfile
>>>"kernel".
>>>I tried different configurations, e.g.:
>>>
>>>dhcp-vendorclass=kernel,box
>>>dhcp-boot=u-boot,niagara
>>>dhcp-boot=net:kernel,kernel,niagara
>>>
>>>But dnsmasq always sends u-boot.
>>>
>>>Is there a way to configure my scenario?
>>
>>If your client is doing DHCP, that should work fine, but your mention of 
>>"BOOTP-Request" might imply that one or both of these interactions might 
>>  BOOTP, and not DHCP. If so, the vendorclass facility is not enabled 
>>for BOOTP.
>>
>>Please could you clarify if we are talking about DHCP or BOOTP here (If 
>>you are not sure, then check your logs, dnsmasq logs BOOTP and DHCP 
>>differently.)
> 
> 
> Here is the log:
> Feb 22 21:33:54 (none) local0.info dnsmasq: started, version 2.22 cachesize
> 150
> Feb 22 21:33:54 (none) local0.info dnsmasq: DHCP, IP range 10.0.1.100 --
> 10.0.1.200, lease time 2h
> Feb 22 21:33:54 (none) local0.info dnsmasq: using local addresses only for
> domain tichel.local
> Feb 22 21:33:54 (none) local0.info dnsmasq: read /etc/hosts - 5 addresses
> Feb 22 21:33:54 (none) local0.info dnsmasq: reading /etc/resolv.conf
> Feb 22 21:33:54 (none) local0.info dnsmasq: using nameserver 10.0.1.1#53
> Feb 22 21:33:54 (none) local0.info dnsmasq: using local addresses only for
> domain tichel.local
> Feb 22 21:34:00 (none) local0.info dnsmasq: BOOTP(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:01 (none) daemon.notice atftpd[1839]: Serving u-boot to
> 10.0.1.41:2001
> Feb 22 21:34:02 (none) local0.info dnsmasq: DHCPDISCOVER(eth0)
> 00:50:9c:2a:69:ed
> Feb 22 21:34:02 (none) local0.info dnsmasq: DHCPOFFER(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:02 (none) local0.info dnsmasq: DHCPREQUEST(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:02 (none) local0.info dnsmasq: DHCPACK(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:03 (none) daemon.notice atftpd[1840]: Serving logo-lcd to
> 10.0.1.41:1506
> Feb 22 21:34:03 (none) local0.info dnsmasq: DHCPDISCOVER(eth0)
> 00:50:9c:2a:69:ed
> Feb 22 21:34:03 (none) local0.info dnsmasq: DHCPOFFER(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:03 (none) local0.info dnsmasq: DHCPREQUEST(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:03 (none) local0.info dnsmasq: DHCPACK(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:03 (none) daemon.notice atftpd[1841]: Serving logo-fb to
> 10.0.1.41:2091
> Feb 22 21:34:07 (none) local0.info dnsmasq: DHCPDISCOVER(eth0)
> 00:50:9c:2a:69:ed
> Feb 22 21:34:07 (none) local0.info dnsmasq: DHCPOFFER(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:07 (none) local0.info dnsmasq: DHCPREQUEST(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:07 (none) local0.info dnsmasq: DHCPACK(eth0) 10.0.1.41
> 00:50:9c:2a:69:ed
> Feb 22 21:34:07 (none) daemon.notice atftpd[1842]: Serving u-boot to
> 10.0.1.41:3023
> 
> 
> Thanks,
> Dirk
> 

OK, so from the logs we can see that the first interaction is BOOTP: 
it's pointless trying to do vendorclass matching on that, but the 
configuration you posted doesn't (it relys on matching in the second stage.)

Then there are two rounds of DHCP after each of which the machine 
requests "logo-fb" from the tftp server. Since the dnsmasq config 
does'nt know anything about "logo-fb" we have to assume that this is 
some strange built-in boot stage, and not relevant.

After the final DHCP interaction, the machine again loads "u-boot". This 
is wrong. _If_ the booting machine is providing the correct vendorclass, 
and dnsmasq is configured in the way you posted, then dnsmasq will have 
provided "kernel" as the boot name. We can't tell for certain, since all 
we have is what the machine asked for on tftp.

As far as I can see, there are three possible places this could go wrong.

1) The vendorclass is missing or wrong.
2) dnsmasq is not honouring its config and sending "kernel" as the boot 
file.
2) The machine is getting "kernel" but ignoring it.

There is not enough information in that log to tell which of these is 
the problem. I suggest you use tcpdump or ethereal to sniff the traffic 
and send the packet dump to me off list. (Make sure you grab complete 
packets, ethereal will do that by default, tcpdump needs a flag.

A packet dump should contain everything we need to diagnose which stage 
is broken.

Cheers,

Simon.




More information about the Dnsmasq-discuss mailing list