[Dnsmasq-discuss] problem with dhcp options

[Carlos Carvalho]

I'm using the config below for dhcp in dnsmasq.

In /etc/dnsmasq.conf:

dhcp-authoritative
no-ping
leasefile-ro
domain=fisica.ufpr.br
dhcp-option=19,0
conf-file = /etc/dnsmasq/dhcp

In /etc/dnsmasq/dhcp:

dhcp-option=3,zagros
# smtp server
dhcp-option=69,hoggar
dhcp-range = 192.168.5.1,static,5m
conf-file = /etc/dnsmasq/dhcp-hosts

And this is the config for one of the machines in /etc/dnsmasq/dhcp-hosts:

dhcp-host = abiod,00:e0:7d:d0:b8:e5,id:*,net:abiod
dhcp-boot = net:abiod,/var/remoteboot/pentium-rtl8139,hoggar
dhcp-option = abiod,19,/var/nfsroot/profs-root/abiod

All names are in /etc/hosts.

First, in one of the machines that boots using bootp I noticed that it
gets it's IP and the one for the tftp server (the same that is the dns
and runs dnsmasq). However it doesn't get the gateway (zagros, see
above). Using ISC dhcpd the bootp bios prints the IP of the gateway.
It manages to load the kernel and boots it. The kernel mounts the
rootfs.

The init scripts run udhcpc, which queries the dhcp server and runs a
script to configure other mount points. udhcpc is failing with

Lease of 200.17.214.144 obtained, lease time 300
zsh: segmentation fault env - ~/udhcpc -q -s ./foo

In another machine with more recent software I get
*** glibc detected *** malloc(): memory corruption: 0x0804f278 ***
zsh: abort env - ./udhcpc -q -s ./script.udhcpc

This machine doesn't have the dhcp-option = abiod,19... in the config,
just the first two lines, because it boots via pxe.

Any ideas?

[Simon Kelley]

Post by Carlos Carvalho
I'm using the config below for dhcp in dnsmasq.
dhcp-authoritative
no-ping
leasefile-ro
domain=fisica.ufpr.br
dhcp-option=19,0
conf-file = /etc/dnsmasq/dhcp
dhcp-option=3,zagros
# smtp server
dhcp-option=69,hoggar
dhcp-range = 192.168.5.1,static,5m
conf-file = /etc/dnsmasq/dhcp-hosts
dhcp-host = abiod,00:e0:7d:d0:b8:e5,id:*,net:abiod
dhcp-boot = net:abiod,/var/remoteboot/pentium-rtl8139,hoggar
dhcp-option = abiod,19,/var/nfsroot/profs-root/abiod

Root path is option 17, not option 19. That probably explains everything
else. Option 19 is a boolean option and clients will be expecting a one
byte data field, the presence of a string is likely to confuse them.

Cheers

Simon.

[Carlos Carvalho]

Post by Simon Kelley

Post by Carlos Carvalho
I'm using the config below for dhcp in dnsmasq.
dhcp-authoritative
no-ping
leasefile-ro
domain=fisica.ufpr.br
dhcp-option=19,0
conf-file = /etc/dnsmasq/dhcp
dhcp-option=3,zagros
# smtp server
dhcp-option=69,hoggar
dhcp-range = 192.168.5.1,static,5m
conf-file = /etc/dnsmasq/dhcp-hosts
dhcp-host = abiod,00:e0:7d:d0:b8:e5,id:*,net:abiod
dhcp-boot = net:abiod,/var/remoteboot/pentium-rtl8139,hoggar
dhcp-option = abiod,19,/var/nfsroot/profs-root/abiod

Root path is option 17, not option 19. That probably explains everything
else. Option 19 is a boolean option and clients will be expecting a one
byte data field, the presence of a string is likely to confuse them.

Ops, typo. However, it didn't change anything. Further, for machines
that do pxe boot there's no root path option:

dhcp-host = teide,00:11:2f:84:22:db,id:*,net:teide
dhcp-boot = net:teide,/var/remoteboot/pxelinux.0,hoggar

