Discussion:
[Dnsmasq-discuss] Making dnsmasq make OFFER faster than virtualbox NAT DHCP
Sebastian Tarach
2017-01-23 01:02:51 UTC
Permalink
Hello,

I'm trying to make *dnsmasq* work on my Debian Virtualbox guest but I keep
getting reply from my VBox host DHCP first.

I have configured bridge ( br0 ) using openvswitch:

$ ovs-vsctl show
cbda5c6b-c9ba-4fb4-8143-a1f0683e1e96
Manager "ptcp:6640"
Bridge "br0"
Port "eth0"
Interface "eth0"
Port "vport1"
Interface "vport1"
Port "br0"
Interface "br0"
type: internal
ovs_version: "2.4.0"
And have *dnsmasq* running on *br0*
I have also removed configuration from *eth0*
*ifconfig eth0 0 *and set default gateway to b*r0*
*route add default gateway 192.168.1.129*
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
0.0.0.0 192.168.1.129 0.0.0.0 UG 0 0 0 br0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0
docker0
192.168.1.128 0.0.0.0 255.255.255.128 U 0 0 0 br0
192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1
But when I'm running *nmap --script broadcast-dhcp-discover -e br0*
the tdpdump process show response/OFFER from VBox DHCP comes first.

*tcpdump -i br0 -nev udp port 68*
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size
262144 bytes
01:29:51.031925 08:00:27:b6:c1:90 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 355: (tos 0x0, ttl 64, id 23681, offset 0, flags [DF],
proto UDP (17), length 341)
192.168.1.129.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
de:ad:c0:de:ca:fe, length 313, xid 0x514a3f0c, Flags [Broadcast]
Client-Ethernet-Address de:ad:c0:de:ca:fe
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, LOG, CS
LPR-Server, IM, RL, Hostname
BS, DP, Domain-Name, SS
RP, EP, IPF, SRT
PF, RSZ, TTL, MTU-Timeout
MTU-Table, MTU, LSN, BR
MD, MS, Router-Discovery, RSA
Static-Route, UT, AT, IE
TT, KI, KG, YD
YS, NTP, Vendor-Option, Netbios-Name-Server
WDD, Netbios-Node, Netbios-Scope, XFS
XDM, Requested-IP, Lease-Time, OO
DHCP-Message, Server-ID, Parameter-Request, MSG
MSZ, RN, RB, Vendor-Class
Client-ID
Lease-Time Option 51, length 4: 1
01:29:51.034866 52:54:00:12:35:02 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 590: (tos 0x10, ttl 64, id 1, offset 0, flags [none],
proto UDP (17), length 576)
10.0.2.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548, xid
0x514a3f0c, Flags [Broadcast]
Your-IP 10.0.2.15
Server-IP 10.0.2.4
Client-Ethernet-Address de:ad:c0:de:ca:fe
file "debian8.pxe"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 10.0.2.2
Domain-Name-Server Option 6, length 8: 192.168.1.1,192.168.1.1
Domain-Name Option 15, length 4: "home"
Lease-Time Option 51, length 4: 86400
Server-ID Option 54, length 4: 10.0.2.2
01:29:54.031972 08:00:27:b6:c1:90 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 347: (tos 0xc0, ttl 64, id 24077, offset 0, flags [none],
proto UDP (17), length 333)
192.168.1.129.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305,
xid 0x514a3f0c, Flags [Broadcast]
Your-IP 192.168.1.176
Server-IP 192.168.1.129
Client-Ethernet-Address de:ad:c0:de:ca:fe
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.1.129
Lease-Time Option 51, length 4: 120
RN Option 58, length 4: 60
RB Option 59, length 4: 105
Subnet-Mask Option 1, length 4: 255.255.255.128
BR Option 28, length 4: 192.168.1.255
Domain-Name-Server Option 6, length 4: 192.168.1.129
Domain-Name Option 15, length 11: "mydomain.io"
Default-Gateway Option 3, length 4: 192.168.1.129
What did I do wrong?
~Thanks
interface=br0
domain-needed
bogus-priv
no-resolv
local=/mydomain.io/
no-poll
no-hosts
domain=mydomain.io
dhcp-range=192.168.1.129,192.168.1.254,255.255.255.128,192.168.1.255,12h
dhcp-option=3,192.168.1.129
log-queries
log-dhcp
dhcp-authoritative
w***@gmail.com
2017-01-23 01:54:51 UTC
Permalink
Post by Sebastian Tarach
Hello,
I'm trying to make *dnsmasq* work on my Debian Virtualbox guest but I keep
getting reply from my VBox host DHCP first.
there should only ever be one DHCP server running on any net segments... turn
off or otherwise disable all the others and you should see the results you desire...

