[Dnsmasq-discuss] Using multiple upstream servers but sometimes the reply from the server which answers first is null.

[Hongyi Zhao]

Hi all,

I use ``--all-servers'' combined with ``--servers-file='' to let
dnsmasq query multiple upstream  servers for me.  But I find the
following issue sometimes will happen:

When I do the dns query, say, for the domain-name,
softwareupdate.vmware.com, sometimes I will get correct result,
sometimes I will get nothing.

When I get nothing, the results is as follows when using dig to do the testing:

$ dig softwareupdate.vmware.com -p6053

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> softwareupdate.vmware.com -p6053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24708
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;softwareupdate.vmware.com.INA

;; Query time: 118 msec
;; SERVER: 127.0.0.1#6053(127.0.0.1)
;; WHEN: Tue Jan 24 10:35:00 CST 2017
;; MSG SIZE  rcvd: 43

It seems this is caused by the following reason:  when dnsmasq sending
all queries to all available servers. The reply from the server which
answers first gives nothing -- which is not an error.  And as a
result, this empty result will be returned to the original requester.
And the subsequent correct replies will simply ignored by dnsmasq.

So, how to solve this issue?

Regards
-- 
Hongsheng Zhao 
Institute of Semiconductors, Chinese Academy of Sciences
GnuPG DSA: 0xD108493

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

Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OK, that's a bit difficult to correlate the client and upstream, but I
can see in the responses coming back from upstream that the order of
the RRs in the Auth section of the "no-such name" replies is

NSEC
RRSIG (for NSEC)
SOA
RRSIG (for SOA)

That's different than for the google public DNS which returns

SOA
NSEC
RRSIG
RRSIG

Both are valid, but the first exercises code-paths the second doesn't,
since the SOA RR has to be moved when the NSEC and its RRSIG are
deleted from the packet.

The address of the upstream server in the captures is an RFC1918
address. Is there a comcast server at  a public address that I can
point to and get the same answers? That should allow me to reproduce
the bug here.

I just tried the first 5 or 6 servers in google's answer to the query
"public dns" and they all reply in the SOA-first order. Need to find a
public DNS server that replies in the NSEC-first order.

Cheers,

Simon.