and I get

*** glibc detected *** malloc(): memory corruption: 0x0804f278 ***
zsh: abort env - ./udhcpc -q -s ./script.udhcpc

[Simon Kelley]

Post by Carlos Carvalho

Post by Simon Kelley

Post by Carlos Carvalho
I'm using the config below for dhcp in dnsmasq.
dhcp-authoritative
no-ping
leasefile-ro
domain=fisica.ufpr.br
dhcp-option=19,0
conf-file = /etc/dnsmasq/dhcp
dhcp-option=3,zagros
# smtp server
dhcp-option=69,hoggar
dhcp-range = 192.168.5.1,static,5m
conf-file = /etc/dnsmasq/dhcp-hosts
dhcp-host = abiod,00:e0:7d:d0:b8:e5,id:*,net:abiod
dhcp-boot = net:abiod,/var/remoteboot/pentium-rtl8139,hoggar
dhcp-option = abiod,19,/var/nfsroot/profs-root/abiod

Root path is option 17, not option 19. That probably explains everything
else. Option 19 is a boolean option and clients will be expecting a one
byte data field, the presence of a string is likely to confuse them.

Ops, typo. However, it didn't change anything. Further, for machines
dhcp-host = teide,00:11:2f:84:22:db,id:*,net:teide
dhcp-boot = net:teide,/var/remoteboot/pxelinux.0,hoggar
and I get
*** glibc detected *** malloc(): memory corruption: 0x0804f278 ***
zsh: abort env - ./udhcpc -q -s ./script.udhcpc

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.

Cheers,

Simon.

[Carlos Carvalho]

Sorry, I only saw this msg. after replying to the other one.

Post by Carlos Carvalho
I'm using the config below for dhcp in dnsmasq.
dhcp-authoritative
no-ping
leasefile-ro
domain=fisica.ufpr.br
dhcp-option=19,0
conf-file = /etc/dnsmasq/dhcp
dhcp-option=3,zagros
# smtp server
dhcp-option=69,hoggar
dhcp-range = 192.168.5.1,static,5m
conf-file = /etc/dnsmasq/dhcp-hosts
dhcp-host = abiod,00:e0:7d:d0:b8:e5,id:*,net:abiod
dhcp-boot = net:abiod,/var/remoteboot/pentium-rtl8139,hoggar
dhcp-option = abiod,19,/var/nfsroot/profs-root/abiod
In another machine with more recent software I get
*** glibc detected *** malloc(): memory corruption: 0x0804f278 ***
zsh: abort env - ./udhcpc -q -s ./script.udhcpc

It looks like udhcp didn't behave well: you should probably use
ethereal/wireshark or tcpdump to grab a copy of the DHCP packet and send
it to the maintainers: If a broken packet make udhcp core dump, chances
are that a suitably crafted broken packet can break root. udhcp should
not be trusting its input from the net to be well-formed.

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.

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

I've put the right number for root path.

Why?

[Simon Kelley]

Post by Carlos Carvalho
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.

Post by Carlos Carvalho
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.)

Post by Carlos Carvalho
I've put the right number for root path.

Are you still sending option 19 too? Is that expected?


Cheers,

Simon.

[Carlos Carvalho]

Post by Simon Kelley

Post by Carlos Carvalho
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.

Post by Simon Kelley

Post by Carlos Carvalho
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.

Post by Simon Kelley
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.

Post by Simon Kelley
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 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.

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.

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.

[Simon Kelley]

Post by Carlos Carvalho

Post by Simon Kelley

Post by Carlos Carvalho
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.

Post by Simon Kelley

Post by Carlos Carvalho
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.

Post by Carlos Carvalho

Post by Simon Kelley
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.

Post by Simon Kelley
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.

Post by Carlos Carvalho
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.

Post by Carlos Carvalho
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.

Post by Carlos Carvalho
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.

Post by Carlos Carvalho
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss