[Dnsmasq-discuss] Windows Server 2008 R2 issue

Simon Kelley simon at thekelleys.org.uk
Mon Oct 15 20:57:15 BST 2012


On 15/10/12 19:12, Brian Haley wrote:

>>
>> The option 116 thing is a red herring. I think the crucial difference
>> between R1 and R2 is that R2 is R2 is setting the Broadcast flag in its
>> requests, so that dnsmasq is sending replies to 255.255.255.255.
>
> Thanks, I looked at that trace many times and never noticed that,
> strange that R2 would have changed something like this.
>
>> Dnsmasq is not explicitly setting the source address, so that's coming
>> from the Linux kernel, it looks like it's making a bad call under these
>> circumstances.
>
> Is dnsmasq choosing the interface? Like using SO_BINDTODEVICE? I should
> go look, but it must be doing something since it's going out onto the
> bridge and not out eth0 where my default route is pointing. I would have
> hoped the kernel would have chosen the address on the bridge, but I can
> look into why it didn't.

Dnsmasq sends the packet with an IP_PKTINFO option, this has two fields 
of interest, ipi_ifindex and ipi_spec_dst. ipi_ifindex is set to the 
index of the interface, and ipi_spec_dst is set to zero, According to 
man 7 ip:

  If IP_PKTINFO is passed to sendmsg(2) and  ipi_spec_dst  is  not  zero,
  then  it  is  used  as  the  local  source  address for the routing
  table lookup and for setting up IP source route options.  When
  ipi_ifindex is not zero, the primary local address of the interface
  specified by the index overwrites ipi_spec_dst for the routing
  table lookup.

Which implies that you shouldn't be seeing the behaviour you are.....

The relevant code is here:


http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/dhcp.c;h=75a4427fe82d6964113c069ff91c8e48a92a955c;hb=HEAD#l336




>
>> A tweak to your firewall rules to accept all packets to 255.255.255.255
>> may be a good solution.
>
> The problem isn't the destination address, but the source, since we're
> trying to catch anyone spoofing the DHCP server, but I may be able to
> write an iptables rule to catch this case and change the source IP to be
> correct.

Understood, in my experience firewalls which don't unconditionally 
accept packets with destination 255.255.255.255 can often cause DHCP 
problems. The same is true for packets with source address 0.0.0.0


Cheers,

Simon.




More information about the Dnsmasq-discuss mailing list