Re: [Dnsmasq-discuss] Windows Server 2008 R2 issue

Mon, 15 Oct 2012 11:14:11 -0700 

On 10/15/2012 06:58 AM, Simon Kelley wrote:

On 13/10/12 17:34, Brian Haley wrote:

Hi,

I'm having trouble getting a Windows Server 2008 R2 virtual machine to
get a
lease from dnsmasq running on Ubuntu Linux.  An R1, and any other OS,
has no
problems.  The version of dnsmasq is 2.58-3.

My config is as follows:

eth0 - public interface - IP 15.3.2.1 (that's not my real IP)
brx1 - private bridge   - IP 10.13.128.1
vnetX - taps attached to the bridge

Here's the ps output for dnsmasq:

20761 ?        S      0:00 dnsmasq --strict-order --bind-interfaces
--conf-file=/var/lib/nova/networks/dnsmasq.conf --domain=novalocal
--pid-file=/var/lib/nova/networks/nova-brx1.pid
--listen-address=10.13.128.1
--except-interface=lo --dhcp-range=10.13.128.2,static,255.255.224.0,900s
--dhcp-lease-max=8192
--dhcp-hostsfile=/var/lib/nova/networks/nova-brx1.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro


<snip>


But for the R2 server I see:

21:26:10.522156 02:16:3e:4b:cc:53 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800),
length 342: (tos 0x0, ttl 128, id 346, offset 0, flags [none], proto
UDP (17),
length 328)
     0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
02:16:3e:4b:cc:53,
length 300, xid 0xcc8a146d, secs 6656, Flags [Broadcast]
           Client-Ethernet-Address 02:16:3e:4b:cc:53
           Vendor-rfc1048 Extensions
             Magic Cookie 0x63825363
             DHCP-Message Option 53, length 1: Discover
             NOAUTO Option 116, length 1: Y
             Client-ID Option 61, length 7: ether 02:16:3e:4b:cc:53
             Hostname Option 12, length 15: "WIN-OE4E9RLAG6M"
             Vendor-Class Option 60, length 8: "MSFT 5.0"
             Parameter-Request Option 55, length 12:
               Subnet-Mask, Domain-Name, Default-Gateway,
Domain-Name-Server
               Netbios-Name-Server, Netbios-Node, Netbios-Scope,
Router-Discovery
               Static-Route, Classless-Static-Route,
Classless-Static-Route-Microsoft, Vendor-Option

21:26:10.522590 02:16:3f:0c:10:0d > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800),
length 345: (tos 0x0, ttl 64, id 58362, offset 0, flags [none], proto
UDP (17),
length 331)
     15.3.2.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 303, xid
0xcc8a146d, secs 6656, Flags [Broadcast]
           Your-IP 10.13.128.194
           Server-IP 10.13.128.1
           Client-Ethernet-Address 02:16:3e:4b:cc:53
           Vendor-rfc1048 Extensions
             Magic Cookie 0x63825363
             DHCP-Message Option 53, length 1: Offer
             Server-ID Option 54, length 4: 10.13.128.1
             Lease-Time Option 51, length 4: 900
             RN Option 58, length 4: 450
             RB Option 59, length 4: 787
             Subnet-Mask Option 1, length 4: 255.255.224.0
             BR Option 28, length 4: 10.13.159.255
             Default-Gateway Option 3, length 4: 10.13.128.1
             Domain-Name-Server Option 6, length 4: 10.13.128.1
             Domain-Name Option 15, length 9: "novalocal"

Notice the source IP address here is that of my Internet-facing
interface, not
the IP on the bridge.  That's actually causing me to drop the packet
on the
bridge due to an ebtables rule that only allows responses from
10.13.128.1 (for
security reasons).  Since I'm starting dnsmasq to only listen on that
IP, I
don't know why it's responding using the other, unless the Linux
network stack
is doing that?

The only thing I've noticed that's different is that in the R2 request
there is
an additional option:

    NOAUTO Option 116, length 1: Y

Is that possibly causing dnsmasq to respond differently?  I haven't
dug into the
code yet, figured I'd ask on the list in case it's been seen before.



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. 


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. 

Thanks,

-Brian

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

Reply via email to