On 18/01/17 20:49, Dave Taht wrote:
> The offputting part of your outline of what to check for was "some 
> hairy pointer code". :) I'm in the middle of some crash bugs 
> elsewhere, and I didn't realize how fast I could get you data
> without thinking about the "hairy" parts.
> 
> 
> dnssec and dnssec-check-unsigned are enabled, and I'm using
> cachesize  (what's the limit nowadays?)
> 
> I put packet captures of the external interface on the router
> (comcast upstream) and captures taken at the client, a log, and
> conf file, here:
> 
> http://www.taht.net/~d/dnssecbug/
> 
> Basically hammering on nslookup for the two internal and internal 
> captures there.
> 
> Hammering on "dig" later, I was unable to trigger it on A, or  
> requests. Was able to easily trigger it on a MX request.
> 
> flent-freemont does not exist, btw. Flent-fremont, does. It will
> go boom on both.
> 
> 
> 
> root@dancer:~/dnssecbug# dig flent-freemont.bufferbloat.net MX ;;
> Got bad packet: bad compression pointer 123 bytes a5 c9 81 a0 00 01
> 00 00 00 01 00 01 0e 66 6c 65  .fle 6e 74 2d 66
> 72 65 65 6d 6f 6e 74 0b 62 75 66 66  nt-freemont.buff 65 72
> 62 6c 6f 61 74 03 6e 65 74 00 00 0f 00 01
> erbloat.net. c0 1b 00 06 00 01 00 00 0e 10 00 34 06 61 72 6e
> ...4.arn 6f 6c 64 02 6e 73 0a 63 6c 6f 75 64 66 6c 61 72
> old.ns.cloudflar 65 03 63 6f 6d 00 03 64 6e 73 c0 eb 78 9d d7 47
> e.com..dns..x..G 00 00 27 10 00 00 09 60 00 09 3a 80 00 00 0e 10
> ..'`..:. 00 00 29 02 00 00 00 00 00 00 00
> ..) root@dancer:~/dnssecbug# dig
> flent-freemont.bufferbloat.net MX
> 
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> flent-freemont.bufferbloat.net MX 
> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode:
> QUERY, status: NOERROR, id: 34631 ;; flags: qr rd ra ad; QUERY: 1,
> ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;;
> QUESTION SECTION: ;flent-freemont.bufferbloat.net.INMX
> 
> ;; AUTHORITY SECTION: bufferbloat.net.3600INSOA
> arnold.ns.cloudflare.com. dns.cloudflare.com. 2023610183 1 2400
> 604800 3600
> 
> ;; Query time: 72 msec ;; SERVER: 172.26.16.1#53(172.26.16.1) ;;
> WHEN: Wed Jan 18 12:42:02 PST 2017 ;; MSG SIZE  rcvd: 123
> 
> 
> 
> On Wed, Jan 18, 2017 at 12:01 PM, Dave Taht 
> wrote:
>> On Wed, Jan 18, 2017 at 11:48 AM, Simon Kelley
>>  wrote:
> I won't have access to a MIPS system 'till the weekend.
> 
> I assume you're using the git head code?
>>> 
>>> No. Lede-project head. package claims to be dnsmasq-2.76-6.
>>> libc is musl.
>>> 
>>> Box under test was an archer c7v2. Can go try a few other mips
>>> boxes like the wndr3800, but I've seen it there too. The arm
>>> box (that is working) is an linksys-1200ac. (overall it's
>>> looking like a fine release of lede)
>>> 
> Did you manage to see a dump of the upstream reply?
>>> 
>>> Not yet. I'll touch bases with you later in the week.
>>> 
> 
> 
> Simon.
> 
> 
> 
> On 18/01/17 07:31, Dave Taht wrote:
> so far I can only make it happen on mips. Doesn't happen on
> arm. Haven't tried harder yet.
> 
>> 
>> 
>> 
>> -- Dave Täht Let's go make home routers and wifi faster! With
>> better software! http://blog.cerowrt.org
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhn5+AAoJEBXN2mrhkTWiTS8QAIwA9Ue2ovYfA/orURvb0VHg
nc4NIpV4bDdKH6IwbpdrJLh4AO/2xs1ZCYNeb+YKz0QKbK1ycOiZqcwKr0OESWEc
tMW1TFNXtdtAy3MHs9hgPJk3tnYzao8VdrsTFOiCUy2rdzexH4OOt17nJ2VC4+Hb
xYZx6/cNOXPGYghk1UeZCJuvspV1UzQkcMJ+EDI5To1s33Nk7apaXY7k8XABYOip
Aj/2F7SLyAohxPDyUR0Pc4NqNZjJhP9bGUfhotLcDWzEtXnVIpMx9OgapZ9s7e5z
q9yYtqorDsPgdAeR9KqyizahjaOcEB3BA9PXshQb0+dutVzgxbrcXhUkBTr41gnY
8dOPA85dFxTasRKAcx1cyVZxZmaSSisP02rfn7FGvq2UmC7/gPlvIS+/2xnYMFqg
wQ6fL+E0nEvT3MLENEDKh187QVYtckI2su+9J0enKZ+6w/yU0vHHocEjTBVqRFts
n3dIeTRiHfSF0v5n27t7rJaX57bioRrYXRByYP9Lz75nGbLhgg7an7VEf2rz/Kx5

Re: [Dnsmasq-discuss] tftp: provide dbus signal for downloaded files

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Yes. Seems sensible. Can I make a request that the patch includes
updates to the documentation: at least dbus/DBus-interface, and also
the man page if that's appropriate.


Cheers,

Simon.


On 20/01/17 14:29, Yegor Yefremov wrote:
> I have an application, where a bootloader downloads files from my 
> dnsmasq tftp instance. I'd like to log these operations or to react
> on them.
> 
> Format would be like for DHCP lease:
> 
> STRING "192.168.1.115" STRING "01:23:45:67:89:ab" STRING
> "filename"
> 
> Would such functionality be accepted for integration?
> 
> Yegor
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhnV4AAoJEBXN2mrhkTWiqwYP/0EkQDbm46CQqkiOX4GQGAQC
dy/1UowiMB7koeEh/Ira3FvFq9puVq5R1tVxaVwIC4aCva/+v2nf7G55mhp7hXnW
agsIBaipwXEvbig9LGI0kg+L1hppgScVP6bVzHSOL0Dj1GrH063GUjPaMeVezWY3
pnaaANmfTSk+DSH99ZVBC56NxKCvWibnf8lD5h5dkq39Wz88vH1SUaBw0mkjJFnk
xL+q0lSUskE/NN/RpId9a647pQ+xjZ2Fj4qr+aiHXOJSODw7NAZMf/oz0fWStA+k
s29VRN99+hqtL1ytoXqNH+dOwWWJOJILmKlakrQtc8cNU2AhEr+Y6rIxv4rXSHKo
J8XX6N+k8VKQWPH9qMiRPwt4p/Mh1H3MJEnheMgrt6cb1ooWM8QRqAz4zjE4UXca
kWBPx0GwBpVoWVAeYdAg0N2Y+M1E6nFB3T2BB5C4PMeJKqJvbHUcQX6cJCwQsRIf
mE5yCVuRlM2nhAmtzYB/gVbpxG00c4jvPfDiQGGPwwoE2LYT3y6BAZIDK/fH+3IW
MMQ3sacSU0/fMct2UeSzEU3PMr/MWqx7zH1zdy/XZk1S2gC7bYqSwL9t3wY6fEdI
h8hflV3l48WtEXzYcnf4FjSUz3OT7unLRd74F/nGk8xTp6g2Ju22LVFkyaNASn5D
/LPt5q2wFdeABruMPgjq
=cq8Z
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] About UEFI PXE booting in proxy mode

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thanks for the reply. Please could you repeat the tcpdump using the
command

