[Dnsmasq-discuss] problem with dhcp options

[Simon Kelley]

Carlos Carvalho wrote:
> Simon Kelley (simon at thekelleys.org.uk) wrote on 5 January 2007 15:26:
>  >Carlos Carvalho wrote:
>  >
>  >> Agreed. Also I can probably hack around and not use udhcpc, will try
>  >> it now. However, there are more problems. First, machines don't get a
>  >> default route, which should be provided by the dhcp-option=3,zagros
>  >> line. I tested with two linux distributions (gentoo included), windows
>  >> 98 and xp.
>  >
>  >Apologies for missing this: you cannot use a hostname there: you need
>  >the dotted-quad IP address.
> 
> That solved the default route problem, thanks.
> 
>  >> Second, I'm getting this in the logs for some machines:
>  >> 
>  >>  dnsmasq[15527]: cannot send DHCP option 17: no space left in packet
>  >>  dnsmasq[15527]: cannot send DHCP option 19: no space left in packet
>  >> 
>  >
>  >Pretty much what it says: you are trying to send more stuff than will
>  >fit. The client can indicate an ability to accept packets larger than
>  >the small default, so this might be client-related. (ISTR that windows
>  >offers larger packets, I doubt that udhcpc does.)
> 
> Hmm... This never happens with ISC dhcpd... Of course it can be a bug
> in dhcpd for not respecting the packet size but everything has always
> worked with it.

dhcpd can use a couple of fields in the fixed part of the DHCP packet as 
extra space for options. dnsmasq will understand such packets, but it 
doesn't generate them. That might explain the difference.
> 
>  >Are you still sending option 19 too? Is that expected?
> 
> Yes but not useful so I removed it but didn't help with the space
> problem.
> 
> I got rid of udhcpc but several machines still didn't boot because
> they didn't get the proper root path or kernel filename. I managed to
> find a small enough config to fit in the packet, and it works for all
> machines. This means that the truncation of packets is really the
> problem. Also udhcpc works when there's no truncation. We still have
> to find out whose fault it is.
> 
> Simon Kelley (simon at thekelleys.org.uk) wrote on 5 January 2007 14:25:
>  >Please could you capture the packets in question and send them to me?
>  >
>  >tcpdump -i <interface> -s 0 -w /tmp/dump
>  >
>  >on the machine running dnsmasq should do it.
> 
> I knew you'd ask for this :-( :-( Of course I must try to do it. Right
> now tcpdump doesn't run because I didn't compile the packet socket in
> the kernel...
> 

I would be useful to see what's going on. Even if you run tcpdump on a 
third machine and only grab the brodcast packets, that's a help.

> I think the manual should make clear some details that are important
> in problem cases. First, dhcp-option=3,... It should be stated that
> an ip must be used, not a name. Talking about it, it should be made
> clear in *all cases* if a name is acceptable. Further, it should be
> said if the name must be in one of the hosts files or if the upstream
> servers will be queried, and what happens when a name isn't found.
 >
 > Why are names accepted in some cases, like dhcp-host, and not in
 > others? At first sight this is not very consistent.
 >
Dnsmasq never does a hostname->IP lookup. For cases where

dhcp-option=<option-number>,<name>

is allowed, that's because the option is defined (in RFC2132) to be an 
ascii string, if the option needs an IP address, then it must appear as

dhcp-option=<option-number>,<dotted-quad>

Dnsmasq doesn't have built-in knowledge of the data types expected by 
options [1], if you put

dhcp-option=3,6.7.8.9

in /etc/dnsmasq.conf then it will put the bytes

3,4,6,7,8,9

in the packet. If you put

dhcp-option=3,wibble

then you will get

3,6,<w>,<i>,<b>,<b>,<l>,<e>

dnsmasq interprets the data simply by matching it as IP-addresses, 
numbers, or strings.

This explains why you got illegal packets which crashed udhcpc: my guess 
is that it assumes any option-3 to be a multiple of four bytes and loses 
synchronisation when presented with a illegal length-five option.

It's arguably a mistake that dnsmasq doesn't know about options, their 
names, and the type of data they encode, but it is pretty consistent. 
You can use a string where that string will be sent to the client, of 
you are sending an IP address then you need to give that. If you want to 
send a string which looks like an IP address, you have to put it in quotes.

[1] there are a few options numbers hard-coded in, for example 119 which 
takes a string as the search path, but requires that the string be 
endoded in a special way.



> It should also be said that if you give a hostname in the dhcp-host
> declaration it'll define the hostname and be sent to the client.
> Further, it should be said that dhcp-option = 12,... is ignored!!
> I find this behavior undesirable. It's ok to define it via dhcp-host
> but not ignore in the specific setting.

I think the rationalle there was that setting option 12 would not be the 
same as putting a name in dhcp-host, (the DNS effects would not happen) 
so it's more confusing to allow this.
> 
> The manual should also tell that the automatic sending of a parameter
> can be cancelled by setting that parameter to null with an empty
> declaration, such as dhcp-option=3 cancels sending the default router.
> 

Hmm, you are right: an accidental ommision. The best place to include 
that is probably the example configuration file.

> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>