PDA

View Full Version : dhcpd does not allow filename option with a colon in it



tudo
20-Oct-2014, 09:41
For some reason, tftpboot does not work with a colon in filename parameter:


group {
filename "node7:linux/pxelinux.0";

host machine_7a {
hardware ethernet 02:01:02:02:01:11;
fixed-address 192.168.10.8;
}

host machine_7b {
hardware ethernet 02:01:02:02:01:12;
fixed-address 192.168.10.9;
}
}


If I change the colon to a dash: -, the remote machines can tftpboot fine. Do you know why a colon in the filename parameter doesn't work?

jmozdzen
21-Oct-2014, 09:47
Hi tudo,

> For some reason, tftpboot does not work with a colon in filename parameter:

could you please be more specific on "how" it doesn't work (error messages,...) and what OS (incl. level) is involved on the server and client side?

Regards,
Jens

tudo
23-Oct-2014, 09:04
Hi tudo,

> For some reason, tftpboot does not work with a colon in filename parameter:

could you please be more specific on "how" it doesn't work (error messages,...) and what OS (incl. level) is involved on the server and client side?

Regards,
Jens

Hi Jens,

Sorry for the late response. My system is using SLES in KVM environment.

Output from `/var/log/message` when I set the `filename` to `"node7-linux/pxelinux.0"`


Jan 22 22:52:48 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:11 via br0
Jan 22 22:52:48 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 22:52:49 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:11 via br0
Jan 22 22:52:49 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 22:52:51 linux-yp1y dhcpd: DHCPREQUEST for 192.168.10.7 (192.168.10.1) from 02:01:02:02:01:11 via br0
Jan 22 22:52:51 linux-yp1y dhcpd: DHCPACK on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 22:52:51 linux-yp1y atftpd[12967]: Serving node7-linux/pxelinux.0 to 192.168.10.7:1024
Jan 22 22:52:51 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:11 via br0
Jan 22 22:52:51 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 22:52:52 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:11 via br0
Jan 22 22:52:52 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 22:52:54 linux-yp1y dhcpd: DHCPREQUEST for 192.168.10.7 (192.168.10.1) from 02:01:02:02:01:11 via br0
Jan 22 22:52:54 linux-yp1y dhcpd: DHCPACK on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 22:52:54 linux-yp1y atftpd[12967]: Serving node7-linux/pxelinux.cfg/default to 192.168.10.7:1024
Jan 22 22:52:54 linux-yp1y atftpd[12967]: Serving node7-linux/vmlinuz to 192.168.10.7:1025
Jan 22 22:52:55 linux-yp1y atftpd[12967]: Serving node7-linux/initrd to 192.168.10.7:1026
Jan 22 22:53:14 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:11 via br0
Jan 22 22:53:14 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 22:53:14 linux-yp1y dhcpd: DHCPREQUEST for 192.168.10.7 (192.168.10.1) from 02:01:02:02:01:11 via br0
Jan 22 22:53:14 linux-yp1y dhcpd: DHCPACK on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 22:53:15 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:12 via br0
Jan 22 22:53:15 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.8 to 02:01:02:02:01:12 via br0
Jan 22 22:53:15 linux-yp1y dhcpd: DHCPREQUEST for 192.168.10.8 (192.168.10.1) from 02:01:02:02:01:12 via br0
Jan 22 22:53:15 linux-yp1y dhcpd: DHCPACK on 192.168.10.8 to 02:01:02:02:01:12 via br0

Output from `/var/log/message` when I set the `filename` to `"node7:linux/pxelinux.0"`:


Jan 22 23:16:57 linux-yp1y kernel: [343021.700191] br0: port 6(vnet6) entering forwarding state
Jan 22 23:16:57 linux-yp1y kernel: [343021.700296] device vnet6 left promiscuous mode
Jan 22 23:16:57 linux-yp1y kernel: [343021.700302] br0: port 6(vnet6) entering disabled state
Jan 22 23:16:57 linux-yp1y kernel: [343021.721423] br0: port 7(vnet7) entering forwarding state
Jan 22 23:16:57 linux-yp1y kernel: [343021.721467] device vnet7 left promiscuous mode
Jan 22 23:16:57 linux-yp1y kernel: [343021.721470] br0: port 7(vnet7) entering disabled state
Jan 22 23:16:58 linux-yp1y kernel: [343021.742969] br2: port 4(vnet8) entering forwarding state
Jan 22 23:16:58 linux-yp1y kernel: [343021.743040] device vnet8 left promiscuous mode
Jan 22 23:16:58 linux-yp1y kernel: [343021.743042] br2: port 4(vnet8) entering disabled state
Jan 22 23:16:58 linux-yp1y ifdown: vnet6
Jan 22 23:16:58 linux-yp1y ifdown: Interface not available and no configuration found.
Jan 22 23:16:58 linux-yp1y ifdown: vnet7
Jan 22 23:16:58 linux-yp1y ifdown: Interface not available and no configuration found.
Jan 22 23:16:58 linux-yp1y ifdown: vnet8
Jan 22 23:16:58 linux-yp1y ifdown: Interface not available and no configuration found.
Jan 22 23:17:01 linux-yp1y kernel: [343025.377050] device vnet6 entered promiscuous mode
Jan 22 23:17:01 linux-yp1y kernel: [343025.393810] br0: port 6(vnet6) entering forwarding state
Jan 22 23:17:01 linux-yp1y kernel: [343025.393814] br0: port 6(vnet6) entering forwarding state
Jan 22 23:17:01 linux-yp1y kernel: [343025.449562] device vnet7 entered promiscuous mode
Jan 22 23:17:01 linux-yp1y kernel: [343025.466276] br0: port 7(vnet7) entering forwarding state
Jan 22 23:17:01 linux-yp1y kernel: [343025.466280] br0: port 7(vnet7) entering forwarding state
Jan 22 23:17:01 linux-yp1y kernel: [343025.557549] device vnet8 entered promiscuous mode
Jan 22 23:17:01 linux-yp1y kernel: [343025.574265] br2: port 4(vnet8) entering forwarding state
Jan 22 23:17:01 linux-yp1y kernel: [343025.574270] br2: port 4(vnet8) entering forwarding state
Jan 22 23:17:03 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:11 via br0
Jan 22 23:17:03 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 23:17:04 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:11 via br0
Jan 22 23:17:04 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 23:17:05 linux-yp1y kernel: [343029.580829] br2: port 4(vnet8) entering forwarding state
Jan 22 23:17:06 linux-yp1y dhcpd: DHCPREQUEST for 192.168.10.7 (192.168.10.1) from 02:01:02:02:01:11 via br0
Jan 22 23:17:06 linux-yp1y dhcpd: DHCPACK on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 23:17:06 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:12 via br0
Jan 22 23:17:06 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.8 to 02:01:02:02:01:12 via br0
Jan 22 23:17:07 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:12 via br0
Jan 22 23:17:07 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.8 to 02:01:02:02:01:12 via br0
Jan 22 23:17:09 linux-yp1y dhcpd: DHCPREQUEST for 192.168.10.8 (192.168.10.1) from 02:01:02:02:01:12 via br0
Jan 22 23:17:09 linux-yp1y dhcpd: DHCPACK on 192.168.10.8 to 02:01:02:02:01:12 via br0
Jan 22 23:17:12 linux-yp1y kernel: [343035.804008] vnet8: no IPv6 routers present
Jan 22 23:17:12 linux-yp1y kernel: [343036.148005] vnet7: no IPv6 routers present
Jan 22 23:17:12 linux-yp1y kernel: [343036.397004] vnet6: no IPv6 routers present
Jan 22 23:17:24 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:11 via br0
Jan 22 23:17:24 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 23:17:25 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:11 via br0
Jan 22 23:17:25 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 23:17:27 linux-yp1y dhcpd: DHCPREQUEST for 192.168.10.7 (192.168.10.1) from 02:01:02:02:01:11 via br0
Jan 22 23:17:27 linux-yp1y dhcpd: DHCPACK on 192.168.10.7 to 02:01:02:02:01:11 via br0
Jan 22 23:17:27 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:12 via br0
Jan 22 23:17:27 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.8 to 02:01:02:02:01:12 via br0
Jan 22 23:17:28 linux-yp1y dhcpd: DHCPDISCOVER from 02:01:02:02:01:12 via br0
Jan 22 23:17:28 linux-yp1y dhcpd: DHCPOFFER on 192.168.10.8 to 02:01:02:02:01:12 via br0
Jan 22 23:17:30 linux-yp1y dhcpd: DHCPREQUEST for 192.168.10.8 (192.168.10.1) from 02:01:02:02:01:12 via br0
Jan 22 23:17:30 linux-yp1y dhcpd: DHCPACK on 192.168.10.8 to 02:01:02:02:01:12 via br0

