[Dnsmasq-discuss] Windows Server 2008 R2 issue

Simon Kelley simon at thekelleys.org.uk
Mon Oct 15 11:58:52 BST 2012


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
>
> That dnsmasq.conf file just has two srv-host lines for my windows license servers.
>
> Running tcpdump, I see plenty of "good" request/responses, for example, this is
> an R1 server:
>
> 21:35:18.255923 02:16:3e:2e:e9:b7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),
> length 342: (tos 0x0, ttl 128, id 1, 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:2e:e9:b7,
> length 300, xid 0x4a51edc4, secs 1280, Flags [none]
>            Client-Ethernet-Address 02:16:3e:2e:e9:b7
>            Vendor-rfc1048 Extensions
>              Magic Cookie 0x63825363
>              DHCP-Message Option 53, length 1: Discover
>              Client-ID Option 61, length 7: ether 02:16:3e:2e:e9:b7
>              Hostname Option 12, length 15: "WIN-HRD4U0NMS2R"
>              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:35:18.256184 02:16:3f:0c:10:0d > 02:16:3e:2e:e9:b7, ethertype IPv4 (0x0800),
> length 345: (tos 0x0, ttl 64, id 22748, offset 0, flags [none], proto UDP (17),
> length 331)
>      10.13.128.1.67 > 10.13.128.217.68: BOOTP/DHCP, Reply, length 303, xid
> 0x4a51edc4, secs 1280, Flags [none]
>            Your-IP 10.13.128.217
>            Server-IP 10.13.128.1
>            Client-Ethernet-Address 02:16:3e:2e:e9:b7
>            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"
>
> 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.

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.

A tweak to your firewall rules to accept all packets to 255.255.255.255 
may be a good solution.



Cheers,

Simon.





More information about the Dnsmasq-discuss mailing list