tcpdump -s 0 -w capturefile

and send me the resulting file? That has far more information than
tcpdump prints.


Cheers,

Simon.

On 20/01/17 08:39, Steven Shiau wrote:
> Hi Simon,
> 
> Thanks for your reply. I am answering you in the following.
> 
> On 2017/01/20 06:47, Simon Kelley wrote:
>> Your example 3 - I'm confused why that shouldn't work - the PXE
>> client seems to be making further requests which are bring
>> ignored. Would it be possible for you to get a packet dump of
>> that exchange using tcpdump?
> $ sudo tcpdump -ni ens38 'udp port 67 and udp port 68' tcpdump:
> verbose output suppressed, use -v or -vv for full protocol decode 
> listening on ens38, link-type EN10MB (Ethernet), capture size
> 262144 bytes 16:18:33.208355 IP 0.0.0.0.68 > 255.255.255.255.67:
> BOOTP/DHCP, Request from 00:0c:29:1d:9a:d1, length 347 
> 16:18:36.205647 IP 192.168.22.254.67 > 255.255.255.255.68:
> BOOTP/DHCP, Reply, length 341 16:18:36.385548 IP 0.0.0.0.68 >
> 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:1d:9a:d1,
> length 359 16:18:36.386212 IP 192.168.22.254.67 >
> 255.255.255.255.68: BOOTP/DHCP, Reply, length 341 ^C 4 packets
> captured 4 packets received by filter 0 packets dropped by kernel
> 
>> 
>> Example 4 looks quite hopeful - the client is succerssfully 
>> downloading the bootx64.efi file (ignore the error before, that's
>> just testing for the existance of the file.
>> 
>> Can you see what's displayed on the client system at this point?
> It's blank screen due to the background_image for grub is not 
> downloaded,  and in the end the grub shows no grub.cfg error, as 
> attached. That format is from the grub prefix we added by: 
> === set
> prefix=(tftp)/grub-efi.cfg echo "Grub CPU and platform: \$grub_cpu,
> \$grub_platform" echo 'Network status: ' net_ls_cards net_ls_addr 
> net_ls_routes
> 
> tr --set pretty_mac x: x- \$net_default_mac
> 
> echo "Loading config file \$prefix/grub.cfg-01-\$pretty_mac..." 
> configfile \$prefix/grub.cfg-01-\$pretty_mac
> 
> echo "Loading config file \$prefix/grub.cfg-\$net_default_ip..." 
> configfile \$prefix/grub.cfg-\$net_default_ip
> 
> echo "Loading config file: \$prefix/grub.cfg" configfile
> \$prefix/grub.cfg
> 
> echo "Could not find config file \$prefix/grub.cfg-\$pretty_mac, 
> \$prefix/grub.cfg-\$net_default_ip or \$prefix/grub.cfg!" sleep 15 
> === This is exactly the same
> problem as mentioned here: 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q4/010931
.html
>
> 
i.e., only grub efi is downloaded, while the rest of required files are
> not downloaded. As I mentioned for comparison, for non-proxy mode
> with same configuration, it works well.
> 
> Thanks again.
> 
> Steven
> 
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhnTjAAoJEBXN2mrhkTWiHX8QAJhjmt1VYRoJ3DuaA6f3s9o+
Tpoie2+4VgFHf3q/wQjq+miQ+da75+0sii9UAdjBtAAHDgLdyzPJSxCHU3neKYYF
dY8ww789lJlUAyvmvKm7Pnv3psMWhy22WLxeJGFXPIz+DjpH+tatZ507ZTQ7946o
nbTPdnfOO5ADF/Spuors6ioB+cmyZD9cPASSvMUQm7EwunBpAORB2S11ZRbeqSb/
84EdzTTtWomq7oP4NtSV98SDo0sTH2MYQtF1ht4INlutQs/zOP6P7NuzdFFJLcb8
Bieq1FYWxK6x4FcTqNdw9SJJon/jRjoxhF3Lvovkwb/00RuQuJRHqHpw+laY6yNA
MGS5LOIps/fIP42gxs7zftgqvfXVMfBLPUDRS3G+IwOZeteKvzNGwV0LrGFGKcZZ
iRDRAIhWH8RImb6gSpt1YXNxyR6Or1m0IuqR+jvYPOjtmXBjRYupZ89B0FKHR9jv
r2tJKSVq/uJa4ScW5R8ezGxaQB8iVFFj6CKDWeWEKxb4NxJUYrJ8RVb1IhAxZJUg
6EqXAZ/tvsIDRlveXk1nMqJ12pJlA68mnLzQ4Z5yarGTsoi6zlLecyhQkThp/LxP
E4lGqyuJEamggwyLd0WUYH7TMqXimCd9Nyv36rurfDZOVbT3G/JaS980SkTbsjZ2
c6JPXEqLshQyjdbht/1b
=msps
-END PGP SIGNATURE-

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

[Dnsmasq-discuss] Bluetooth networking issue

[Aaron Brice]

I am testing a bluetooth networking (bnep0) device on an Ubuntu 16.04 
laptop.  Everything works fine if I comment out dns=dnsmasq from the 
NetworkManager.conf.  With dnsmasq on, everything works fine the first 
time I connect my bluetooth network device.  When I disconnect it and 
reconnect it, DNS lookups fail immediately with a REFUSED status.  When 
I restart the NetworkManager service everything works again.


I turned on log-queries, and it shows the query is received, but no 
response is shown in the logs and also no error messages.  The logs show 
that on the reconnect the DHCP succeeded, and dnsmasq received the 
upstream nameservers from the DHCP response, but tcpdump does not show 
any DNS traffic to those nameservers when I use dig.  Is there a 
verbosity setting that might show some more information on why the DNS 
queries are being refused?


Logs:

Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: setting upstream servers 
from DBus
Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: using nameserver 
192.168.10.2#53(via bnep0)
Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: using nameserver 
68.105.29.16#53(via bnep0)
Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: using nameserver 
68.105.28.16#53(via bnep0)
Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: query[A] daisy.ubuntu.com 
from 127.0.0.1
Jan 18 16:56:02 datasoft-travel whoopsie[883]: [16:56:02] Cannot reach: 
https://daisy.ubuntu.com
Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: query[SOA] local from 
127.0.0.1
Jan 18 16:56:02 datasoft-travel NetworkManager[7926]:  
[1484783762.2180] device (5C:31:3E:EC:71:B3): Activation: successful, 
device activated.
Jan 18 16:56:02 datasoft-travel nm-dispatcher: req:2 'up' [bnep0]: new 
request (1 scripts)
Jan 18 16:56:02 datasoft-travel nm-dispatcher: req:2 'up' [bnep0]: start 
running ordered scripts...
Jan 18 16:56:02 datasoft-travel whoopsie[883]: [16:56:02] The default 
IPv4 route is: /org/freedesktop/NetworkManager/ActiveConnection/2
Jan 18 16:56:02 datasoft-travel deja-dup-monito[3334]: Source ID 948 was 
not found when attempting to remove it
Jan 18 16:56:02 datasoft-travel whoopsie[883]: [16:56:02] Network 
connection may be a paid data plan: 
/org/freedesktop/NetworkManager/Devices/3
Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: query[A] daisy.ubuntu.com 
from 127.0.0.1
Jan 18 16:56:02 datasoft-travel whoopsie[883]: [16:56:02] Cannot reach: 
https://daisy.ubuntu.com
Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: query[SOA] local from 
127.0.0.1

Jan 18 16:56:02 datasoft-travel systemd[1]: Reloading.
Jan 18 16:56:02 datasoft-travel systemd[1]: snapd.refresh.timer: Adding 
4h 43min 19.514615s random time.
Jan 18 16:56:02 datasoft-travel systemd[1]: apt-daily.timer: Adding 2h 
3min 35.943181s random time.
Jan 18 16:56:02 datasoft-travel dnsmasq[7973]: query[SOA] local from 
127.0.0.1

Jan 18 16:56:02 datasoft-travel systemd[1]: Reloading.
Jan 18 16:56:02 datasoft-travel systemd[1]: snapd.refresh.timer: Adding 
1h 9min 9.603579s random time.
Jan 18 16:56:02 datasoft-travel systemd[1]: apt-daily.timer: Adding 6h 
19min 48.788489s random time.
Jan 18 16:56:03 datasoft-travel dnsmasq[7973]: query[A] 
fsodqcsvqrxnlyy.corp.datasoft.com from 127.0.0.1
Jan 18 16:56:03 datasoft-travel dnsmasq[7973]: query[A] 
xasqjyv.corp.datasoft.com from 127.0.0.1
Jan 18 16:56:03 datasoft-travel dnsmasq[7973]: query[A] 
ftmkaipfpi.corp.datasoft.com from 127.0.0.1
Jan 18 16:56:03 datasoft-travel dnsmasq[7973]: query[A] daisy.ubuntu.com 
from 127.0.0.1
Jan 18 16:56:03 datasoft-travel whoopsie[883]: [16:56:03] Cannot reach: 
https://daisy.ubuntu.com
Jan 18 16:56:03 datasoft-travel avahi-daemon[903]: Joining mDNS 
multicast group on interface bnep0.IPv6 with address 
fe80::cf57:5122:c1f0:43cd.
Jan 18 16:56:03 datasoft-travel avahi-daemon[903]: New relevant 
interface bnep0.IPv6 for mDNS.
Jan 18 16:56:03 datasoft-travel avahi-daemon[903]: Registering new 
address record for fe80::cf57:5122:c1f0:43cd on bnep0.*.
Jan 18 16:56:03 datasoft-travel dnsmasq[7973]: query[A] daisy.ubuntu.com 
from 127.0.0.1
Jan 18 16:56:03 datasoft-travel whoopsie[883]: [16:56:03] Cannot reach: 
https://daisy.ubuntu.com
Jan 18 16:56:03 datasoft-travel NetworkManager[7926]:  
[1484783763.4104] policy: set 'SIDEBRIDGE_002020 Network' (bnep0) as 
default for IPv6 routing and DNS
Jan 18 16:56:03 datasoft-travel dnsmasq[7973]: query[A] daisy.ubuntu.com 
from 127.0.0.1
Jan 18 16:56:03 datasoft-travel whoopsie[883]: [16:56:03] Cannot reach: 
https://daisy.ubuntu.com
Jan 18 16:56:04 datasoft-travel dnsmasq[7973]: query[A] 
hmtddsov.corp.datasoft.com from 127.0.0.1
Jan 18 16:56:04 datasoft-travel dnsmasq[7973]: query[A] 
bigsooxchvptr.corp.datasoft.com from 127.0.0.1
Jan 18 16:56:04 datasoft-travel dnsmasq[7973]: query[A] 
ecbamrdeizxzc.corp.datasoft.com from 127.0.0.1
Jan 18 16:56:04 datasoft-travel dnsmasq[7973]: query[A] daisy.ubuntu.com 
from 127.0.0.1
Jan 18 16:56:04 datasoft-travel whoopsie[883]: [16:56:04] Cannot reach: 
https://daisy.ubuntu.com
Jan 

Re: [Dnsmasq-discuss] Making dnsmasq make OFFER faster than virtualbox NAT DHCP

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 23/01/17 17:45, wkitt...@gmail.com wrote:
> On 01/23/2017 06:49 AM, Simon Kelley wrote:
>> 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!
> 

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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhkr+AAoJEBXN2mrhkTWiIuEP+wYazoN9/6AleAFaAnEljxPI
kAf9dklY+Xc2CG4gK5Y6+2k1Y5yhveLJ4OWN3DEzvGx9djjHvIdowvuUM2X16DJo
de0qxTQEJPKU2KGSdhohAYqhJsSr0HwTyNBFxYQuKABePlEHoX0/8+EJ2LUAWPmh
k7PdnTfHbjWAtBZ7xqXYjfJKDklCZm+9WowsRY8PGaT008oxt9j9WWLTbtoy4fpn
f+Yd8IUqjfLqvlNC5TmjX+MKi3OiKncIZd0/PzPkr26dHvFb6wlNvrxBSz5m46oE
UMcqZvV5QmiaMV7YUVRk9S42/Sep5N4/s1hNwOM08DkeMLH/+k1t14FjtI3/I2CE
9cEDxpOuTHsmst9aUWzRRR9Bzr9rMJttWtBLXAoRViVtLc5LkYEu6P7EdTXSeOi3
2X8GVnP9XZ26m70maAH4yEdQkQsLgeJmpcsrIfsWkvWBJNNDrSEYyVkqkeyAPQC1
/XRoNEbqW62iZDRTtcE8hFAZI6QL2fRtVMdBpQEP8ebeGrEPmCFUfwG7S7aHq16V
Q0sJYD1gtjT4KmFWkIlhgEAishfxnYvLselA2rxsM0KDLp6ADC/78RZIaEYWBgKq
4X7ggiKoua8FSTmf0pc04iUrtLDiecF0Hrfj/zB1fwmnnr0y+FeZVih9Ln4/SqjF
DeJLms4zLkE0XIGV369y
=vs1A
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Making dnsmasq make OFFER faster than virtualbox NAT DHCP

[Kurt H Maier]

On Mon, Jan 23, 2017 at 12:45:28PM -0500, wkitt...@gmail.com wrote:
> On 01/23/2017 06:49 AM, Simon Kelley wrote:
> > 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


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

Re: [Dnsmasq-discuss] Making dnsmasq make OFFER faster than virtualbox NAT DHCP

[wkitty42]

On 01/23/2017 06:49 AM, Simon Kelley wrote:

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.

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

Re: [Dnsmasq-discuss] dnsmasq always answer dhcp NAK

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

If I've understood the problem correctly, dnsmasq is never even seeing
these packets. If the destination address in the IP-level header is
for a random IP address then the kernel network stack will discard the
packet, even if the link-layer MAC address is correct so that the
packet arrives at the network hardware.

Since dnsmasq is listening at the IP level, and doesn't do raw packet
capture, it won't ever see the packets. Note that other DHCP servers
are available (such as ISC dhcpd) which do work at raw packet level.
I'm not sure if dhcpd would behave as you wish in this case, but it
would certainly be simpler to modify it to do so. Unless dnsmasq is
completely re-written to do raw packet capture (which it won't be)
there is not way to modify it to do what you want.


Cheers,

Simon.



On 21/01/17 07:37, Nikita N. wrote:
> Hi, I confirm --dhcp-authoritative works *PERFECTLY* with all other
> clients. Meaning it works when client matches the IP layer address,
> and when Dst: Broadcast (ff:ff:ff:ff:ff:ff) and Src: 0.0.0.0
> (0.0.0.0) and Dst: 255.255.255.255 (255.255.255.255). Unfortunately
> my bugged client has IP Src bugged, and IP Dst gateway bugged. No
> matter that, I see those DHCP request frames in the server network 
> where I run dnsmasq (because my net conf is so), so also dnsmasq
> sees them. I believe the option I'm looking for is smtng like: if a
> UDP frame with Dst Port: 67 comes from Src: macX, and is *NOT*
> protocol/standard valid, then dnsmasq sends a DHCP NAK with Dst:
> macX (e.g. similar to the different cases when dnsmasq sends NAK
> with option Message wrong network, whatever) Is that possible? 
> Thanks
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhfNUAAoJEBXN2mrhkTWik3kP/jeqWsbPY0TCXvgpSORy3aPG
WjU99BQsDth+EJDFrDwNlhqlq8iLrMRGHnyK8BCLcu9d7kqHuqPJrECIdzs8pyVx
J7qoux6lJI/hqWrQihFLaZbxPl4XkAxPBw+zZDecjBA5m4JzSfX4Zutq9jgjiVAJ
EMgPFgc/RZbm7eiid2Mrd5FhOei7aH//S99p7EQjSk+X6eNiHdpnvXfaNQjeQRQ/
2JSMcI3hkjc3GJgcD7a/NIfLYpMFeW48RZ7eUyFYm3FAx1PbBKf1OaqeO0eCjZ4u
C2CwjWRX+qefdQtQ/GzyYtHWCUX5sIrNCwKO6+zwhn74Yjm48TKV7IKtK/ypGCGH
2eqsYo32W1fa5e4QaG7IzcmV0uew20MgcKWjjKYBxr3K8edp4t55c4bS1gwLS1ou
9b5KK6s6uUvM0IcMxP6y71JPlvkndDwRjRqaeFdxD+Lr6HL5Faxw20eBOv/C9PNe
nzfJVZQ2+ReEHMThKakmXrEICbv3yNY2axnTg7an4fuheLDVNY5+9SENUb+PAOwt
o/ACsW2ue/2ufgGJjmoW5mU+3/e/TlKi1v8MqUcxeCoC7JeeD/qk5oySDgNXaZZp
X5FZWj/Nb+7qBSJtoWre8v9J3g70oKNTFyQ5x6m/9B5h5lBCK5skkpS3LXWr6IJ8
/89setpR61Nh7zD+bA0v
=qGI/
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] will there be a 2.77 release anytime soon?

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

T'would probably be a good idea, just for accumulated bug-fixes. Would
be nice to nail the DNSSEC compression pointers bug first though.


Cheers,

Simon.



On 22/01/17 16:41, Dave Taht wrote:
> just checkin
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhe07AAoJEBXN2mrhkTWiCEMP/ifLtkSJDJgTSGUgcds2t/m5
Dp75uxr+D+03qGGzGrCr5k9PPJ61C6ZuPnhgLUISmaJIzxHGZf/3gyGhCBbtTiCX
b5e7d+1RzGVrCzQu8WXTWaCzvcO2xdS3a5TjCQd7SG+DiXJBzF2xE5h1mABTGylI
WcgWqDXUlZrNVXG2AHoZWJQtUraYwROtK9ZkoTErCCnkFvtP5ea3FS+CMMM1ZXFu
AD85DQqpg5ByrWvt8TpX0NxWVxAHP2ML3nmtNXybMGp0Op5UGzoRKnNDyHrPp7Ep
vCGGSuyV3+o7JeAcNAr5pvVU6zxWVhXT87wFgQG1Djg6yWQ2oLTbxDhL9Iv5cXug
gkuFocmxI5r05LUrwtLA/mAXVX81BQHoM2iG/rHPXeRLjkzcENnKT5mnTWsHaqyk
KUQcTlbPHqIUNv76VaEMl3BNyYCQNEilvWddrlSJ6mjkw3Z720Q8LRr/foHyamPm
Kl0RGw03Emw0SxACSGtGPmpdnKFDzv13zSp3StXAyPmIBnbVwf/sphjQA2YXKHWE
90XzTJ9mfbOGIk5EYSaivZ/aqJFNWtGw5DpUnu//F/CnxGIYbZUTvRO3vcRErUHq
lOKmyy3hI8/bokfYydX6918oqn8yVwBmDPiSY9g834nfJoJrtuaGiw+QLJ44phrQ
4tXLVVtZMIorrlzbHTD9
=pkRV
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Making dnsmasq make OFFER faster than virtualbox NAT DHCP

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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.


On 23/01/17 01:54, wkitt...@gmail.com wrote:
> On 01/22/2017 08:02 PM, Sebastian Tarach wrote:
>> 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...
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhe3SAAoJEBXN2mrhkTWiKykP/A4vpT9i4v6KDScSrFdux7Ym
0EtCFXXj3A9WYVuW3dnrg+IWvCb/XK4fPoB0Y5MoiLnfeiLhpcV5YcOUc5eSy+sn
MUry54inMu6qjtUATBUXTHSIMha132WDbvuEMad+D5mCgvuJSDJ0qGDrD3DHaoOC
nsAVxoVJKSfEjdcCIKUvgkVnrRX8rm6BfWfUIHiT9MoihVv/wyI7mitiStnCP32y
q3TcOaOgFgdqiaWGhBckPm2HUefGf8dlwlM9VDNhccYozAIH4XDp/KRiaRVIVfIk
/qh5ckYlZ9vXXmx+HRHb7AtQV9ZXlVOozJYRrnpe8OHZlXg2SkFL3y3HL+xEMNH/
1x15Rr2PLWFIqQmVcehFimUt14zWhnF9Wg/F1jRH+75r3Os/ewwO1Y/frOSMb2V5
1aiA6NsKAUwZ5yc878AYeHEGpLs5GnNWfhNeoTXcel59imJWIX8NMkotJIx8RyoX
Xm2JLPsKHMU8QTmmNNGplyMJ3kHhoCgBygFPOHnbYfG8TyxV4zqDLueIp6ZBoz3H
FyiOh/DUp5wSE+wpUDNtN0PGKyYuX5WPtuQooJHRB+ReDCpaOyJGFUhJigwciJCu
ngO/UlizUAz3q+zDaZTBD9H2X5zJnwLzwqezB6c3verLVBEoZX28BAilLCGLYVp5
MYYVgKaCr6Ibpv3GEXdQ
=pZLP
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Is there a way to disable file/directory polling for specific addn-hosts files or conf-dir changes?

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dnsmasq won't re-read /etc/hosts or files in a directory specified by
- --addn-hosts automatically. It _will_ re-read files in a directory
specified by --hostsdir. Armed with that information, the first thing
to do might be to look at exactly what configuration you're using.

Once that's sorted out, I'd be interested to know why dnsmasq is
behaving so badly in that case. Are these files very big?


Cheers,

Simon.


On 22/01/17 13:06, TheWerthFam wrote:
> The openwrt platform I'm using seems to support the ionotify
> feature( I believe that many openwrt platforms don't).  The
> application I'm working on updates files in the addn-hosts and
> conf-dir daily.  When this happens the dnsmasq process identifies
> that files have changed and automatically tries to reload/reread
> them(I understand because of the dnsmasq option polling).  For some
> reason dnsmasq doesn't seem to reload/reread them well/properly.
> The reload process takes 5 minutes at very high cpu load on a
> reload/reread.  Where if dnsmasq where just restarted it startups
> with in 10 seconds, while also loading the entries in the
> addn-hosts and conf-dir locations.
> 
> Question is: Is there a way to either turn off polling for just
> these specific addn-hosts and conf-dir locations while keeping the
> polling active to allow dnsmasq to watch /etc/hosts and
> /etc/resolv.conf as normal? Or to force a restart on file change vs
> a reload/reread as it does now?
> 
> Thanks Derek
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYhezDAAoJEBXN2mrhkTWil6MP/011OJdvw/0ios0hHTooKCuY
rbNuPydkKtT+Jzi2P1BMN/FrpLUtxTEKjWw+KKtNbVaBl7M7EjceECjE4Zk28HgV
pyCXQjQeqGzj2jlUjcv0IUSxQtG7fdWn1pSuiyKuuOUpCc2UTIanuWUe1ibMyC8F
X9YpS6ewF7mTxmStPIydcEbyLHhGLHQ/WklLIt4y0iir5Nzu6MEVgFBjvdOJbJA/
UCOHY5P9pJSoj2LAg4YOtkN0rI6Cqp53pl2mquaQsdl1K+v3EDk2r/+HuzuY5NIz
lyaUHj/kG9fAIJ5LvwMkxvYA2BqcrBOkf4C+zJdTFBd1QGNc9nEUHwXviaz6owuW
13Kv3EHvgTUj1eu+35XwuxwE1E8OCRmou9Ilz22ioY8VjIfpRsZyUKgScsFuAHfa
RzE5oJWa9+x2R2JRfW73OuEb6vNM5w4kdAMlaiMChmICtD/ND4sYzvq6PcDv+AwG
+lubWqmtdJF0tDlquqSjYup8ZPdsqzduAv6cO0Nnos2KKqYk0ilsZSlQObXeZG0P
6qiSIz0+JJUqjthCH1zHY2jERgDBVESe5TqvuElyFpjw4pf/nqXIfiKHlJv6H6Zs
19E1dV/j04Fo0BewyMmxAJWzx+qPs44TqxTPFU983PX2UCA9qibHnKuB5Jrrk/aM
3Vk1P+l2gSwcbACAUO7O
=s6QL
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Bug forward upstream SERVFAIL

[Martin Wetterwald]

Hi,
I agree with khm that it's not because A software does something that
it's right and that B should also do it.

I do think however like Dave (independently of what BIND does) that the
aim of having several upstreams is to provide robustness. The upstreams
in our case are the customer's ISP DNS (we use several ISP at the same
time).  We cannot control those DNS. If one of them is misconfigured and
has a internal failure, it will return SERVFAIL. This should not affect
dnsmasq's robustness. The end DNS client wants to get an answer. If he
gets a SERVFAIL answer, it's terrible, usually it means no Internet at
all.
Our case is not DNSSEC related. DNSSEC is disabled, but upstream can
still return SERVFAIL.

We've already patched our dnsmasq internally and it's already in
production. We are happy with this behaviour. Our clients only need to
have at least one ISP DNS which is working, and dnsmasq will make sure
he gets an answer.
Of course if all upstreams return SERVFAIL, dnsmasq will forward
SERVFAIL.

I just wanted to share it here to help in case dnsmasq maintainers also
think it's a good behaviour. :)


Martin

On 22/01/17 22:57, Kurt H Maier wrote:
> On Sun, Jan 22, 2017 at 07:31:35PM -0800, Dave Taht wrote:
> > From a brief conversation with the bind9 maintainer:
> 
> BIND is far from being a normative DNS reference, and I certainly do
> not believe that "BIND does it" is a good reason for anything.  Quite
> the contrary.
> 
> However, this discussion has been happening for a while now; last thing
> Simon Kelley said about it was that SERVFAIL in a DNSSEC context meant
> that the upstream server cannot validate the record's chain of trust --
> meaning that this particular SERVFAIL is not recoverable.  In that case
> you don't want to waste time spamming other resolvers just to get the
> same failure.
> 
> Where are you getting SERVFAIL in this case?  Is it a DNSSEC failure?
> 
> khm
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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