jmozdzen
23-Oct-2014, 11:24
Hi tudo,

it does look like dhcpd is doing it's job, but the tftp client doesn't work like you want it to. This is not fully unexpected - the colon in the file name has a special meaning:

From "man tftp":


get file1 file2 file3...
Get a file or set of files from the specified sources. A remote filename can be in one of two forms: a plain filename on the remote host, if the host has already been specified, or a string of the form host:filename
to specify both a host and filename at the same time. If the latter form is used, the last hostname specified becomes the default for future transfers. Enable literal mode to prevent special treatment of the ':'
character (e.g. C:\dir\file).
So you're basically telling the client to grab the file "linux/pxelinux.0" from host "node7", but seem to expect aftpd output on host "linux-yp1y"...

Regards,
Jens

tudo
23-Oct-2014, 11:40
Hi tudo,

it does look like dhcpd is doing it's job, but the tftp client doesn't work like you want it to. This is not fully unexpected - the colon in the file name has a special meaning:

From "man tftp":

So you're basically telling the client to grab the file "linux/pxelinux.0" from host "node7", but seem to expect aftpd output on host "linux-yp1y"...

Regards,
Jens

I tried:
tcpdump -i br0

Here is the output when I do not use a colon in filename option:


tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
01:25:48.394178 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:11 (oui Unknown), length 398
01:25:48.394495 IP 192.168.10.1.bootps > 192.168.10.17.bootpc: BOOTP/DHCP, Reply, length 300
01:25:49.363506 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:11 (oui Unknown), length 398
01:25:49.363728 IP 192.168.10.1.bootps > 192.168.10.17.bootpc: BOOTP/DHCP, Reply, length 300
01:25:51.341024 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:11 (oui Unknown), length 410
01:25:51.341173 IP 192.168.10.1.bootps > 192.168.10.17.bootpc: BOOTP/DHCP, Reply, length 300
01:25:51.344876 arp who-has 192.168.10.1 tell 192.168.10.17
01:25:51.344909 arp reply 192.168.10.1 is-at 00:13:5e:e9:05:d6 (oui Unknown)
01:25:51.345058 IP 192.168.10.17.1024 > 192.168.10.1.tftp: 51 RRQ "node7-linux/pxelinux.0" octet blksize 1432 tsize 0


Here is the output when I use a colon in filename option:


tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
01:29:50.302920 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:11 (oui Unknown), length 398
01:29:50.303457 IP 192.168.10.1.bootps > 192.168.10.17.bootpc: BOOTP/DHCP, Reply, length 300
01:29:51.271726 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:11 (oui Unknown), length 398
01:29:51.271935 IP 192.168.10.1.bootps > 192.168.10.17.bootpc: BOOTP/DHCP, Reply, length 300
01:29:53.249172 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:11 (oui Unknown), length 410
01:29:53.249297 IP 192.168.10.1.bootps > 192.168.10.17.bootpc: BOOTP/DHCP, Reply, length 300
01:29:53.256156 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:12 (oui Unknown), length 398
01:29:53.256258 IP 192.168.10.1.bootps > 192.168.10.18.bootpc: BOOTP/DHCP, Reply, length 300
01:29:54.237650 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:12 (oui Unknown), length 398
01:29:54.237745 IP 192.168.10.1.bootps > 192.168.10.18.bootpc: BOOTP/DHCP, Reply, length 300
01:29:56.215130 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:12 (oui Unknown), length 410
01:29:56.215246 IP 192.168.10.1.bootps > 192.168.10.18.bootpc: BOOTP/DHCP, Reply, length 300
01:30:11.071521 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:11 (oui Unknown), length 398
01:30:11.071730 IP 192.168.10.1.bootps > 192.168.10.17.bootpc: BOOTP/DHCP, Reply, length 300
01:30:12.033565 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:11 (oui Unknown), length 398
01:30:12.033658 IP 192.168.10.1.bootps > 192.168.10.17.bootpc: BOOTP/DHCP, Reply, length 300
01:30:14.010988 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:11 (oui Unknown), length 410
01:30:14.011099 IP 192.168.10.1.bootps > 192.168.10.17.bootpc: BOOTP/DHCP, Reply, length 300
01:30:14.017935 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:12 (oui Unknown), length 398
01:30:14.018026 IP 192.168.10.1.bootps > 192.168.10.18.bootpc: BOOTP/DHCP, Reply, length 300
01:30:14.999458 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:12 (oui Unknown), length 398
01:30:14.999550 IP 192.168.10.1.bootps > 192.168.10.18.bootpc: BOOTP/DHCP, Reply, length 300
01:30:16.977000 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:01:02:02:01:12 (oui Unknown), length 410

How can I tell if it is the problem of atftpd? All I see are DHCP packages.

And how do I allow colon in the "filename" option? I had a system that allows DHCPD configuration with colon in "filename"; now I want to replicate similar DHCPD configuration that can accept colon in "filename".

jmozdzen
23-Oct-2014, 12:01
Hi tudo,

I tried: [CODE]How can I tell if it is the problem of atftpd? All I see are DHCP packages.

And how do I allow colon in the "filename" option? I had a system that allows DHCPD configuration with colon in "filename"; now I want to replicate similar DHCPD configuration that can accept colon in "filename".

I don't yet see that it is a problem of atftpd, nor do I see that the colon isn't allowed. To me it looks like everything works as expected.

The man page quote from my earlier message was about the tftp *client* - the one invoked on the *client* system (the machine you're trying to boot) to grab the boot file. By your configuration, you're telling that client to grab the file from a different host (and to use only the text after the colon as the file name).

Why are you including such special characters in the file name at all? Depending on which client will be used to fetch the boot file (and that might be some PXE boot code in a network card), the interpretation of the colon may differ. Restrict yourself to unambiguous file names, to be on the safe side.

Regards,
Jens

tudo
23-Oct-2014, 13:00
Hi tudo,


I don't yet see that it is a problem of atftpd, nor do I see that the colon isn't allowed. To me it looks like everything works as expected.

The man page quote from my earlier message was about the tftp *client* - the one invoked on the *client* system (the machine you're trying to boot) to grab the boot file. By your configuration, you're telling that client to grab the file from a different host (and to use only the text after the colon as the file name).

Why are you including such special characters in the file name at all? Depending on which client will be used to fetch the boot file (and that might be some PXE boot code in a network card), the interpretation of the colon may differ. Restrict yourself to unambiguous file names, to be on the safe side.

Regards,
Jens

I see, thanks. I will check the my PXE configuration of my machine. The reason I do this is for backward compatible. I have a test suite that assumes pathname with colon in it. I need to make this work, so I don't have to modify the test library.