FWIW: rogue DHCP servers are the bane of sysdamins everywhere...
--
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list* unless
private contact is specifically requested and granted.
Simon Kelley
2017-01-23 11:49:39 UTC
Permalink
Actually, it's permitted to have more than once DHCP server, but the
client is entitled to wait for some time to hear from them all, and
then pick whichever one it prefers, so trying to implement server
priority by speed-of-reply is doomed to failure.


Cheers,

Simon.
Post by w***@gmail.com
Post by Sebastian Tarach
Hello,
I'm trying to make *dnsmasq* work on my Debian Virtualbox guest
but I keep getting reply from my VBox host DHCP first.
there should only ever be one DHCP server running on any net
segments... turn off or otherwise disable all the others and you
should see the results you desire...
FWIW: rogue DHCP servers are the bane of sysdamins everywhere...
w***@gmail.com
2017-01-23 17:45:28 UTC
Permalink
Actually, it's permitted to have more than once DHCP server, but the client
is entitled to wait for some time to hear from them all, and then pick
whichever one it prefers,
that's interesting... i can't say that i've ever heard that before... maybe it
has been corporate policy on all the networks i've dealt with over the years?

it is something that i may do more research on because i don't want to pass bad
information as i have apparently just done... do you have any pointers to
documentation on this aspect of DHCP servers?
so trying to implement server priority by speed-of-reply is doomed to
failure.
yup! seems to be that way :)

thanks for the clarification!
--
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list* unless
private contact is specifically requested and granted.
Kurt H Maier
2017-01-23 18:14:18 UTC
Permalink
Post by w***@gmail.com
Actually, it's permitted to have more than once DHCP server, but the client
is entitled to wait for some time to hear from them all, and then pick
whichever one it prefers,
that's interesting... i can't say that i've ever heard that before... maybe it
has been corporate policy on all the networks i've dealt with over the years?
it is something that i may do more research on because i don't want to pass bad
information as i have apparently just done... do you have any pointers to
documentation on this aspect of DHCP servers?
RFC 2131, section 3.1, "Client-server interaction - allocating a network
address", step 3:

"The client receives one or more DHCPOFFER messages from one or more
servers. The client may choose to wait for multiple responses. The
client chooses one server from which to request configuration
parameters..."


khm
Simon Kelley
2017-01-23 18:27:11 UTC
Permalink
Post by w***@gmail.com
Post by Simon Kelley
Actually, it's permitted to have more than once DHCP server, but
the client is entitled to wait for some time to hear from them
all, and then pick whichever one it prefers,
that's interesting... i can't say that i've ever heard that
before... maybe it has been corporate policy on all the networks
i've dealt with over the years?
it is something that i may do more research on because i don't want
to pass bad information as i have apparently just done... do you
have any pointers to documentation on this aspect of DHCP servers?
Post by Simon Kelley
so trying to implement server priority by speed-of-reply is
doomed to failure.
yup! seems to be that way :)
thanks for the clarification!
To be honest, I've never seen it used, except possibly in
high-availability fail-over scenarios, nevertheless it's in the spec:
see RFC-2131 para 4.4.1 Initialization and allocation of network address
.

"The client collects DHCPOFFER messages over a period of time, selects
one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
from the previously used server) and extracts the server address from
the 'server identifier' option in the DHCPOFFER message. The time
over which the client collects messages and the mechanism used to
select one DHCPOFFER are implementation dependent."



Cheers,

Simon.

Loading...