[Dnsmasq-discuss] Wrong server IP in dual normal/proxyDHCP mode

Alkis Georgopoulos alkisg at gmail.com
Sat May 16 08:05:16 BST 2015


On 15/05/2015 11:13 μμ, Simon Kelley wrote:
> Do you have dhcp-boot configuration. Do they have tags to select the
> correct one depending on the efi tag you're using?


Hi Simon, here's my minimal.conf with which I can reproduce the problem:
enable-tftp
tftp-root=/var/lib/tftpboot/
dhcp-option=17,/opt/ltsp/i386
dhcp-match=set:efi,option:client-arch,7
dhcp-range=tag:!efi,10.161.254.0,proxy
dhcp-range=tag:efi,192.168.68.20,192.168.68.250,8h
dhcp-boot=tag:!efi,ltsp/i386/pxelinux.0
dhcp-boot=tag:efi,ltsp/amd64/bootnetx64.efi
pxe-service=X86PC, "Boot from network", ltsp/i386/pxelinux
pxe-service=BC_EFI,"BC_EFI: Boot from network",ltsp/amd64/bootnetx64

I actually have 2 NICs on the server, I didn't mention the second one 
because it was irrelevant, but I do have some new debugging hint so I'm 
mentioning it now.
With these IPs, I get the problem:
$ ip -oneline -family inet addr show
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever 
preferred_lft forever
2: eth0    inet 10.160.67.10/24 brd 10.160.67.255 scope global eth0\ 
    valid_lft forever preferred_lft forever
3: eth1    inet 10.161.254.11/24 brd 10.161.254.255 scope global eth1\ 
      valid_lft forever preferred_lft forever
3: eth1    inet 192.168.68.1/24 brd 192.168.68.255 scope global eth1\ 
     valid_lft forever preferred_lft forever

The problem is that the non-uefi client tries to fetch pxelinux.0 from 
192.168.68.1 instead of from 10.161.254.11.
Everything else (uefi clients etc) works fine.

Now, if I move 192.168.68.1 to my other NIC just as a test, and without 
changing anything else at all, the non-uefi client does boot fine:
alkisg at srv1-dide:~$ ip -oneline -family inet addr show
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever 
preferred_lft forever
2: eth0    inet 10.160.67.10/24 brd 10.160.67.255 scope global eth0\ 
    valid_lft forever preferred_lft forever
2: eth0    inet 192.168.68.1/24 brd 192.168.68.255 scope global eth0\ 
     valid_lft forever preferred_lft forever
3: eth1    inet 10.161.254.11/24 brd 10.161.254.255 scope global eth1\ 
      valid_lft forever preferred_lft forever

Today (Saturday) the traffic at work was minimal so I was able to 
capture a full tcpdump, in case it helps:
http://paste.debian.net/178053/

The problematic client screen is at:
http://paste.debian.net/178055/


I still haven't tested with git-trunk, but of course I have applied your 
patch to the Ubuntu 14.04's dnsmasq version.

Thanks,
Alkis



More information about the Dnsmasq-discuss mailing list