Re: [Dnsmasq-discuss] ubus problem

2019-04-10 Thread Simon Kelley



On 10/04/2019 17:55, Jan Willem Janssen wrote:
> On Mon, 2019-04-08 at 20:41 +0100, Simon Kelley wrote:
>>> I've to give it some thought about how we could support multiple Dnsmasq 
>>> instances in
>>> combination with UBus. Not sure how the DBus implementation would handle 
>>> this...
>>
>> It doesn't: the path is a compile-time parameter.
>>
>> It's not clear that the entities on the other end of the UBus under
>> openwrt could cope with multiple instances. The pragmatic solution might
>> be to turn Ubus off for one of them.
> 
> There's one solution I can think of: making the name under which we register 
> the UBus
> object configurable (with "dnsmasq" as default for backwards compatibility). 
> It would
> allow multiple instances to be configured each with their own unique name.
> 
> We could extend the existing `enable-ubus` flag to allow this name to be 
> supplied from the
> command line/configuration file. 
> 
> @Simon Kelley: WDYT?
> 
> 


See my answer above: Ubus == openWRT and friends. If the infrastructure
in openWRT can talk to multiple dnsmasq instances at different ubus
names, or it's a sensible ambition for it to do so in the future, then
it's good to support it.

If Harmut's config is unique, and works without openWRT talking to both
dnsmasq instances, then the solution may be just to turn off ubus on one
of the dnsmasq instances.

Simon.

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


Re: [Dnsmasq-discuss] ubus problem

2019-04-08 Thread Simon Kelley



> 
> I've to give it some thought about how we could support multiple Dnsmasq 
> instances in
> combination with UBus. Not sure how the DBus implementation would handle 
> this...

It doesn't: the path is a compile-time parameter.

It's not clear that the entities on the other end of the UBus under
openwrt could cope with multiple instances. The pragmatic solution might
be to turn Ubus off for one of them.



Simon.


> 
> Regards,
> 
>   Jan Willem
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] ubus problem

2019-04-08 Thread Simon Kelley
@Jan?

(I suspect that nothing has changed, except that a previously silent
error is now no longer silent, but it would be nice to confirm this, and
maybe explicitly consider this case.)

Simon



On 08/04/2019 15:24, e9hack wrote:
> Hi,
> 
> I'm using the latest dnsmasq version with openwrt. There are two instances 
> running. One provides dhcpv4, dhcpv6 and dns
> to several networks, the other one dhcpv4 to one network only. It looks like, 
> that the second instance has a problem
> with ubus:
> 
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: Connected to system UBus
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: started, version 
> 2.80-52-ga2b8220 cachesize 300
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: compile time options: 
> IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN
> DHCP DHCPv6 no-Lua no-TFTP no-conntrack no-ipset auth DNSSEC no-ID 
> loop-detect inotify dumpfile
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: UBus support enabled: 
> connected to system bus
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: DNSSEC validation enabled
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: DNSSEC signature 
> timestamps not checked until receipt of SIGINT
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: configured with trust 
> anchor for  keytag 20326
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: configured with trust 
> anchor for  keytag 19036
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using only locally-known 
> addresses for domain test
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using only locally-known 
> addresses for domain onion
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using only locally-known 
> addresses for domain localhost
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using only locally-known 
> addresses for domain local
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using only locally-known 
> addresses for domain invalid
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using only locally-known 
> addresses for domain bind
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using nameserver 
> 2a02:::::::#53
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using nameserver 
> 46.zzz.zzz.zzz#53
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using nameserver 
> 2a03:::::::#53
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using nameserver 
> 146.zzz.zzz.zzz#53
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: using only locally-known 
> addresses for domain lan
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: read /etc/hosts - 4 
> addresses
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1808]: read /tmp/hosts/dhcp.main 
> - 29 addresses
> Sun Apr  7 18:37:34 2019 daemon.err dnsmasq[1809]: Cannot add object to UBus: 
> Invalid argument
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1809]: started, version 
> 2.80-52-ga2b8220 DNS disabled
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1809]: compile time options: 
> IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN
> DHCP DHCPv6 no-Lua no-TFTP no-conntrack no-ipset auth DNSSEC no-ID 
> loop-detect inotify dumpfile
> Sun Apr  7 18:37:34 2019 daemon.info dnsmasq[1809]: UBus support enabled: bus 
> connection pending
> 
>>From the first I see:
> daemon.info dnsmasq[1808]: Connected to system UBus
> daemon.info dnsmasq[1808]: UBus support enabled: connected to system bus
> 
>>From the second I see:
> daemon.err dnsmasq[1809]: Cannot add object to UBus: Invalid argument
> daemon.info dnsmasq[1809]: UBus support enabled: bus connection pending
> 
> Sometimes, the starting sequence is inverted. The error occurs all the time 
> on the seconded started instance only.
> 
> This occurs since this commit:
> 
> commita2b8220f4e82e454bbc0013ee83ea3220111d92e
> Improved UBus supported
> 
> Regards,
> Hartmut
> 
> ___
> 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


Re: [Dnsmasq-discuss] misunderstanding negative caching

2019-04-04 Thread Simon Kelley
an ICMP no route to host or similar should cause option b)


Simon.


On 04/04/2019 22:25, Alex Litvak wrote:
> Thank you for your reply Simon.  If DNS service is down and dnsmasq
> receive immediate icmp reject will this be  a) cached, b) handled as
> immediate error with next name server tried immediately, or c) just a
> timeout within system defined time out?
> 
> We are looking to avoid a delay with failing / overloaded DNS servers,
> whence asking all those weird questions.
> 
> Thanks again,
> 
> On 4/4/2019 10:39 AM, Simon Kelley wrote:
>> On 27/03/2019 00:32, alexander.v.lit...@gmail.com wrote:
>>> Dear list,
>>>
>>> I configured dnsmasq with enabled negative cache and neg-ttl 600.  I
>>> attempted to use it with a query that times out (configured fake dns
>>> servers
>>> in the config file).  When I ping a host, I have NXDOMAIN in logs. 
>>> However,
>>> every time I ping it dnsmasq asks those servers to resolve the host.
>>> Shouldn't I get rejection immediately based on dnsmasq negative cache?
>>>
>>> Thank you in advance,
>>>
>>>
>>>
>>
>> A time-out will not be cached, which is generally sensible, I think.
>>
>> Simon.
>>
>> ___
>> 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


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


Re: [Dnsmasq-discuss] Netboot drops DNSMasq DHCP offer

2019-04-04 Thread Simon Kelley
Sorry, I wasn't clear.

A DHCP client can set a bit in the DHCP DISCOVER message that asks the
DHCP server to broadcast the reply to it. The packet captures you posted
showed exactly that. It's quite possible that the ThinkPad X260,
_doesn't_ do this, so the reply is not broadcast.

A source of problems in the past has been firewall (iptables) rules that
block packets sent to the 255.255.255.255 broadcast address. Such a rule
on the machine running dnsmasq would  break DHCP but only for clients
which set the broadcast bit in the DHCPDISCOVER. I don't know if the
packet capture happens before or after iptables, for the packet to be
blocked, but still appear (as it did) in the packet capture, it would
have to be before iptables.


Cheers,

Simon.

On 04/04/2019 18:42, Conrad Kostecki wrote:
> Hi Simon,
> 
> Am 04.04.2019 16:10:32, "Simon Kelley"  schrieb:
> 
>> How are you producing the dnsmasq captures? on the host running dnsmasq,
>> or elsewhere on the network?
> 
> Both captures were produced on that machine, which runs the DHCP server.
> This means, on the non working setup, this is my linux router.
> The fritzbox also does offer a capture on its interfaces itself.
> 
> Captures where done with tcpdump on port 67+68.
> 
>> The DHCP is asking for, and getting, broadcast replies (ie to
>> 255.255.255.255) It's just possible that : 1) no other DHCP clients
>> you've used ask for this
> What do you mean by this? Sorry, but I didn't understand this.
> 
>>  2) the firewall configuration on the host
>> running dnsmasq blocks packets with destination 255.255.255.255.
> I can rule this out. If I take the same network cable, which I used for
> Netboot, but instead, connect my modern ThinkPad X260, DHCP works just
> perfectly fine.
> I did also give now a try and connected directly the Netboot machine to
> an interface directly on the machine, which hosts DNSMasq.
> So I think, I can rule out at least the hardware side here.
> 
> Conrad
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] misunderstanding negative caching

2019-04-04 Thread Simon Kelley
On 27/03/2019 00:32, alexander.v.lit...@gmail.com wrote:
> Dear list, 
> 
> I configured dnsmasq with enabled negative cache and neg-ttl 600.  I
> attempted to use it with a query that times out (configured fake dns servers
> in the config file).  When I ping a host, I have NXDOMAIN in logs.  However,
> every time I ping it dnsmasq asks those servers to resolve the host. 
> Shouldn't I get rejection immediately based on dnsmasq negative cache? 
> 
> Thank you in advance,
> 
> 
>

A time-out will not be cached, which is generally sensible, I think.

Simon.

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


Re: [Dnsmasq-discuss] Odd caching behaviour...

2019-04-04 Thread Simon Kelley
On 30/03/2019 08:41, John Robson wrote:
> Simon,
> 
> The upstream server is authoritative for the initial domain (being
> inside an organisation I don’t think that’s unusual) and the incomplete
> (but perfectly valid, I agree) response is taken as complete. The
> upstream server does do recursion as well, but when that failed it just
> returned what it could (seems reasonable enough).
> 
> I’d have thought that the lack of an actual resolved A record (which is
> what was asked for) would mark the cache entry as incomplete at best.
> This is pure gut, not a technically based statement.

A CNAME reply with no record for the target of the CNAME, from a
recursive server, establishes that the target doesn't exist. If it were
otherwise, there would be large numbers of legitimate answers which are
uncachable. Consider that there are many record types and the target of
a CNAME will not exist for most record types.

As a common example, an IPv6 enabled host will query for the  record
of something it wants to talk to. If hostname is a CNAME, and the thing
it want's to talk to doesn't have an  record, then the reply will be
a CNAME with no target. You really want to be able to cache that.


> 
> And whilst I agree that the record was cached (and that that is probably
> technically correct) I can’t then explain why dnsmasq stopped using the
> cache when I restarted my program - with 45+ minutes of cache left,
> dnsmasq went back to the upstream server and got a complete answer.
> 
> Restarting dnsmasq obviously reset the cache, and everything recovered
> when I did that - but restarting other software shouldn’t have magically
> reset the cache, and yet it did.


I can't explain that. If it's reproducible, run dnsmasq with
--log-queries set and see exactly what's going on.


> 
> (Un)Fortunately the second/third nameservers seem to be being better
> behaved at the moment, so we haven’t seen the incomplete response in
> several days - kind of makes it harder to test though.

Not reproducible, then. That's a pity.


Cheers,

Simon.

> 
> Cheers,
> 
> John
> 
> 
> 
> On Fri, 29 Mar 2019 at 22:43, Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> On 21/03/2019 11:01, John Robson wrote:
> > OK,
> >
> > Maybe this does reveal something about the caching...
> > Which might be expected behaviour, but I am not convinced it's
> useful...
> >
> > Overnight monitoring has shown that the upstream server does
> > occasionally send back an incomplete (but perfectly valid) CNAME only
> > response.  Mostly I can justify the caching behaviour based on the
> TTLs
> > of the second CNAME or A record (the server is authoritative for the
> > first CNAME, so that's always at 3600).
> >
> > As a slight aside:
> > dnsmasq sends a query at 22:57:32.599, then again (new transaction id)
> > at 22:57:33.601, and at 22:57:36.601.
> > This last query gets a response in 0.1 seconds, both the others
> > eventually come in (incomplete) at 22:57:44.073
> > I am assuming that dnsmasq ignored these late arrivals (either due
> to a
> > default timeout, or just because a better answer has been received -
> > this would be comparable with behaviour when it queries multiple
> servers
> > to decide which is 'best').
> > In this case we are protected by the fact that the incomplete query
> > takes far longer than the complete one due to timeouts.
> >
> > Later though:
> > At 01:12:47 we are out of TTL, so send a request, and get an
> incomplete
> > response... The response only contains the first CNAME, which has
> a 3600
> > TTL.
> >
> > Then dnsmasq doesn't send another query for an hour - despite the fact
> > that it doesn't have a "good" answer.
> > In this case the query it sends after an hour gets incomplete response
> > again - not good.
> > Then I lost track because the container got moved to a different
> host -
> > but it looks like it was returning incomplete for several hours...
> >
> >
> > dnsmasq is otherwise well behaved - it is still responding to other
> > queries just fine, despite being hammered by more than 2k
> queries/second
> >
> > Two questions:
> >  - Is it correct/wanted behaviour to cache an incomplete record
> like this?
> > I have no issue caching the cname, but should we keep trying to
> resolve
> > the cname to an a record?
> >
> >  - Why/How does a restart of the query

Re: [Dnsmasq-discuss] dnsmasq router advertisement/DHCPv6 configuration

2019-04-04 Thread Simon Kelley
On 29/03/2019 16:55, Marco Schuster wrote:
> Hello all,
> 
> I have a working IPv4 setup as follows:
> 1) AVM FritzBox as DSL router
> 2) Debian / dnsmasq 2.80-1 router, with eth0 being uplink to the
> FritzBox and eth1.X the client VLANs (1-16)
> 3) a couple dozen clients in the different VLANs
> 
> Now I want to expand this setup to IPv6.
> 
> The router itself has working IPv6 connectivity, with the FritzBox
> getting a /56 from the provider and distributing a /62 prefix via IA_PD
> and an IPv6 address (not in the /62 prefix but in the larger /56) via
> IA_NA to the router, with dhclient dealing with configuring eth0. An
> example prefix on eth0 would be 2001:a61:2456:b8fc::/62.
> 
> I want each VLAN IPv6 range to be set up as :VLAN_ID: allocation>. How do I express this with dnsmasq?
> 
> In addition: right now I have "interface=eth0, no-dhcp-interface=eth0"
> in the configuration so that machines in the FritzBox network can access
> the DNS resolver part of dnsmasq. Unfortunately, "enable-ra" enables
> router advertisements on eth0, but not on eth1.X according to the logs!
> 
> How do I prevent this and have dnsmasq only send RAs / respond to DHCPv6
> on VLANs where I explicitly state it?
> 

It should only be sending RAs on interfaces where there is a suitable
dhcp-range. Can you show more of your configuration?


Simon.


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


Re: [Dnsmasq-discuss] Preferred vs Valid dhcpv6 lifetime

2019-04-04 Thread Simon Kelley
On 03/04/2019 04:56, Bryce Larson wrote:
> In many dhcpv6 servers and on layer 3 switches, you can configure the
> valid lifetime and the preferred lifetime separately for dhcpv6 leases. 
> Does that functionality exist in dnsmasq?  It doesn't seem to be
> documented in the man page.  Looking under dhcp-range, the lease time
> seems to configure both attributes in the actual dhcp lease.  If that
> feature is not built in, can that be added?

It's not possible to configure this as the code stands. It would be
possible, to change, but not simple, I think.

> 
> Another question I had is if it would be better to have the valid time
> be a bit longer than the preferred time by default.  I notice on some of
> my clients that if the dnsmasq dhcpv6 server is set to a higher lease
> time, that on the DHCP Request from the client after the server has
> responded with an Advertise, they request 7200 seconds as the preferred
> time and 7500 seconds as the valid time.


Dnsmasq should honour this request. All the logic associated with
calculating the time is in the function calculate_times() in src/rfc3315.c

Briefly: if the client asks for times, and they are sane and less than
the configured times, they are used.

ELSE

valid and preferred are both set to the time given in the dhcp-host, or
if none, the dhcp-range.

If the address is deprecated in the kernel's interface, the preferred
time gets set to zero.


Cheers,

Simon.

> 
> ___
> 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


Re: [Dnsmasq-discuss] Netboot drops DNSMasq DHCP offer

2019-04-04 Thread Simon Kelley
On 03/04/2019 19:47, Conrad Kostecki wrote:
> Hi,
> in order to make PXE possible with older notebooks, I've compiled for
> myself Netboot.
> This is a piece of software, which starts from floppy, where you can
> load your dos paket driver and start PXE.
> Basically, it makes possible to boot with PXE by using PCMCIA networks
> cards from floppy, when nothing else is possible to boot from.
> 
> Netboot itself is working so far fine, it initializes itself fine, loads
> my dos packet driver and starts DHCP.
> I can clearly see, that a DHCP broadcast comes into my DNSMasq, which
> replies with a DHCP offer.
> And here it stops. It seems, Netboot can't correctly handle that offer
> by DNSMasq, as it silently drops it and tries again.
> So I see multiple broadcast searches and DHCP offers.
> 
> BUT: If I use DHCP from an ordinary AVM Fritz!Box 7490 (Router), Netboot
> succeeds and can handle the reply from it.
> So the question is, what could go wrong? Can I debug this somehow? Any
> solutions to make this possible work with Netboot?
> 
> Note: Netboot is pretty old, latest release is from 2007. I suspect,
> that maybe DNSMasq does some RFC correct, which is "too new" for those
> old clients.
> Any help would be appreciated.
> 
> Conrad
> 

The packet captures are pretty much identical.

How are you producing the dnsmasq captures? on the host running dnsmasq,
or elsewhere on the network?

The DHCP is asking for, and getting, broadcast replies (ie to
255.255.255.255) It's just possible that : 1) no other DHCP clients
you've used ask for this 2) the firewall configuration on the host
running dnsmasq blocks packets with destination 255.255.255.255.


That's the only theory I can think if at the moment.

Simon.


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


Re: [Dnsmasq-discuss] 'shared-network' behavior would be huge

2019-04-01 Thread Simon Kelley
On 01/04/2019 16:33, Ryan Gray wrote:
> Update on testing the new shared-network configuration:  My lab
> network is the happiest network right now. This is great.
> 
> A few clarifications: I needed to set the source part of the
> shared-network parameter to the IP of my relay, not the IP or
> interface of my dnsmasq server. 

That's expected (and documented) if you're running a relay. In this
case, the only information about which physical network the client is on
is the relay address inserted into the DHCP request by the relay.

> My dnsmasq server is at 10.200.200.1
> which is bound to its br0 interface. My dhcp relay (Brocade switch)
> holds the gateways for VLANs that need DHCP. The one I'm testing is a
> vlan with an IP interface of 192.168.127.254/24 and a subinterface
> 192.168.128.254/24, so all requests from that VLAN are coming from
> 192.168.127.254.
> 
> I added this to my config:
> 
> shared-network=192.168.127.254,192.168.128.0
> 
> And it works!  I am even successfully handing out some addresses based
> on nothing other than their subscriber-id (whole different talk show),
> and it's now working.
> 
> What if I know that an interface is going to have multiple 'gateway'
> IPs, but I'm not sure which one the switch/router will be using as its
> source. In the example above, if I don't know whether or not the
> requests will be coming from .127.254 or .128.254, can I safely just
> have a 'shared-network' config line for each even though one will be a
> bit redundant (shared-network=192.168.127.254,192.168.127.0)?

Yes, that should work fine.


Cheers,

Simon.

> 
> So far, this is really great. Thank you so much.
> 
> 
> Regards,
> Ryan Gray
> 
> On Sun, Mar 31, 2019 at 5:13 PM Simon Kelley  wrote:
>>
>>
>>
>> On 30/03/2019 18:33, Ryan Gray wrote:
>>> TLDR; How do I use "shared-network" exactly?  :)
>>>
>>> Everything compiled and is up and running with no changes to my
>>> existing configs or method of execution. I'm a little unclear about
>>> how to hold this tool.
>>>
>>> Assuming a router interface of 192.168.4.126/25 and no sub interfaces,
>>> I typically do something like this:
>>>
>>> dhcp-range=set:"internet-192_168_4_0_25",192.168.4.1,192.168.4.125,255.255.255.128,1h
>>> tag-if=set:internet-pool,tag:internet-192_168_4_0_25
>>> dhcp-option=tag:"internet-192_168_4_0_25",3,192.168.4.126
>>> dhcp-option=tag:"internet-192_168_4_0_25",1,255.255.255.128
>>> dhcp-option=tag:"internet-192_168_4_0_25",5,8.8.8.8
>>>
>>> If I add another gateway IP to that router interface (I use "gateway
>>> IP" loosely), 192.168.5.0/24 and  and assuming the router with the
>>> ip-helper configured is, by default, going to say "hey, I'm
>>> 192.168.4.126". With ISC, having ranges for 192.168.4.1-125 and
>>> 192.168.5.1-253 within the block of config that defines a
>>> shared-network would make things copacetic.
>>>
>>> The question:  In this scenario, am I to start dnsmasq with
>>> "--shared-network=192.168.4.126,192.168.5.0"?   If so, I'm not
>>> sure if my subnet definition strategy above is going to stay the same
>>> because I'm not sure how dnsmasq is going to treat this in regards to
>>> tags.  Perhaps I'm just looking at this sideways.
>>>
>>
>>
>> You need to have something like
>>
>> shared-network=192.168.4.1,192.168.5.0
>>
>> assuming that the interface on the machine running dnsmasq is 192.168.4.1
>>
>> or
>>
>> shared-network=eth0,192.168.5.0
>>
>> assuming that the interface is so-named.
>>
>> Either of these will allow dnsmasq to allocate addresses on the sunnet
>> that includes 192.168.5.0, but to make that happen you need a dhcp-range
>> which tells it which addresses are available. This dhcp-range MUST have
>> the netmask: normally dnsmasq can figure out the netmask, but it doesn't
>> have enough information in this case.
>>
>> You can set tag in the dhcp-range, as before, and use it to control the
>> DHCP options sent to the client (which should include router, as the
>> normal default route option won't be sent.
>>
>>
>> Simon.
>>
>>
>>
>>> On Fri, Mar 29, 2019 at 4:13 PM Simon Kelley  
>>> wrote:
>>>>
>>>> On 29/03/2019 20:36, Ryan Gray wrote:
>>>>> Hello other humans,
>>>>>
>>>>> First, Simon Kelly, thank you for dnsmasq.
>

Re: [Dnsmasq-discuss] 'shared-network' behavior would be huge

2019-03-31 Thread Simon Kelley



On 30/03/2019 18:33, Ryan Gray wrote:
> TLDR; How do I use "shared-network" exactly?  :)
> 
> Everything compiled and is up and running with no changes to my
> existing configs or method of execution. I'm a little unclear about
> how to hold this tool.
> 
> Assuming a router interface of 192.168.4.126/25 and no sub interfaces,
> I typically do something like this:
> 
> dhcp-range=set:"internet-192_168_4_0_25",192.168.4.1,192.168.4.125,255.255.255.128,1h
> tag-if=set:internet-pool,tag:internet-192_168_4_0_25
> dhcp-option=tag:"internet-192_168_4_0_25",3,192.168.4.126
> dhcp-option=tag:"internet-192_168_4_0_25",1,255.255.255.128
> dhcp-option=tag:"internet-192_168_4_0_25",5,8.8.8.8
> 
> If I add another gateway IP to that router interface (I use "gateway
> IP" loosely), 192.168.5.0/24 and  and assuming the router with the
> ip-helper configured is, by default, going to say "hey, I'm
> 192.168.4.126". With ISC, having ranges for 192.168.4.1-125 and
> 192.168.5.1-253 within the block of config that defines a
> shared-network would make things copacetic.
> 
> The question:  In this scenario, am I to start dnsmasq with
> "--shared-network=192.168.4.126,192.168.5.0"?   If so, I'm not
> sure if my subnet definition strategy above is going to stay the same
> because I'm not sure how dnsmasq is going to treat this in regards to
> tags.  Perhaps I'm just looking at this sideways.
> 


You need to have something like

shared-network=192.168.4.1,192.168.5.0

assuming that the interface on the machine running dnsmasq is 192.168.4.1

or

shared-network=eth0,192.168.5.0

assuming that the interface is so-named.

Either of these will allow dnsmasq to allocate addresses on the sunnet
that includes 192.168.5.0, but to make that happen you need a dhcp-range
which tells it which addresses are available. This dhcp-range MUST have
the netmask: normally dnsmasq can figure out the netmask, but it doesn't
have enough information in this case.

You can set tag in the dhcp-range, as before, and use it to control the
DHCP options sent to the client (which should include router, as the
normal default route option won't be sent.


Simon.



> On Fri, Mar 29, 2019 at 4:13 PM Simon Kelley  wrote:
>>
>> On 29/03/2019 20:36, Ryan Gray wrote:
>>> Hello other humans,
>>>
>>> First, Simon Kelly, thank you for dnsmasq.
>>>
>>> I noticed here
>>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012700.html
>>> that there was discussion of the possibility of supporting behavior like
>>> ISC's 'shared-network'. Did this go anywhere? I would absolutely use
>>> this and would be happy to perform any testing that would help. I didn't
>>> see other mentions of this so I thought I'd ask.
>>>
>>> Dead serious, this would be spectacular.
>>>
>>>
>>
>>
>>
>> Today (actually, yesterday) is your lucky day:
>>
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ae5b7e04a1025167f1b80840e61432a3cea9625c
>>
>> Do please test!
>>
>>
>> Simon
>>
>>
>>> Regards,
>>> Ryan Gray
>>>
>>>
>>> ___
>>> 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
> 

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


Re: [Dnsmasq-discuss] Odd caching behaviour...

2019-03-29 Thread Simon Kelley
On 21/03/2019 11:01, John Robson wrote:
> OK,
> 
> Maybe this does reveal something about the caching...
> Which might be expected behaviour, but I am not convinced it's useful...
> 
> Overnight monitoring has shown that the upstream server does
> occasionally send back an incomplete (but perfectly valid) CNAME only
> response.  Mostly I can justify the caching behaviour based on the TTLs
> of the second CNAME or A record (the server is authoritative for the
> first CNAME, so that's always at 3600).
> 
> As a slight aside:
> dnsmasq sends a query at 22:57:32.599, then again (new transaction id)
> at 22:57:33.601, and at 22:57:36.601.
> This last query gets a response in 0.1 seconds, both the others
> eventually come in (incomplete) at 22:57:44.073
> I am assuming that dnsmasq ignored these late arrivals (either due to a
> default timeout, or just because a better answer has been received -
> this would be comparable with behaviour when it queries multiple servers
> to decide which is 'best').
> In this case we are protected by the fact that the incomplete query
> takes far longer than the complete one due to timeouts.
> 
> Later though:
> At 01:12:47 we are out of TTL, so send a request, and get an incomplete
> response... The response only contains the first CNAME, which has a 3600
> TTL.
> 
> Then dnsmasq doesn't send another query for an hour - despite the fact
> that it doesn't have a "good" answer.
> In this case the query it sends after an hour gets incomplete response
> again - not good.
> Then I lost track because the container got moved to a different host -
> but it looks like it was returning incomplete for several hours...
> 
> 
> dnsmasq is otherwise well behaved - it is still responding to other
> queries just fine, despite being hammered by more than 2k queries/second
> 
> Two questions:
>  - Is it correct/wanted behaviour to cache an incomplete record like this?
> I have no issue caching the cname, but should we keep trying to resolve
> the cname to an a record?
> 
>  - Why/How does a restart of the querying program change the caching
> behaviour of dnsmasq?
> Because even if the program is restarted after just a few minutes it
> immediately gets better data - my capture from yesterday shows that
> despite the fact that the TTL had 2855 seconds (of the 3600 default)
> left just two minutes before the first 'new process' request comes in,
> that new request triggers an outbound query.
> 
> 
> Cheers,
> 
> John
> 

What's you're calling an "incomplete" answer is actually a perfectly
good answer. Dnsmasq is entitled to infer that the target of the CNAME
doesn't exist if it's not included in the answer, and keep that
information in the cache for the the TTL  period.

Note that is _only_ true if the the upstream server is a recursive
server - as such it's expected to attempt the follow the CNAME and
return as much of the chain as exists. If the upstream server is an
authoritative server, that's not true - if the CNAME target is outside
the domain(s) that the server is authoritative for, then the target will
not be included. This is one reason why dnsmasq should only use
recursive servers, an it will log an error if an upstream server is not
recursive (ra flag not set). It's also the most common reason why people
see the dnsmasq behaviour you're describing.



Cheers,

Simon.


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


Re: [Dnsmasq-discuss] [PATCH] Improve UBus support

2019-03-29 Thread Simon Kelley
This all looks sensible, with one exception: the logging in
set_ubus_listeners() and check_ubus_listeners() and associated with the
calls to check_ubus_listeners can potentially massively span the logs -
a long lived error will log multiple lines every time dnsmasq spins its
event loop. It would be good to have rate limiting there. Set a flag
after logging the error which inhibits further errors, clear it once a
normal situation is restored.


Cheers,

Simon.



On 25/03/2019 12:12, Jan Willem Janssen wrote:
> Improve the UBus support in DNSMASQ:
> 
> - Aligned the handling of UBus connections with the DBus code as it makes it 
> a bit easier
> to comprehend and allow for automatic reconnects when the connection to UBus 
> drops;
> - make sure that DNSMASQ can connect to UBus when running as another user 
> than root;
> - added status checks and logging to the various UBus calls to aid debugging 
> from an
> enduser point of view;
> - show the (lack of) support for UBus in the configuration string.
> 
> ---
>  src/config.h  |   4 ++
>  src/dnsmasq.c |  38 -
>  src/dnsmasq.h |   6 +++
>  src/ubus.c| 114 --
>  4 files changed, 139 insertions(+), 23 deletions(-)
> 
> diff --git a/src/config.h b/src/config.h
> index 203d69e..99b22eb 100644
> --- a/src/config.h
> +++ b/src/config.h
> @@ -362,6 +362,10 @@ static char *compile_opts =
>  "no-"
>  #endif
>  "DBus "
> +#ifndef HAVE_UBUS
> +"no-"
> +#endif
> +"UBus "
>  #ifndef LOCALEDIR
>  "no-"
>  #endif
> diff --git a/src/dnsmasq.c b/src/dnsmasq.c
> index 3f3edbd..5d89aa1 100644
> --- a/src/dnsmasq.c
> +++ b/src/dnsmasq.c
> @@ -420,6 +420,18 @@ int main (int argc, char **argv)
>die(_("DBus not available: set HAVE_DBUS in src/config.h"), NULL, 
> EC_BADCONF);
>  #endif
>  
> +  if (option_bool(OPT_UBUS))
> +#ifdef HAVE_UBUS
> +{
> +  const char *err;
> +  daemon->ubus = NULL;
> +  if ((err = ubus_init()))
> +my_syslog(LOG_WARNING, _("UBus init failed: %s"), (char *)err, 
> EC_MISC);
> +}
> +#else
> +  die(_("UBus not available: set HAVE_UBUS in src/config.h"), NULL, 
> EC_BADCONF);
> +#endif
> +
>if (daemon->port != 0)
>  pre_allocate_sfds();
>  
> @@ -812,6 +824,16 @@ int main (int argc, char **argv)
>  }
>  #endif
>  
> +#ifdef HAVE_UBUS
> +  if (option_bool(OPT_UBUS))
> +{
> +  if (daemon->ubus)
> +my_syslog(LOG_INFO, _("UBus support enabled: connected to system 
> bus"));
> +  else
> +my_syslog(LOG_INFO, _("UBus support enabled: bus connection 
> pending"));
> +}
> +#endif
> +
>  #ifdef HAVE_DNSSEC
>if (option_bool(OPT_DNSSEC_VALID))
>  {
> @@ -1000,7 +1022,7 @@ int main (int argc, char **argv)
>  
>  #ifdef HAVE_UBUS
>if (option_bool(OPT_UBUS))
> - set_ubus_listeners();
> +set_ubus_listeners();
>  #endif
>   
>  #ifdef HAVE_DHCP
> @@ -1135,7 +1157,19 @@ int main (int argc, char **argv)
>  
>  #ifdef HAVE_UBUS
>if (option_bool(OPT_UBUS))
> -check_ubus_listeners();
> +{
> +  /* if we didn't create a UBus connection, retry now. */
> +  if (!daemon->ubus)
> +{
> +  const char *err;
> +  if ((err = ubus_init()))
> +my_syslog(LOG_WARNING, _("UBus problem: %s"), err);
> +  if (daemon->ubus)
> +my_syslog(LOG_INFO, _("Connected to system UBus"));
> +}
> +
> +  check_ubus_listeners();
> +}
>  #endif
>  
>check_dns_listeners(now);
> diff --git a/src/dnsmasq.h b/src/dnsmasq.h
> index 0e409b4..f5e154e 100644
> --- a/src/dnsmasq.h
> +++ b/src/dnsmasq.h
> @@ -1119,6 +1119,11 @@ extern struct daemon {
>  #ifdef HAVE_DBUS
>struct watch *watches;
>  #endif
> +  /* UBus stuff */
> +#ifdef HAVE_UBUS
> +  /* void * here to avoid depending on ubus headers outside ubus.c */
> +  void *ubus;
> +#endif
>  
>/* TFTP stuff */
>struct tftp_transfer *tftp_trans, *tftp_done_trans;
> @@ -1456,6 +1461,7 @@ void emit_dbus_signal(int action, struct dhcp_lease 
> *lease, char
> *hostname);
>  
>  /* ubus.c */
>  #ifdef HAVE_UBUS
> +const char *ubus_init(void);
>  void set_ubus_listeners(void);
>  void check_ubus_listeners(void);
>  void ubus_event_bcast(const char *type, const char *mac, const char *ip, 
> const char
> *name, const char *interface);
> diff --git a/src/ubus.c b/src/ubus.c
> index 703a60d..c58c231 100644
> --- a/src/ubus.c
> +++ b/src/ubus.c
> @@ -20,29 +20,94 @@
>  
>  #include 
>  
> -static struct ubus_context *ubus = NULL;
>  static struct blob_buf b;
> +static int notify;
>  
>  static int ubus_handle_metrics(struct ubus_context *ctx, struct ubus_object 
> *obj,
>struct ubus_request_data *req, const char 
> *method,
>struct blob_attr *msg);
> -static struct ubus_method ubus_object_methods[] = {
> -  {.name = "metrics", .handler = ubus_handle_metrics},
> +
> +static 

Re: [Dnsmasq-discuss] Is wrapping close() in retry_send() required ?

2019-03-29 Thread Simon Kelley
On 26/03/2019 19:33, Pali Rohár wrote:
> On Wednesday 27 February 2019 17:07:21 Simon Kelley wrote:
>> On 27/02/2019 15:06, Bogdan Harjoc wrote:
>>> There are 50 calls to close() in dnsmasq-2.80, and 10 of them are
>>> wrapped in retry_send().
>>>
>>> "man close" has this paragraph in the section "Dealing with error
>>> returns from close":
>>>
>>> "Retrying the close() after a failure return is the wrong thing to do,
>>> since this may cause a reused file descriptor from another thread to
>>> be closed. This can occur because the Linux kernel always releases the
>>> file descriptor early in the close operation, freeing it for reuse;
>>> the steps that may return an error, such as flushing data to the
>>> filesystem or device, occur only later in the close operation".
>>>
>>> Dnsmasq is single-threaded so the retry_send() call is probably
>>> harmless. Are there other OSes that may return an error before the fd
>>> is released, in other words is there an OS where wrapping close in
>>> retry_send is required ?
>>
>>
>> Good questions.
>>
>> Note that retry_send() only deals with EINTR return codes, ie
>> interrupted system calls. (Ok there are other return codes in there, but
>> nothing which might be returned by close())
>>
>> So the use of retry_send(close(...)) is simply to restart the close()
>> syscall if a signal arrives during the syscall.
>>
>>
>> HOWEVER, whilst the man page for close() on my Linux machine states that
>> EINTR is a possible error return, man (7) signal does NOT include
>> close() in the set of syscalls which can be interrupted.
>>
>> Clearly I was reading the close() man page when I used the wrapper, and
>> signal man page when I didn't :)
>>
>>
>> You're probably right that it doesn't matter, but it would be nice to
>> make this at least consistent.
>>
>> Anyone know the answer?
> 
> See manpage: http://man7.org/linux/man-pages/man2/close.2.html
> 
> 
> The EINTR error is a somewhat special case.  Regarding the EINTR
> error, POSIX.1-2013 says:
> 
>If close() is interrupted by a signal that is to be caught, it
>shall return -1 with errno set to EINTR and the state of
>fildes is unspecified.
> 
> This permits the behavior that occurs on Linux and many other
> implementations, where, as with other errors that may be reported by
> close(), the file descriptor is guaranteed to be closed.  However, it
> also permits another possibility: that the implementation returns an
> EINTR error and keeps the file descriptor open.  (According to its
> documentation, HP-UX's close() does this.)  The caller must then once
> more use close() to close the file descriptor, to avoid file
> descriptor leaks.  This divergence in implementation behaviors
> provides a difficult hurdle for portable applications, since on many
> implementations, close() must not be called again after an EINTR
> error, and on at least one, close() must be called again.  There are
> plans to address this conundrum for the next major release of the
> POSIX.1 standard.
> 
> 
> So retrying close() on EINTR on Linux is an application bug. On the
> other hand it is required on HP-UX.
> 
>

Thanks Pali, that looks pretty definitive. As dnsmasq is supported on
Linux but not on HP-UX, I've made the relevant changes.


Cheers,

Simon.


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


Re: [Dnsmasq-discuss] 'shared-network' behavior would be huge

2019-03-29 Thread Simon Kelley
On 29/03/2019 20:36, Ryan Gray wrote:
> Hello other humans,
> 
> First, Simon Kelly, thank you for dnsmasq.
> 
> I noticed here
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012700.html
> that there was discussion of the possibility of supporting behavior like
> ISC's 'shared-network'. Did this go anywhere? I would absolutely use
> this and would be happy to perform any testing that would help. I didn't
> see other mentions of this so I thought I'd ask.
> 
> Dead serious, this would be spectacular.
> 
> 



Today (actually, yesterday) is your lucky day:

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ae5b7e04a1025167f1b80840e61432a3cea9625c

Do please test!


Simon


> Regards,
> Ryan Gray
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] [PATCH] Fix cmsg(3) API usage on OpenBSD

2019-03-28 Thread Simon Kelley
Patch applied. Many thanks. There's another instance of the same problem
the src/dhcp.c which I've fixed as a separate commit.


Cheers,

Simon.



On 22/03/2019 10:36, Jeremie Courreges-Anglas wrote:
> 
> Hi,
> 
> an unpatched dnsmasq daemon fails on OpenBSD since 2016, since kernel
> support was added for IP_SENDSRCADDR.  The problem has been worked
> around and then fixed in our ports tree for some time now.  Please find
> attached a patch to address this issue.
> 
> IIUC the existing code was inspired from an example in the cmsg(3) Linux
> manpage.  Said manpage was fixed since, this bugreport contains a nice
> discussion:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=15952
> 
> The patch was only tested on OpenBSD but should hopefully be correct on
> all affected systems.  Please let me know if you need additional
> information.
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] Parsing limitation for big dns query responses in tcp

2019-03-22 Thread Simon Kelley
Could you give more details on exactly how you're testing this?
Whereever that error is coming from, it's not from dnsmasq, which
doesn't use the resolver library at all.


Simon.


On 20/03/2019 14:59, Philippe Lamhaut wrote:
> Hello,
> 
> I am using dnsmasq version 2.80 as dns client in an application. Testing
> different size of dns query responses in tcp.
> 
> The biggest response that is properly parsed by the application has the
> following specifications: 
> dns response size: 2049
> tcp PDU size:         2051
> Answers RRs:            30
> Additional RRs:          31
> 
> When the response is bigger than that the ns_initparse() function fails
> with "Message too long" error.
> 
> Appreciate any help to understand where is the bottleneck and if
> something can be do to support bigger responses.
> 
> Thanks,
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] Minimal capabilities for options

2019-03-16 Thread Simon Kelley
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=305ffb5ef0ba5ab1df32ef80f266a4c9e395ca13

is a first pass on this.

I have a nasty feeling that there are configurations which need some of
the capabilities and have had a free pass because they are always there,
which I've missed (I only just noticed that the IPset code needs
NET_ADMIN) No doubt they will turn up eventually.


Please test!


Cheers,

Simon.



On 20/01/2019 10:38, Mathieu Hofman wrote:
> Running dnsmasq in docker currently requires explicitly granting the
> NET_ADMIN capability for the container, or dnsmasq fails to start if
> configured to drop root.
> 
> The failure is due to a capset() call that includes NET_ADMIN when
> dnsmasq attempts to keep capabilities before dropping root. If the
> capability is not already available, the call fails. If dnsmasq doesn't
> drop root, the checks are skipped and it starts successfully without the
> capability, but potentially fails later depending on the configured options.
> 
> From what I gather, the NET_ADMIN capability is only needed to inject a
> neighbor / ARP entry after receiving a DHCP request from a client so
> that the response can be sent using unicast. The capability is not
> required if the DHCP server is disabled or if the dhcp-broadcast option
> is used.
> 
> The NET_RAW capability is similarly needed to send an ICMP ping before
> allocating an address for a client, but pings are not used if the DHCP
> server is disabled or if the no-ping option is specified.
> 
> I would like to suggest 2 improvements to the way capabilities are
> handled in dnsmasq:
> 
> 1) Only try to keep capabilities which are actually needed according to
> the configured options. If the DHCP server is disabled, do not keep (or
> request if not available) the NET_ADMIN and NET_RAW capabilities. If the
> dhcp-broadcast option is specified, do not include NET_ADMIN. If no-ping
> is specified, do not include NET_RAW.
> Currently the NET_BIND_SERVICE capability is kept only if DAD or dynamic
> binding are required by the config. This suggestion would use similar
> logic for the NET_ADMIN and NET_RAW capabilities.
> 
> 2) Check that the capabilities required for the configuration are
> available to the process when starting, and fail early if they are not.
> Currently capabilities are not checked. It's only a side effect of the
> capset() call when dropping root that dnsmasq will fail to start if a
> capability is missing. If dnsmasq is configured to not drop privileges,
> such as starting as a non-root user, or staying root without changing
> user, dnsmasq will only fail later when attempting to use a feature
> requiring the capability.
> 
> Optionally, dnsmasq could try to automatically disable any configured
> feature that relies on the missing capability, and probably warn such
> action was taken in the logs. For the NET_RAW capability, it's probably
> not possible to disable pings if the DHCP server is not authoritative as
> that might be too risky. For the NET_ADMIN capability hopefully it's
> safe to automatically switch to dhcp-broadcast.
> 
> For now, I'm working around the current capabilities handling by
> manually dropping root and granting the required capabilities to dnsmasq
> before executing it. Dnsmasq seem to run fine from what I can tell, but
> I've only tested it in my environment.
> My docker config for this is
> here: https://gist.github.com/mhofman/cdd85a6baa4b9206830b254d0ab9bb89
> 
> To summarize the new suggested capabilities logic would be:
> - Figure out the set of capabilities required for the configured options
> (regardless of user config).
> - Check if the process has the required capabilities. Fail if not, or
> optionally gracefully degrade features and warn.
> - If configured to drop root, call capset() only with required capabilities.
> 
> The current alternative is not acceptable in my opinion: keep running as
> root (or worse, in debug mode).
> 
> This change would also help pi-hole which recently added code to check
> for available capabilities before invoking dnsmasq.
> See https://github.com/pi-hole/FTL/issues/432
> 
> A similar request was made in
> 2013: 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q2/007188.html
> 
> Mathieu
> 
> ___
> 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


Re: [Dnsmasq-discuss] Why is a different TTL resturned for bare and FQDN queries?

2019-03-15 Thread Simon Kelley
Sorry for lack of reply to this, I hope you're still there, Wojtek.


I think this may have something to do with your other post about
authoritative mode - one of the answers has the "aa" flag set, and the
other one doesn't.


It would be useful, for both of the situations you describe, to set
--log-queries in dnsmasq and post what it actually logs during these tests.



Cheers,

Simon.


On 02/02/2019 21:56, Wojtek Swiatek wrote:
> 
> switch-3 is a device which gets its IP via DHCP from dnsmasq. When
> trying to resolve it on dnsmasq (which expands hosts):
> 
> 
> root@rpi1 ~# dig @10.200.0.40  switch-3
> 
> ; <<>> DiG 9.11.4-4-Raspbian <<>> @10.200.0.40  switch-3
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57399
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;switch-3.                      IN      A
> 
> ;; ANSWER SECTION:
> switch-3.               0       IN      A       10.200.0.123
> 
> ;; Query time: 0 msec
> ;; SERVER: 10.200.0.40#53(10.200.0.40)
> ;; WHEN: Sat Feb 02 22:52:01 CET 2019
> ;; MSG SIZE  rcvd: 53
> 
> 
> 
> root@rpi1 ~# dig @10.200.0.40  switch-3.swtk.info
> 
> 
> ; <<>> DiG 9.11.4-4-Raspbian <<>> @10.200.0.40 
> switch-3.swtk.info 
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39739
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;switch-3.swtk.info .            IN      A
> 
> ;; ANSWER SECTION:
> switch-3.swtk.info .     600     IN      A   
>    10.200.0.123
> 
> ;; Query time: 0 msec
> ;; SERVER: 10.200.0.40#53(10.200.0.40)
> ;; WHEN: Sat Feb 02 22:52:06 CET 2019
> ;; MSG SIZE  rcvd: 63
> 
> 
> 
> 
> So one response (to the bare query provides a TTL of 0, and the other
> one (FQDN) - 600.
> 
> I do not know whether this normal/expected or not, and whether this is a
> problem or not?
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] Use dnsmasq to assign static /32 addresses via DHCP

2019-03-15 Thread Simon Kelley
On 15/03/2019 12:44, Peter Lieven wrote:
> Hi Simon,
> 
> Am 14.03.19 um 18:41 schrieb Simon Kelley:
>> Is this a use for something like the ISC dhcpd shared-network configuration.
>>
>>
>> In the dnsmasq case, we could have something like
>>
>> shared-network=,
>>
>> or
>>
>> shared-network=,
>>
>> In the first case dnsmasq would behave _as_if_ the specified interface
>> carried the address and netmask specified.
>>
>> In the second case, it would behave as if the interface which carries
>> interface-address also carried the address and netmask specified.
>>
>> If I've understood correctly, you'd just need a shared-network
>> declaration for each of your /24s.
> 
> 
> What you describe is exactly what I would need. However, as far
> 
> as I understand the documentation of the shared network feature in ISC dhcpd
> 
> they still require that the network is configured on the DHCP interface (as 
> alias, secondary etc.).
> 
> This already works in dnsmasqd. I would need the feature that does not
> 
> require the addresses to be actually configured on the interface as you
> 
> describe it.
> 


I may have miss-understood the dhcpd case - what it does or doesn't do
is probably irrelevant to what dnsmasq can  do in this case.


As far as I can see, there's no reason why it shouldn't work, with the
following caveats.

1) The DHCP server interface must have at least one address configured,
and that address needs to be reachable from configured clients. This
address gets used as the "server identifier" field in unicast
transmissions from the client to the server for things like lease
renewal. The case that the server-id is not on the same network as the
client is not new, it's the case when using a DHCP relay.

2) Dnsmasq currently guesses at the default router to send to a client,
unless it's overridden by configuration. This is either its own address
on the network where the client is given an address, or, if the DHCP
came via relay, then it's the address of the relay on the network where
the client is given an address. In the case that a client is being given
an address on a network where neither the DHCP server or the DHCP relay
have an address, there's no sensible guess for what the client's default
router should be set to, so explicit configuration will have to be
mandatory.

Cheers,

Simon.


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


Re: [Dnsmasq-discuss] Use dnsmasq to assign static /32 addresses via DHCP

2019-03-14 Thread Simon Kelley
Is this a use for something like the ISC dhcpd shared-network configuration.


In the dnsmasq case, we could have something like

shared-network=,

or

shared-network=,

In the first case dnsmasq would behave _as_if_ the specified interface
carried the address and netmask specified.

In the second case, it would behave as if the interface which carries
interface-address also carried the address and netmask specified.

If I've understood correctly, you'd just need a shared-network
declaration for each of your /24s.



For the avoidance of doubt, this is NOT currently implemented on
dnsmasq, but it has been on the "desirable" list in my head for some time.


Simon.



On 12/03/2019 11:56, Peter Lieven wrote:
> Hi,
> 
> we run several thousand virtual gateways which are used to assign /32
> allocations to Virtual Servers via DHCP.
> 
> 
> This so far runs pretty well except for one hack that we had to make and
> that I would like to avoid.
> 
> We assign the /32 networks out of /24 blocks that we reserved for this
> purpose. However, dnsmasq only
> assigns IP addresses via an interface if the network is configured on
> that interface. We had to add some
> more specific routes on the gateways to make a 2 hosts that receive a
> /32 out of the same /24 see each
> other if they are on different gateways. In fact I would like to
> configure only one common virtual address
> on the vserver facing interface lets say 10.255.255.255/32.
> 
> What I would like to need is an option to either make dnsmasq assign
> addresses out of an dhcp-range even
> if the network is not configured on the dhcp interface or an option
> where dnsmasq runs in a mode where it
> 
> does not require dhcp-range options, but only works using dhcp-host
> entries and replies if gets a request
> 
> for a static mac address entry.
> 
> 
> My config looks basically like this:
> 
> [virtual gw1]
> 
> dhcp-range=set:virtualgw,10.0.0.2,10.0.0.254,infinite,static
> 
> dhcp-host=52:54:00:00:00:01,10.0.0.2,vserver1
> 
> dhcp-option=tag:virtualgw,1,255.255.255.255
> dhcp-option=tag:virtualgw,3,10.255.255.255
> dhcp-option=tag:virtualgw,28,255.255.255.255
> 
> dhcp-option=tag:virtualgw,121,10.255.255.255/32,0.0.0.0,0.0.0.0/0,10.255.255.255
> 
> 
> 
> [virtual gw2]
> 
> dhcp-range=set:virtualgw,10.0.0.2,10.0.0.254,infinite,static
> 
> dhcp-host=52:54:00:00:00:02,10.0.0.3,vserver1
> 
> dhcp-option=tag:virtualgw,1,255.255.255.255
> dhcp-option=tag:virtualgw,3,10.255.255.255
> dhcp-option=tag:virtualgw,28,255.255.255.255
> 
> dhcp-option=tag:virtualgw,121,10.255.255.255/32,0.0.0.0,0.0.0.0/0,10.255.255.255
> 
> 
> 
> To make dnsmasq deliver addresses out of 10.0.0.0/24 I have to configure
> 10.0.0.1/24
> 
> on the DHCP interface. To ensure reachability between 10.0.0.2 and
> 10.0.0.3 I have
> 
> configured static routes 10.0.0.0/25 and 10.0.0.128/25 towards the
> default gw.
> 
> The configuration of 10.0.0.1/24 on the DHCP interface and the static
> routes is what I would like to avoid.
> 
> 
> Thanks for your feedback,
> 
> Peter
> 
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] Configuring DHCPv6 Vendor specific information using Option 17

2019-03-14 Thread Simon Kelley


On 14/03/2019 03:13, P, Sreelakshmi wrote:
> Thanks Simon, this works!
> 
> In case of DHCP v4 vendor option, it's not mandatory to provide encapsulated 
> vendor specific information. Here in DHCPv6, I see that the option 17 doesn't 
> work without giving enterprise ID for encapsulation. Why so?

I think because the only defined form of vendor-specific option defined
for DHCPv6 is the so-called vendor-identifying vendor specific option,
which includes the vendor-id as part of the option. If the option format
includes the vendor-id then the vendor-id must be provided.

> Also, is there a way to give hex as vendor option value that can include 
> enterprise ID as well?
> 
--dhcp-option=vi-encap:47196,option6:100,11:22:33:44:55:66:77

should work.


Simon.


> Regards,
> Sree
> 
> -Original Message-
> From: Dnsmasq-discuss 
> [mailto:dnsmasq-discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon 
> Kelley
> Sent: Tuesday, March 5, 2019 4:04 AM
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: Re: [Dnsmasq-discuss] Configuring DHCPv6 Vendor specific information 
> using Option 17
> 
> You need something like
> 
> --dhcp-option=vi-encap:47196,option6:100,\
> "AOS-Switch:Top:Tokyo,3ffe:501::100::abcd,aruba123"
> 
> 
> Check the vendor-specific option number. I got the value of 100 from the data 
> you provided, but I may have decoded it wrong.
> 
> Cheers,
> 
> Simon.
> 
> 
> On 04/03/2019 10:01, P, Sreelakshmi wrote:
>> Hi All,
>>
>>  
>>
>> How to we configure vendor specific information in dnsmasqv6 using 
>> option 17?
>>
>>  
>>
>> Every time I tried to configure option 17 as below :
>>
>>  
>>
>> dnsmasq
>> --dhcp-option=option6:17,003db85c00640035414f532d5377697463683a546
>> f703a546f6b3
>> -test
>>
>>  
>>
>> I ended up getting the below error:
>>
>>     dnsmasq: bad command line options: bad IPv6 address
>>
>>  
>>
>>  
>>
>> What is the proper way to configure option 17 in dnsmasq? Below is my 
>> enterprise id and data:
>>
>>  
>>
>> Enterprise Id : *47196*
>>
>> Data : *¸\d5AOS-Switch:Top:Tokyo,3ffe:501::100::abcd,aruba123*
>>
>>  
>>
>> If we try to configure the same value using other DHCPv6 servers, it 
>> works fine.
>>
>> Any example? Can we configure the value as ASCII or HEX? Any help will 
>> be greatly appreciated.
>>
>>  
>>
>> Regards,
>>
>> Sree
>>
>>  
>>
>>
>> ___
>> 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
> 

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


Re: [Dnsmasq-discuss] TCP Fast Open?

2019-03-10 Thread Simon Kelley
On 10/03/2019 02:02, Craig Andrews wrote:
> TCP Fast Open eliminates a round trip for TCP connections. Since dnsmasq
> is performance sensitive and uses many TCP connections, using TCP Fast
> Open would be a nice improvement. See https://lwn.net/Articles/508865/
> for background.
> 
> On the client side, it's as simple as setting the TCP_FASTOPEN_CONNECT
> option on the socket.
> 
> On the server side, dnsmasq would do something like this on the
> listening socket:
> 
> int qlen = 5;
> setsockopt(fd, SOL_TCP, TCP_FASTOPEN, , sizeof(qlen));
> 
> Chrome and Firefox have supported TCP Fast Open for clients for over a
> year, and other DNS servers (ex unbound) use it for client and sever
> connections too.
> 
> Could dnsmasq implement TCP Fast Open?
> 
> Thanks,
> ~Craig
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

I think

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=608aa9fcfca2ffeba40d78c7c4e0dcb50e0d5704

should do the trick. Please test.


Cheers,

Simon.



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] "No IPv6 address available" for bulk request from IXIA DHCPv6 clients

2019-03-07 Thread Simon Kelley
What a strange configuration!

I can sort-of explain what's happening here.

DHCP is a two-phase process: The server first suggests an address, then
the client accepts it and tells the server that it will be using the
address.

In dnsmasq, the first phase does not reserve an address. It's completely
idempotent. The client is given a suggested address, but there's nothing
to stop the same address being suggested to another client until the
first one comes along and reserves it. The address suggested to a client
is determined in part by a hash of the client's MAC address or some
other unique feature, so that clashes are very rare.

However in this case, you have dhcp ranges holding only two addresses.
Whilst the first range has at least one free address, it will be used to
suggest the address to use. The hash doesn't  work: if there's only one
free address, then that will be suggested and the hash can't change it.

So when lots of clients come along at once and ask for an address, they
all get one of the two addresses from the first dhcp-range. When they
come back to comfirm the address, all but two are refused because the
address in already in use.

If the clients come along one at a time, the addresses that are already
committed to the earlier clients don't get suggested, and the clients
get an address which they can sucessfuly commit.



The fix is to use a more conventional dhcp-range configuration. Another
possible fix might be to use the  --dhcp-sequential-ip  setting. That
_might_ behave more sanely under these conditions, but I've not tested
it, so no guarantees.

Cheers,

Simon.



On 07/02/2019 10:12, P, Sreelakshmi wrote:
> Hi All,
> 
>  
> 
> I’m trying to simulate DHCPv6 clients from IXIA and observe that only 1
> or 2 clients gets honored with IPv6 address when simultaneous requests
> are sent from 64 clients, but the same thing works if the request is
> made one after the other sequentially.
> 
>  
> 
> *_Configuration below:_*
> 
>  
> 
>     log-facility=/var/log/dnsmasq_swns/dnsmasq6.log
> 
> port=0
> 
> dhcp-script=/usr/bin/dhcp_server_leases
> 
> leasefile-ro
> 
> dhcp-lease-max=64000
> 
> bind-dynamic
> 
> dhcp-range=set:default+test,2000::e:2,2000::e:3
> 
> dhcp-range=set:default+test,2000::27:1,2000::27:2
> 
> dhcp-range=set:default+test,2000::16:1,2000::16:2
> 
> dhcp-range=set:default+test,2000::7:1,2000::7:2
> 
> dhcp-range=set:default+test,2000::26:1,2000::26:2
> 
> dhcp-range=set:default+test,2000::3b:1,2000::3b:2
> 
> dhcp-range=set:default+test,2000::32:1,2000::32:2
> 
> dhcp-range=set:default+test,2000::40:1,2000::40:2
> 
> dhcp-range=set:default+test,2000::28:1,2000::28:2
> 
> dhcp-range=set:default+test,2000::1b:1,2000::1b:2
> 
> dhcp-range=set:default+test,2000::3f:1,2000::3f:2
> 
> dhcp-range=set:default+test,2000::12:1,2000::12:2
> 
> dhcp-range=set:default+test,2000::9:1,2000::9:2
> 
> dhcp-range=set:default+test,2000::d:1,2000::d:2
> 
> dhcp-range=set:default+test,2000::36:1,2000::36:2
> 
> dhcp-range=set:default+test,2000::24:1,2000::24:2
> 
> dhcp-range=set:default+test,2000::1f:1,2000::1f:2
> 
> dhcp-range=set:default+test,2000::34:1,2000::34:2
> 
> dhcp-range=set:default+test,2000::21:1,2000::21:2
> 
> dhcp-range=set:default+test,2000::3a:1,2000::3a:2
> 
> dhcp-range=set:default+test,2000::17:1,2000::17:2
> 
> dhcp-range=set:default+test,2000::3d:1,2000::3d:2
> 
> dhcp-range=set:default+test,2000::1:1,2000::1:2
> 
> dhcp-range=set:default+test,2000::f:1,2000::f:2
> 
> dhcp-range=set:default+test,2000::22:1,2000::22:2
> 
> dhcp-range=set:default+test,2000::14:1,2000::14:2
> 
> dhcp-range=set:default+test,2000::2c:1,2000::2c:2
> 
> dhcp-range=set:default+test,2000::19:1,2000::19:2
> 
> dhcp-range=set:default+test,2000::1d:1,2000::1d:2
> 
> dhcp-range=set:default+test,2000::2:1,2000::2:2
> 
> dhcp-range=set:default+test,2000::37:1,2000::37:2
> 
> dhcp-range=set:default+test,2000::a:1,2000::a:2
> 
> dhcp-range=set:default+test,2000::38:1,2000::38:2
> 
> dhcp-range=set:default+test,2000::2a:1,2000::2a:2
> 
> dhcp-range=set:default+test,2000::23:1,2000::23:2
> 
> dhcp-range=set:default+test,2000::2b:1,2000::2b:2
> 
> dhcp-range=set:default+test,2000::4:1,2000::4:2
> 
> dhcp-range=set:default+test,2000::15:1,2000::15:2
> 
> dhcp-range=set:default+test,2000::8:1,2000::8:2
> 
> dhcp-range=set:default+test,2000::35:1,2000::35:2
> 
> dhcp-range=set:default+test,2000::1e:1,2000::1e:2
> 
> dhcp-range=set:default+test,2000::b:1,2000::b:2
> 
> dhcp-range=set:default+test,2000::3c:1,2000::3c:2
> 
> dhcp-range=set:default+test,2000::25:1,2000::25:2
> 
> dhcp-range=set:default+test,2000::3:1,2000::3:2
> 
> dhcp-range=set:default+test,2000::33:1,2000::33:2
> 
> dhcp-range=set:default+test,2000::31:1,2000::31:2
> 
> dhcp-range=set:default+test,2000::6:1,2000::6:2
> 
> dhcp-range=set:default+test,2000::18:1,2000::18:2
> 
> dhcp-range=set:default+test,2000::11:1,2000::11:2
> 
> dhcp-range=set:default+test,2000::1a:1,2000::1a:2
> 
> 

Re: [Dnsmasq-discuss] Query forwarding behaviour with multiple name servers.

2019-03-07 Thread Simon Kelley
On 08/02/2019 09:49, John Robson wrote:
> Hi all,
> 
> I'm trying to understand the mechanism by which dnsmasq uses the
> resolvers specified (in this case they are all specified in
> /etc/resolv.conf).
> Specifically I am trying to work out why dnsmasq is (erratically)
> sending the same query to multiple servers, and not listening beyond the
> first response.
> 
> 
> As I understand it the default (i.e. non dnsmasq) resolver behaviour is
> to try the first name server entry first, then the second etc.  This can
> be changed by use of the 'rotate' option in that file.
> 
> However, dnsmasq reads it's name servers from /etc/resolv.conf, but the
> defaults are different - relevant options from the man page say:
> *-o, --strict-order*
> By default, dnsmasq will send queries to any of the upstream servers
> it knows about and tries to favour servers that are known to be up.
> Setting this flag forces dnsmasq to try each query with each server
> strictly in the order they appear in /etc/resolv.conf
> *--all-servers*
> By default, when dnsmasq has more than one upstream server
> available, it will send queries to just one server. Setting this
> flag forces dnsmasq to send all queries to all available servers.
> The reply from the server which answers first will be returned to
> the original requester.
> 
> To me that means that, by default, dnsmasq will send to any one of the
> upstream servers, favouring servers it thinks are up - that seems
> reasonable.
> 
> 
> What I am seeing is that sometimes (and I can't figure a packet count, a
> query count, or a time based correlation) dnsmasq forwards a query to
> both of the listed name servers (I presume this is part of the
> 'aliveness' testing?).
> When this happens dnsmasq then only listens to the first reply, meaning
> that the server which is slightly slower/further away then gets their
> response bounced in an ICMP port unreachable message from the dnsmasq box.
> 
> I then see dnsmasq stick to the 'first responding' server until it
> forwards a query to both again (always in the same order, that listed in
> /etc/resolv.conf) and, depending on the first response, it either sticks
> or flips it's preferred server until ???
> 
> 
> Two questions:
>  - What triggers dnsmasq to forward a query to multiple upstream
> resolvers (aside from the first query after startup, which seems reasonable)

Kevin answered this.

>  - Why does dnsmasq not bother to listen for the second (or more)
> response - which would surely be useful in terms of timing/aliveness
> information, as well as less odd for the upstream server*.

Because to do so involves keeping resources around: at least some state
and an open network socket. Since a server may never respond, those
resources have to be reclaimed at some point (this functions exists
already, since no answer may be forthcoming from any server) If dnsmasq
is sending queries to a server which never answers, that implies far
more resources hanging around during a long timeout, which increases the
resource footprint for the daemon, and maybe even provides an DoS attack
opportunity. TBH, it never occurred to me that the subsequent replies
had any real utility, but I can see that they might. I'm not aware of
any DNS server which would react in any way to an ICMP port unreachable.
Don't forget that this is UDP. The server sends the reply "fire an
forget". I think it would be next to impossible to get the OS to even
tell the server that the port unreachable message had been seen.


Cheers,

Simon.


> 
> Cheers,
> 
> John
> 
> 
> * I can imagine an upstream server eventually deciding that it is being
> used in an amplification attack and just not responding any more.
> 
> 
> -- 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] [PATCH] auth-server without interface

2019-03-07 Thread Simon Kelley
On 15/02/2019 12:09, Petr Mensik wrote:
> Hi!
> 
> I was playing a bit with auth-vm and auth-server together with virtual
> machine manager. I think it might be useful to omit interface in
> auth-server at all, just change name reported by auth-vm zones on normal
> dns port.
> 
> Libvirt uses dnsmasq as DHCP and DNS server on each virtual network
> configured. It listens just on one interface excluding loopback (virbr0
> for example). If I specify its interface, it stops responding normal
> recursive queries on it. I think there is no good reason to demand it.
> Anyway, current manual page indicates it is optional...
> 
> Regards,
> Petr
> 

It was made optional in this commit.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=08933475abd0580cff747e3d1e0db3865207a200


Does that adddress the use-case you describe?


Cheers,

Simon.


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


Re: [Dnsmasq-discuss] Regarding dnslookup with dnsmasq 2.80 using dig command

2019-03-07 Thread Simon Kelley

There's not really enough information here to be sure, but I think this
may be fixed by


http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=162e5e0062ce923c494cc64282f293f0ed64fc10


Cheers,

Simon.




On 05/02/2019 08:18, Debananda Pal wrote:
> Hi,
> 
> I have updated dnsmasq from 2.79 to 2.80 in our application and using
> dig (DiG 9.12.3-P1) to retrieve record and am using below command :
> 
> Observation on Box 1:
> -
> # dig  localhost +noquestion +noauthority +noadditional +search +noedns
> There is no Answer I get 
> 
> # dig A localhost +noquestion +noauthority +noadditional +search +noedns
> Getting proper answer.
> 
> Observation on Box 2 (Same image of Box 1):
> -
> # dig  localhost +noquestion +noauthority +noadditional +search +noedns
> Getting proper answer.
> 
> # dig A localhost +noquestion +noauthority +noadditional +search +noedns
> There is no Answer I get  
>  
> I am getting proper response with dnsmasq 2.79 version with above command.
> 
> If I remove +search option (with dnsmasq 2.80 installed) I am getting
> proper response on both "A" and "".
> 
> Please let me know, if you have any suggestion.
> 
> Regards,
> D Pal
> 
> ___
> 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


Re: [Dnsmasq-discuss] Authoritative zone and no recursion replies

2019-03-07 Thread Simon Kelley
On 15/02/2019 12:54, Petr Mensik wrote:
> Hi everyone.
> 
> I think it is handy to be able to delegate some suffix from internal
> domain, lets say example.com provided by BIND or any bigger server. But
> recursive servers do not set recursive queries on normal delegation.
> Delegation is when I just add line into zone file:
> 
> $ORIGIN example.com.
> dnsmasq-private IN A 10.0.0.53
> private IN NS dnsmasq-private
> 
> Then query to xy.private.example.com would be forwarded to dnsmasq. It
> is great this can be configured by dynamic update of a zone. No change
> of configuration is necessary. It requires dnsmasq to be accessible by
> recursive resolvers. Great for trusted network configuration.
> 
> Unfortunately, dnsmasq does not cooperate very well with them. Recursive
> servers use queries without recursion desired flag set. Dnsmasq tends to
> refuse it or servfail if any forwarder is configured. For each host it
> reads from /etc/hosts or configured from DHCP, I think it would be nice
> to respond also without recursion to every host from hosts. The same way
> for DHCP assigned names. AFAIK it is denied to disallow cache probing.
> What is point to deny provided names without recursion set, when it
> gracefully offers it when recursion is desired?
> 
> compare when at least one server is set:
> dig +rec mydnsmasqhost
> dig +norec mydnsmasqhost
> 
> where mydnsmasqhost is hostname which obtained address from dnsmasq.
> 
> It just makes delegation from big resolvers difficult. Without auth-zone
> with common prefix, it would not work. Is there a good reason for it? If
> domain is set, it would be easy to create delegation without need to
> auth-zone set.
> 
> My example would work if --auth-zone=private.example.com would be used.
> While it is better, why should not --domain private.example.com be
> sufficient? It would be quite useful for VM configuration, because
> current libvirt does not support adding auth-zone to dnsmasq
> configuration file.
> 
> Any comments welcome.
> 
> Have a nice day,
> Petr
> 

The behaviour in receiving a query without RD set changed in

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4139298d287eb5c57f4aa53c459cb02fc5be2495

which doesn't directly help you, but does need to be taken into account.

If I understand you correctly, you want the behaviour to change if the
query can be answered from configured (/etc/hosts and so on) data,
whilst keeping the same behaviour for answers which came from upstream,
but are merely cached.

To answer the question "What is point to deny provided names without
recursion set, when it gracefully offers it when recursion is desired?"
The aim is to avoid a client being able to tell the difference between
an answer coming from the dnsmasq cache, and one coming from upstream.
If RD is set, it will get an answer, either from upstream, or from the
cache. It can't tell the difference. The original behaviour with RD
_unset_ was to either answer from the cache, or fail (not sending
upstream), allowing the client to deduce the contents of the cache. That
was changed to always SERVFAIL, and then the latest change is to always
forward upstream. The reason given for this is to allow dig +trace to
operate through dnsmasq.

It seems that actually just ignoring the RD bit i) disallows cache
snooping, ii) allows dig +trace to operate. Maybe that should be the
behaviour?


Simon.


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


Re: [Dnsmasq-discuss] Referring the PXE GUID / UUID in dhcp script

2019-03-05 Thread Simon Kelley
On 20/02/2019 06:38, 西谷優希 wrote:
> Hi,
> 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q1/003844.html
> As mentioned in this post, a PXE request contains a GUID / UUID value.
> Is there a way to refer this GUID / UUID in dhcp script?
> 
> I'd like to implement like below:
> 1. execute PXE Boot
> 2. send DHCP request to dhsmasq
> 3. hook dhcp-script which does:
>   - refer UUID of the client
>   - take the the client information from CMDB
>   - create pxelinux.cfg/ with the taken information(e.g. RAID
> type, kernel version)
> 4. send DHCP response to the host
> 5. booting goes on ...
> 
> Of course, it is possible to use the MAC address of NIC in place of
> UUID, but it can be changed by repair and replacement and the priority
> of UUID is higher than the MAC address of NIC for pxelinux.
> So it's great if GUID / UUID can be referred in dhcp script.
> 
> Thanks,
> nishitani yuki
> 
> ___

There are two problems with this idea.

1) The UUID is not supplied to the script (but that's easy to fix.)

2) The script execution is asynchronous. The DHCP protocol processing
doesn't wait for the script to execute, so you will have a big fat race
condition where the host may actually be booting before or after step 3
above has occurred.

Cheers,

Simon.


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


Re: [Dnsmasq-discuss] Configuring DHCPv6 Vendor specific information using Option 17

2019-03-04 Thread Simon Kelley
You need something like

--dhcp-option=vi-encap:47196,option6:100,\
"AOS-Switch:Top:Tokyo,3ffe:501::100::abcd,aruba123"


Check the vendor-specific option number. I got the value of 100 from the
data you provided, but I may have decoded it wrong.

Cheers,

Simon.


On 04/03/2019 10:01, P, Sreelakshmi wrote:
> Hi All,
> 
>  
> 
> How to we configure vendor specific information in dnsmasqv6 using
> option 17?
> 
>  
> 
> Every time I tried to configure option 17 as below :
> 
>  
> 
> dnsmasq
> --dhcp-option=option6:17,003db85c00640035414f532d5377697463683a546f703a546f6b3
> –test
> 
>  
> 
> I ended up getting the below error:
> 
>     dnsmasq: bad command line options: bad IPv6 address
> 
>  
> 
>  
> 
> What is the proper way to configure option 17 in dnsmasq? Below is my
> enterprise id and data:
> 
>  
> 
> Enterprise Id : *47196*
> 
> Data : *¸\d5AOS-Switch:Top:Tokyo,3ffe:501::100::abcd,aruba123*
> 
>  
> 
> If we try to configure the same value using other DHCPv6 servers, it
> works fine.
> 
> Any example? Can we configure the value as ASCII or HEX? Any help will
> be greatly appreciated.
> 
>  
> 
> Regards,
> 
> Sree
> 
>  
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] DNSSEC BOGUS still replied to with IP

2019-03-01 Thread Simon Kelley
On 01/03/2019 20:33, Simon Kelley wrote:

> 
> What's worrying is that Cloudflare and Google are both quite happy that
> the answer is _not_ bogus, but dnsmasq thinks it is. I shall poke around
> some more to try and understand that.
> 
> 
>

Answering myself, this appears to be a cloudflare bug, which I've seen
before. Sometimes the Cloudflare servers give a correct answer to a
query for a DS record at vp4.navy.mil with proof that such a record
doesn't exist.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +dnssec @1.0.0.1 DS vp4.navy.mil
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56156
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;vp4.navy.mil.  IN  DS

;; AUTHORITY SECTION:
navy.mil.   2149IN  SOA ns1.csd.disa.mil. 
hostmaster.navy.mil. 2019022501
7200 900 2592000 3600
navy.mil.   2149IN  RRSIG   SOA 8 2 7200 20190327183033 
20190225183033 3624
navy.mil. yXqgMb/KaKhAFD+nK/rOWxRA+e0SNcxFNMduE9JCOF9CLbmEEY79hH0/
aDHC6F+0R3AYRhk3FrZVrZcZTDnbNjHgX8VFI+ffYGJyQ1xL929Fr4pv
W+ZBnQlMyZ/XNHcOD23h/03YTP9ZBl40Ham+FdAFAxeHPGieWSzO/g4i mtw=
j8j5otdlg2trckk1ihstd584fjv5uh4n.navy.mil. 2429 IN NSEC3 1 0 10
32313032434343 J8UPVKMCB2UQO4TIS8VJACGU4JIFPAFI NS
j8j5otdlg2trckk1ihstd584fjv5uh4n.navy.mil. 2429 IN RRSIG NSEC3 8 3 3600
20190327183033 20190225183033 3624 navy.mil.
S+Y4RODqxYLEQML5+5qxUk2bp/opzKwinQMrlDufegat4ElU+Cby/tUG
Mbew4tYdZFMmMS3G6zGE2xA+zC0Doa3iTK4qYnQ2wHkqj08nwrCi1y3z
ruLw8GMowcAgtjc5NtkG+T94N2MiWFM64AqoNeFzGOcfrnUlDS4h1r9l TC4=

;; Query time: 103 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Fri Mar 01 20:46:33 GMT 2019
;; MSG SIZE  rcvd: 523


But then if you repeat exactly the same query and get back the same
answer, but without the required DNSSEC records as proof.


; <<>> DiG 9.10.3-P4-Ubuntu <<>> +dnssec @1.0.0.1 DS vp4.navy.mil
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59281
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;vp4.navy.mil.  IN  DS

;; AUTHORITY SECTION:
navy.mil.   3306IN  SOA ns1.csd.disa.mil. 
hostmaster.navy.mil. 2019022501
7200 900 2592000 3600

;; Query time: 173 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Fri Mar 01 20:46:35 GMT 2019
;; MSG SIZE  rcvd: 106


If dnsmasq gets the second form, it has no choice but to declare the
original answer bogus.

Running the DS query multiple times to both 1.1.1.1 and 1.0.0.1, the
answers seem to be pretty much randomly distributed between correct and
incorrect, with about 0.5 probability.  8.8.8.8 gets it right every time.

Doing the same thing with a DS query for thekelleys.org.uk, (as another
example of an unsigned subomain of a signed, NSEC3-using domain) gives
the correct answer all the time, so this looks like some interaction
between that particular domain and Cloudflare.

Simon.


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


Re: [Dnsmasq-discuss] DNSSEC BOGUS still replied to with IP

2019-03-01 Thread Simon Kelley
On 01/03/2019 18:56, Dominik DL6ER wrote:
> Dear list members,
> 
> to my understanding, dnsmasq should not return any valid records for BOGUS 
> domains.
> However, using Cloudflare (1.1.1.1 / 1.0.0.1) as upstream, I see a domains 
> being
> validated as BOGUS in the log, however, the A query still succeeds and the 
> client
> receives valid IP addresses. I'm using dnsmasq v2.80.
> 
> Corresponding log excerpt:
> 
> Mar  1 12:07:43 dnsmasq[28682]: query[A] www.vp4.navy.mil from 192.168.0.135
> Mar  1 12:07:43 dnsmasq[28682]: forwarded www.vp4.navy.mil to 1.0.0.1
> Mar  1 12:07:43 dnsmasq[28682]: dnssec-query[DS] mil to 1.0.0.1
> Mar  1 12:07:43 dnsmasq[28682]: reply mil is DS keytag 59896, algo 8, digest 2
> Mar  1 12:07:43 dnsmasq[28682]: reply mil is DS keytag 59896, algo 8, digest 1
> Mar  1 12:07:43 dnsmasq[28682]: dnssec-query[DS] navy.mil to 1.0.0.1
> Mar  1 12:07:43 dnsmasq[28682]: dnssec-query[DNSKEY] mil to 1.0.0.1
> Mar  1 12:07:43 dnsmasq[28682]: reply mil is DNSKEY keytag 59896, algo 8
> Mar  1 12:07:43 dnsmasq[28682]: reply mil is DNSKEY keytag 10428, algo 8
> Mar  1 12:07:43 dnsmasq[28682]: reply mil is DNSKEY keytag 15450, algo 8
> Mar  1 12:07:43 dnsmasq[28682]: reply navy.mil is DS keytag 33826, algo 8, 
> digest 2
> Mar  1 12:07:43 dnsmasq[28682]: reply navy.mil is DS keytag 33826, algo 8, 
> digest 1
> Mar  1 12:07:43 dnsmasq[28682]: dnssec-query[DS] vp4.navy.mil to 1.0.0.1
> Mar  1 12:07:43 dnsmasq[28682]: Insecure DS reply received, do upstream DNS 
> servers support DNSSEC?
> Mar  1 12:07:43 dnsmasq[28682]: reply vp4.navy.mil is BOGUS DS
> Mar  1 12:07:43 dnsmasq[28682]: validation www.vp4.navy.mil is BOGUS
> Mar  1 12:07:43 dnsmasq[28682]: reply www.vp4.navy.mil is 
> Mar  1 12:07:43 dnsmasq[28682]: reply 
> open-elb-prod-277276106.us-east-1.elb.amazonaws.com is 34.196.13.230
> Mar  1 12:07:43 dnsmasq[28682]: reply 
> open-elb-prod-277276106.us-east-1.elb.amazonaws.com is 52.0.22.76
> 
> Is this intended behavior?


Is the client actually getting the IP addresses, or are you assuming
that it is based on the log? I just ran the same query and got the same
logs, but the reply which went back to the client has a SERVFAIL return
code, and an empty answer section.


What is happening here is that 1.0.0.1 is returning a valid but unsigned
answer to the original query, which is being logged. (You can think of
the the "reply" noun is the logs as "reply from 1.0.0.1", not "reply to
192.168.0.135".) Dnsmasq fails to prove that an unsigned reply is OK,
and therefore labels it as bogus, and turns it into a SERVFAIL reply.

What's worrying is that Cloudflare and Google are both quite happy that
the answer is _not_ bogus, but dnsmasq thinks it is. I shall poke around
some more to try and understand that.


Simon.



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


Re: [Dnsmasq-discuss] [PATCH] lease: prune lease as soon as expired

2019-02-27 Thread Simon Kelley
Nice catch.

Patch applied.

Thanks for your work with that one.


Cheers,

Simon.



On 11/02/2019 16:04, Florent Fourcot wrote:
> We detected a performance issue on a dnsmasq running many dhcp sessions
> (more than 10 000). At the end of the day, the server was only releasing
> old DHCP leases but was consuming a lot of CPU.
> 
> It looks like curent dhcp pruning:
>  1) it's pruning old sessions (iterate on all current leases). It's
>  important to note that it's only pruning session expired since more
>  than one second
>  2) it's looking for next lease to expire (iterate on all current leases
>  again)
>  3) it launchs an alarm to catch next expiration found in step 2). This
>  value can be zero for leases just expired (but not pruned).
> 
> So, for a second, dnsmasq could fall in a "prune loop" by doing:
>  * Not pruning anything, since difftime() is not > 0
>  * Run alarm again with zero as argument
> 
> On a server with very large number of leases and releasing often
> sessions, that can waste a very big CPU time.
> 
> Signed-off-by: Florent Fourcot 
> ---
>  src/lease.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/lease.c b/src/lease.c
> index 97bee21..7299227 100644
> --- a/src/lease.c
> +++ b/src/lease.c
> @@ -563,7 +563,7 @@ void lease_prune(struct dhcp_lease *target, time_t now)
>for (lease = leases, up =  lease; lease = tmp)
>  {
>tmp = lease->next;
> -  if ((lease->expires != 0 && difftime(now, lease->expires) > 0) || 
> lease == target)
> +  if ((lease->expires != 0 && difftime(now, lease->expires) >= 0) || 
> lease == target)
>   {
> file_dirty = 1;
> if (lease->hostname)
> 


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


Re: [Dnsmasq-discuss] Is wrapping close() in retry_send() required ?

2019-02-27 Thread Simon Kelley
On 27/02/2019 15:06, Bogdan Harjoc wrote:
> There are 50 calls to close() in dnsmasq-2.80, and 10 of them are
> wrapped in retry_send().
> 
> "man close" has this paragraph in the section "Dealing with error
> returns from close":
> 
> "Retrying the close() after a failure return is the wrong thing to do,
> since this may cause a reused file descriptor from another thread to
> be closed. This can occur because the Linux kernel always releases the
> file descriptor early in the close operation, freeing it for reuse;
> the steps that may return an error, such as flushing data to the
> filesystem or device, occur only later in the close operation".
> 
> Dnsmasq is single-threaded so the retry_send() call is probably
> harmless. Are there other OSes that may return an error before the fd
> is released, in other words is there an OS where wrapping close in
> retry_send is required ?


Good questions.

Note that retry_send() only deals with EINTR return codes, ie
interrupted system calls. (Ok there are other return codes in there, but
nothing which might be returned by close())

So the use of retry_send(close(...)) is simply to restart the close()
syscall if a signal arrives during the syscall.


HOWEVER, whilst the man page for close() on my Linux machine states that
EINTR is a possible error return, man (7) signal does NOT include
close() in the set of syscalls which can be interrupted.

Clearly I was reading the close() man page when I used the wrapper, and
signal man page when I didn't :)


You're probably right that it doesn't matter, but it would be nice to
make this at least consistent.

Anyone know the answer?


Cheers,

Simon.


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


Re: [Dnsmasq-discuss] CNAME caching issue in Dnsmasq(2.76)

2019-01-21 Thread Simon Kelley


On 21/01/2019 07:33, Yossi Boaron wrote:

> 
> Is this dnsmasq limitation is just due to lack of support in code/bug? 
> or it requires massive architectural changes of dnsmasq?
> If it's the first one, I can try to fix this issue.
> 

It's the second, unfortunately. a DNS query can be answered from an
upstream source, or locally, but not by a mixture of both.

Simon.


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


Re: [Dnsmasq-discuss] 3 secs dhcp delay

2019-01-21 Thread Simon Kelley



On 21/01/2019 08:59, Harald Dunkel wrote:
> On 1/18/19 10:36 AM, Harald Dunkel wrote:
>>
>> Do you think dnsmasq could watch/ping its IP address range while it is
>> idle, caching the result? It might examine the local arp table as well:
>> If there is an entry with matching MAC and IP address, isn't it
>> reasonable
>> to assume that the IP address is not in use somewhere else?
>>
> 
> PS: I found https://tools.ietf.org/html/rfc5227 on the web. Interesting
> read, but probably it won't help to avoid the delay.

RFC5227 is an elaboration of the ARP-based method.

Using ARP probes works at the client, but it's never applicable for the
server, because the server may not be located in the same
broadcast-domain as the client(s). Using DHCP relay, the server can be
on another subnet entirely. This is why servers use ICMP for conflict
detection, as it's a routable protocol.


> 

Simon.


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


Re: [Dnsmasq-discuss] 3 secs dhcp delay

2019-01-21 Thread Simon Kelley



On 21/01/2019 11:49, Roy Marples wrote:

> 
>> Will dnsmasq offer another IP address in case it receives a decline?
> 
> It does with my testing, unless I hardcode the hardware address to a
> fixed IP. This results in an infinite loop, but there's no real way
> around that.


It's supposed to give up on the fixed IP, log a message and allocate a
pool IP instead under that circumstance. If you can repeat this I'd be
interested in the details, as it's a bug.


Cheers,


Simon.



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


Re: [Dnsmasq-discuss] CNAME caching issue in Dnsmasq(2.76)

2019-01-20 Thread Simon Kelley
It's a known limitation. The  actual limitation is that a CNAME and it's
target must both either originate from an upstream server, or both
originate from the dnsmasq local configuration. Mixing sources (ie CNAME
from upstream and target from dnsmasq, or vice-versa) is not allowed.

The commonest situation, when a CNAME is defined in dnsmasq's
configuration whose target comes from upstream, is noted a a problem in
the man page, but that doesn't mention what you're doing, defining the
CNAME upstream but the target in dnsmasq. It should probably do that.

Workaround is to add the CNAME to the dnsmasq configuration.

Cheers,

Simon.




On 20/01/2019 11:03, Yossi Boaron wrote:
> 
> Hi All,
> I have the following DNS topology (In my Openstack deployment):
> VM --> DNSMASQ --> external DNS server 
> domain name= shiftstack.com , and Dnsmasq 2.76
> is used at this Openstack deployment.
> 
> I run the following test:
> 1. Define CNAME record at external DNS server
> 
> ostest-etcd-5.shiftstack.com .   
>  IN   CNAME        ostest-master-2
> 
> 2. while 'ostest-master-2' is defined in --addn-hosts at Dnsmasq:
> the relevant entry:
> 10.0.1.214      ostest-master-2.shiftstack.com
> . ostest-master-2
> 
> 3. next step, I tried to resolve 'ostest-etcd-5.shiftstack.com
> .' from the VM.
> I expected that dig ostest-etcd-5.shiftstack.com
> . should be replied with the
> ostest-master-2 IP (10.0.1.214).
> 
> Actual behavior:
> When I run dig (see 1)  just for type A, Dnsmasq replied only with the
> CNAME entry and doesn't return ostest-master-2 IP address.
> 
> But when I run dig (see 2) for types  and A (at this order), I can
> see that Dnsmasq resolves  ostest-master-2 IP address as expected.
> 
> It seems to me like an issue of CNAME caching  at Dnsmasq (2.76), 
> Is it a known issue?
> 
> Thanks in advance
> Yossi
> 
> 
> [1] 
> $ dig +noedns  ostest-etcd-5.shiftstack.com
> .  A
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>>
> +noedns ostest-etcd-5.shiftstack.com
> . A
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13837
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;ostest-etcd-5.shiftstack.com . 
> IN      A
> 
> ;; ANSWER SECTION:
> ostest-etcd-5.shiftstack.com .
> 3600 IN   CNAME   ostest-master-2.shiftstack.com
> .
> 
> ;; Query time: 2 msec
> ;; SERVER: 10.0.0.2#53(10.0.0.2)
> ;; WHEN: Sun Jan 20 09:52:48 UTC 2019
> ;; MSG SIZE  rcvd: 118
> 
> $ 
> 
> [2] 
> $ dig +noedns ostest-etcd-5.shiftstack.com
> .
>   ostest-etcd-5.shiftstack.com
> .  A
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>>
> +noedns ostest-etcd-5.shiftstack.com
> .
>  ostest-etcd-5.shiftstack.com . A
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63573
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;ostest-etcd-5.shiftstack.com . 
> IN      
> 
> ;; ANSWER SECTION:
> ostest-etcd-5.shiftstack.com .
> 3600 IN   CNAME   ostest-master-2.shiftstack.com
> .
> 
> ;; Query time: 3 msec
> ;; SERVER: 10.0.0.2#53(10.0.0.2)
> ;; WHEN: Sun Jan 20 09:53:59 UTC 2019
> ;; MSG SIZE  rcvd: 118
> 
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15671
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;ostest-etcd-5.shiftstack.com . 
> IN      A
> 
> ;; ANSWER SECTION:
> ostest-etcd-5.shiftstack.com .
> 3600 IN   CNAME   ostest-master-2.shiftstack.com
> .
> ostest-master-2.shiftstack.com .
> 0 IN    A       10.0.1.214
> 
> ;; Query time: 0 msec
> ;; SERVER: 10.0.0.2#53(10.0.0.2)
> ;; WHEN: Sun Jan 20 09:53:59 UTC 2019
> ;; MSG SIZE  rcvd: 106
> 
> $ 
> 
> ___
> 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


Re: [Dnsmasq-discuss] [PATCH] Change read_leases() to skip invalid entries

2019-01-17 Thread Simon Kelley
Patch applied. Thanks.

Simon.

On 17/01/2019 20:50, Brian Haley wrote:
> There's no reason to stop reading the existing lease file
> when dnsmasq is started and an invalid entry is found, it
> can just be ignored.  This was fallout from an Openstack
> bug where the file was being written incorrectly with []
> around IPv6 addresses.

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


Re: [Dnsmasq-discuss] 3 secs dhcp delay

2019-01-17 Thread Simon Kelley


On 17/01/2019 10:30, Harald Dunkel wrote:
> Hi folks,
> 
> I see a 3 to 4 secs delay for dnsmasq's dhcp protocol. Example:
> 
> Strongswan's dhcp plugin obtains an IP address on behalf of the peer (a
> road warrior laptop). The strongswan logfile on the host says
> 
> :
> Jan 14 10:48:07 18[IKE]  peer requested virtual IP %any
> Jan 14 10:48:07 18[CFG]  sending DHCP DISCOVER to
> 172.16.122.9
> Jan 14 10:48:08 18[CFG]  sending DHCP DISCOVER to
> 172.16.122.9
> Jan 14 10:48:10 18[CFG]  sending DHCP DISCOVER to
> 172.16.122.9
> Jan 14 10:48:10 16[CFG] received DHCP OFFER 172.16.122.65 from 172.16.122.9
> Jan 14 10:48:10 18[CFG]  sending DHCP REQUEST for
> 172.16.122.65 to 172.16.122.9
> Jan 14 10:48:10 18[CFG]  sending DHCP REQUEST for
> 172.16.122.65 to 172.16.122.9
> Jan 14 10:48:10 18[CFG]  sending DHCP REQUEST for
> 172.16.122.65 to 172.16.122.9
> Jan 14 10:48:10 15[CFG] received DHCP ACK for 172.16.122.65
> Jan 14 10:48:10 18[IKE]  assigning virtual IP
> 172.16.122.65 to peer 'C=DE, ST=NRW, L=Metropolis, O=example AG,
> CN=roadwarrior.ac.example.de, E=secur...@example.de'
> :
> 
> dnsmasq's logfile contains this:
> 
> :
> Jan 14 10:48:00 dnsmasq-dhcp[10542]: 1657285313 available DHCP range:
> 172.16.122.10 -- 172.16.122.254
> Jan 14 10:48:00 dnsmasq-dhcp[10542]: 1657285313 DHCPRELEASE(eth1)
> 172.16.122.65 7a:a7:c5:fc:7d:59
> Jan 14 10:48:07 dnsmasq-dhcp[10542]: 2364812771 available DHCP range:
> 172.16.122.10 -- 172.16.122.254
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 DHCPDISCOVER(eth1)
> 7a:a7:c5:fc:7d:59
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 tags: eth1
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 DHCPOFFER(eth1)
> 172.16.122.65 7a:a7:c5:fc:7d:59
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 requested options:
> 6:dns-server, 44:netbios-ns
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 next server: 172.16.122.9
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  1 option: 53
> message-type  2
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 54
> server-identifier  172.16.122.9
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 51
> lease-time  12h
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 58
> T1  6h
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 59
> T2  10h30m
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option:  1
> netmask  255.255.255.0
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 28
> broadcast  172.16.122.255
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option:  6
> dns-server  172.16.122.9
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 available DHCP range:
> 172.16.122.10 -- 172.16.122.254
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 DHCPDISCOVER(eth1)
> 7a:a7:c5:fc:7d:59
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 tags: eth1
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 DHCPOFFER(eth1)
> 172.16.122.65 7a:a7:c5:fc:7d:59
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 requested options:
> 6:dns-server, 44:netbios-ns
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 next server: 172.16.122.9
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  1 option: 53
> message-type  2
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 54
> server-identifier  172.16.122.9
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 51
> lease-time  12h
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 58
> T1  6h
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 59
> T2  10h30m
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option:  1
> netmask  255.255.255.0
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 28
> broadcast  172.16.122.255
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option:  6
> dns-server  172.16.122.9
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 available DHCP range:
> 172.16.122.10 -- 172.16.122.254
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 DHCPDISCOVER(eth1)
> 7a:a7:c5:fc:7d:59
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 tags: eth1
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 DHCPOFFER(eth1)
> 172.16.122.65 7a:a7:c5:fc:7d:59
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 requested options:
> 6:dns-server, 44:netbios-ns
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 next server: 172.16.122.9
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  1 option: 53
> message-type  2
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 54
> server-identifier  172.16.122.9
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 51
> lease-time  12h
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 58
> T1  6h
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 2364812771 sent size:  4 option: 59
> T2  10h30m
> Jan 14 10:48:10 dnsmasq-dhcp[10542]: 

Re: [Dnsmasq-discuss] Fwd: [PATCH] fix entries in /etc/hosts disabling static leases

2019-01-17 Thread Simon Kelley
Patch applied, sorry for missing that in my review.

Cheers,

Simon.


On 15/01/2019 22:45, Steven Siloti wrote:
> On Tue, Jan 15, 2019 at 12:44 PM Kaas Baichtal  > wrote:
> 
> Hi,
> 
> I tried to install this patch manually to my 2.80 and got a segfault
> that
> prevented dnsmasq running. I also tried git cloning the master and
> installing that instead but got the same result. Any suggestions? I
> could
> really use this fix. Thank you.
> 
> --Kaas
> 
> Sorry about that, the attached patch should fix it.
> 
> ___
> 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


Re: [Dnsmasq-discuss] Issues with CentOS 7 dnsmasq, stops resolving queries.

2019-01-17 Thread Simon Kelley
Setting log-queries in the dnsmasq config will get you some useful
information.

Simon.


On 16/01/2019 21:26, elie...@ngtech.co.il wrote:
> Hey,
> 
> I have couple CentOS 7 hypervisors and VM's.
> On the hypervisors I do not have any issue with dnsmasq as DHCP server but I
> have not tried using it as a DNS.
> On once machine I have the latest CentOS 7 dnsmasq version (2.7x) and for
> some reason while 
> it run's queries against a local unbound server, it seems that it returns
> empty responses.
> When I am querying  the same unbound service from the same machine using
> tools like dig or host they answer fine.
> When I am querying the local dnsmasq it returns an empty response.
> How should I verify what might cause this issue?
> 
> Thanks,
> Eliezer
> 
> 
> Linux System Administrator
> Mobile: +972-5-28704261
> Email: mailto:elie...@ngtech.co.il
> 
> 
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] Solaris specific patches to fix build failures and improve performance

2019-01-17 Thread Simon Kelley



On 14/01/2019 15:56, libor.buk...@oracle.com wrote:
> Hello,
> 
> patches resolve the build failures, functionality, and performance
> issues on Solaris. A brief description is included in each patch.
> 
> Please let me know whether these patches could be merged and which
> changes are necessary.
> 

Very happy in principle to merge. After a quick look though, I have the
following observations.


Patch 0 - I think this may be out of date WRT the current code, which
removed the HAVE_IPV6 conditional compilation for IPv6 support.


Patch 1 - Looks fine. I wonder why I couldn't get SIOCSXARP
to work, as detailed in my comment?


Patch 2 - There is a Makefile included in the contrib/lease-tools
directory. I'd rather work on that than include it in the main Makefile.
This is a nasty , unsupported hack, and I'd really like OpenStack to use
the RemoveDhcpLease DBus method instead, but that's not your problem.
Happy to take conditional compilation patches or even a Solaris forked
version as another source file, but it all has to stay in contrib/

Patch 3 - Nasty, but Not My Problem. will take as is.

Patch 4 - This adds loads of conditional code in src/dnsmasq.c because
Linux deals in terms of interface names, and Solaris in interface
indexes. Much better to make whichdevice() and bindtodevice() return and
take struct irec *, then the Linux version can use the name from that,
and Solaris version the index. The only OS-specific code becomes
bindtodevice()


Cheers,

Simon.



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


Re: [Dnsmasq-discuss] IXFR requests and how they are handled

2019-01-17 Thread Simon Kelley
Dnsmasq returns an empty answer, which may not be correct, but is at
least an answer, so I'm not sure where the timeout is coming from.

>From RFC 1995

  If incremental zone transfer is not available, the entire zone is
   returned.  The first and the last RR of the response is the SOA
   record of the zone.  I.e. the behavior is the same as an AXFR
   response except the query type is IXFR.


So a simple answer would be to treat IXFR exactly the same as AXFR,
which should be trivial.


Cheers,

Simon.

On 15/01/2019 17:07, Wojtek Swiatek wrote:
> Hello
> 
> I was trying to use dnsmasq as a master with unbound as secondaries.
> After some debugging
> (https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4219), I realized
> that IXFR is not handled by dnsmasq (AXFR is - and works fine).
> It seems that the request just hangs and timeouts.
> 
> Would it be possible to appropriately respond to IXFR queries so that
> the requesting server knows to fallback to AXFR?
> I am trying at the same time to see whether the "timeout" case could not
> be gracefully handled as well on unbound side (they only handle rejection)
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] [PATCH] fix entries in /etc/hosts disabling static leases

2019-01-13 Thread Simon Kelley
Patch applied.


Cheers,

Simon.



On 12/01/2019 21:55, Steven Siloti wrote:
> It is possible for a config entry to have one address family specified by a
> dhcp-host directive and the other added from /etc/hosts. This is especially
> common on OpenWrt because it uses odhcpd for DHCPv6 and IPv6 leases are
> imported into dnsmasq via a hosts file.
> 
> To handle this case there need to be separate *_HOSTS flags for IPv4 and IPv6.
> Otherwise when the hosts file is reloaded it will clear the CONFIG_ADDR(6) 
> flag
> which was set by the dhcp-host directive.
> ---

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


Re: [Dnsmasq-discuss] Config Parcing Bug

2019-01-13 Thread Simon Kelley
The error is originating in the libidn2 library. Interestingly,
compiling against libidn1, that library doesn't flag the error.

Dnsmasq passes the input domain name to libidn[2] so that it can be
translated to punycode if it contains non-ascii characters.

I guess the authors of libidn2 would consider this valid behaviour if
you reported it as a bug.

A possible solution in this case would be to use the untranslated name
(maybe with a warning) if it fails the translation  call.


Cheers,

Simon.


On 12/01/2019 00:22, Tasnad Kernetzky wrote:
> Hi all,
> 
> I wanted to report a bug (at least we belieave it is one). We had a
> short discussion over at the archlinux bugtracker
> (https://bugs.archlinux.org/task/60366).
> 
> In short:
> 
>> echo 'address=/ab--c.example.com/#' | dnsmasq --test -C -
> 
>> dnsmasq: error at line 1 of stdin
> 
> Althoug the URL is "forbidden":
> 
>> host 'ab--c.example.com'
>> host: 'ab--c.example.com' is not a legal IDNA2008 name (string
> contains forbidden two hyphens pattern), use +noidnin
> 
> it would be nice to be able to block it. We ended up there, since the
> filter list from
> https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts started
> to include these kinds of URLs.
> 
> 
> My feeling is, that parsing the two dashes somehow fails. Interestingly,
> adding one more character before the dashes does not trigger the bug:
> 
>> echo 'address=/abb--c.example.com/#' | dnsmasq --test -C -
> 
>> dnsmasq: syntax check OK.
> 
> 
> Escaping (ab\-\-c.example.com) allows dnsmasq to start, but renders the
> line ineffective.
> 
> 
> Do you know about this and is it intended behaviour?
> 
> 
> Regards,
> 
> Tasnad
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Config Parcing Bug

2019-01-12 Thread Simon Kelley
Are you compiling dnsmasq with support for IDN?

dnsmasq -v will tell you.

Simon.


On 12/01/2019 00:22, Tasnad Kernetzky wrote:
> Hi all,
> 
> I wanted to report a bug (at least we belieave it is one). We had a
> short discussion over at the archlinux bugtracker
> (https://bugs.archlinux.org/task/60366).
> 
> In short:
> 
>> echo 'address=/ab--c.example.com/#' | dnsmasq --test -C -
> 
>> dnsmasq: error at line 1 of stdin
> 
> Althoug the URL is "forbidden":
> 
>> host 'ab--c.example.com'
>> host: 'ab--c.example.com' is not a legal IDNA2008 name (string
> contains forbidden two hyphens pattern), use +noidnin
> 
> it would be nice to be able to block it. We ended up there, since the
> filter list from
> https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts started
> to include these kinds of URLs.
> 
> 
> My feeling is, that parsing the two dashes somehow fails. Interestingly,
> adding one more character before the dashes does not trigger the bug:
> 
>> echo 'address=/abb--c.example.com/#' | dnsmasq --test -C -
> 
>> dnsmasq: syntax check OK.
> 
> 
> Escaping (ab\-\-c.example.com) allows dnsmasq to start, but renders the
> line ineffective.
> 
> 
> Do you know about this and is it intended behaviour?
> 
> 
> Regards,
> 
> Tasnad
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

2019-01-11 Thread Simon Kelley
Great. I'm distressed I didn't remember the issue until I ran "git
blame" over the code when putting together debugging instructions.

Cheers,

Simon.


On 11/01/2019 08:47, Sandeep K M wrote:
> Thanks a lot Simon, that did the trick.
> 
> The patch fixed the issue. I am able to see the reply messages being
> sent by server and the same being received by the client:
> 
> Jan 11 06:46:52 dnsmasq[4131]: started, version 2.78 DNS disabled
> Jan 11 06:46:52 dnsmasq[4131]: compile time options: IPv6 GNU-getopt
> no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth
> no-DNSSEC loop-detect inotify
> Jan 11 06:46:52 dnsmasq-dhcp[4131]: DHCPv6, IP range 2020::10 --
> 2020::20, lease time 1h
> Jan 11 06:47:47 dnsmasq-dhcp[4131]: DHCPSOLICIT(m1s1p1)
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 06:47:47 dnsmasq-dhcp[4131]: DHCPADVERTISE(m1s1p1) 2020::12
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 06:47:48 dnsmasq-dhcp[4131]: DHCPREQUEST(m1s1p1)
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 06:47:48 dnsmasq-dhcp[4131]: DHCPREPLY(m1s1p1) 2020::12
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 07:17:48 dnsmasq-dhcp[4131]: DHCPRENEW(m1s1p1)
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> Jan 11 07:17:48 dnsmasq-dhcp[4131]: DHCPREPLY(m1s1p1) 2020::12
> 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
> 
> Everything is working fine even the renew. Thanks again.
> 
> Thanks
> -Sandeep
> 
> On Fri, Jan 11, 2019 at 3:21 AM Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> Thanks for the offer. I think there may be a simpler answer, worth
> trying first.
> 
> Looking back through the git history, this looks like a bug introduced
> into 2.78 by the patches for security problems found by Google, in 2017.
> 
> It was fixed for 2.79, by  patch
> 
> 
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=499d8dde2b1a216eab9252ee500cc31b8c2b2974
> 
> So, first either move to 2.79 (or preferably 2.80) or apply that patch.
> 
> If that doesn't fix it, we'll go for debugging.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> On 10/01/2019 12:18, Sandeep K M wrote:
> > Hi Simon,
> >
> > Thanks again for the response.
> >
> > I will be happy to be your tester :)
> >
> > Its fairly a simple setup with two hosts and a switch. I can
> create this
> > any time you want.
> >
> > Please provide me the instructions. I am using dnsmasq version 2.78.
> >
> > Thanks
> > -Sandeep
> >
> > On Wed, Jan 9, 2019 at 10:33 PM Simon Kelley
> mailto:si...@thekelleys.org.uk>
> > <mailto:si...@thekelleys.org.uk <mailto:si...@thekelleys.org.uk>>>
> wrote:
> >
> >     On 04/01/2019 06:25, Sandeep K M wrote:
> >     > Hi Simon,
> >     >
> >     > Thanks a lot for your prompt reply.
> >     >
> >     > Attached are the packet captures:
> >     >
> >     > 1. Packets exchanged between client and relay
> (client-relay.pcap)
> >     > 2.  Packets exchanged between relay and server
> (relay-server.pcap)
> >     > 3. strace of dnsmasq (dnsmasq.trace)
> >     >
> >     > Please let me know if any other information is required.  
> >     >
> >     > I am not an expert in reading pcap's or strace but I do see
> in the
> >     > attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE"
> >     message is
> >     > being written to the same interface from which it received the
> >     > "DHCPSOLICIT" packet. But still it is fails to go out of that
> >     interface.
> >     >
> >     > 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14
> >     > 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73
> >     >
> >     > Any help on this would be greatly appreciated. Also is there any
> >     example
> >     > configuration of dnsmasq dhcpv6 working with relay ? Any
> reference
> >     would
> >     > be of great help.
> >     >
> >
> >     I'm sure this was tested with a relay, but the current test
> harnesses
> >     here would take some work to get into a position to test this
> code, so
> >     I'm going to try and use you as a tester, if that's OK?
> >
> >
> >     Looking at the strace 

Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

2019-01-10 Thread Simon Kelley
Thanks for the offer. I think there may be a simpler answer, worth
trying first.

Looking back through the git history, this looks like a bug introduced
into 2.78 by the patches for security problems found by Google, in 2017.

It was fixed for 2.79, by  patch


http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=499d8dde2b1a216eab9252ee500cc31b8c2b2974

So, first either move to 2.79 (or preferably 2.80) or apply that patch.

If that doesn't fix it, we'll go for debugging.


Cheers,

Simon.



On 10/01/2019 12:18, Sandeep K M wrote:
> Hi Simon,
> 
> Thanks again for the response.
> 
> I will be happy to be your tester :)
> 
> Its fairly a simple setup with two hosts and a switch. I can create this
> any time you want.
> 
> Please provide me the instructions. I am using dnsmasq version 2.78.
> 
> Thanks
> -Sandeep
> 
> On Wed, Jan 9, 2019 at 10:33 PM Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> On 04/01/2019 06:25, Sandeep K M wrote:
> > Hi Simon,
> >
> > Thanks a lot for your prompt reply.
> >
> > Attached are the packet captures:
> >
> > 1. Packets exchanged between client and relay (client-relay.pcap)
> > 2.  Packets exchanged between relay and server (relay-server.pcap)
> > 3. strace of dnsmasq (dnsmasq.trace)
> >
> > Please let me know if any other information is required.  
> >
> > I am not an expert in reading pcap's or strace but I do see in the
> > attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE"
> message is
> > being written to the same interface from which it received the
> > "DHCPSOLICIT" packet. But still it is fails to go out of that
> interface.
> >
> > 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14
> > 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73
> >
> > Any help on this would be greatly appreciated. Also is there any
> example
> > configuration of dnsmasq dhcpv6 working with relay ? Any reference
> would
> > be of great help.
> >
> 
> I'm sure this was tested with a relay, but the current test harnesses
> here would take some work to get into a position to test this code, so
> I'm going to try and use you as a tester, if that's OK?
> 
> 
> Looking at the strace output, dnsmasq logs that it's sending a
> DHCPADVERTISE reply, but it never calls sendto() to actually send the
> packet. This is definitely a dnsmasq bug, and not something in your
> network that's causing the packet to get lost: it never gets sent.
> 
> 
> What's confusing me is that manually tracing the code paths from what's
> known to be working (log the DHCPADVERTISE) to the sendto() call that
> should send that packet, I can't see any reason why the code should
> fail.
> 
> Are you in a position to run dnsmasq under gdb and step through the
> relevant code? I can give you detailed instructions on where to set
> breakpoints and where the reply packet could be getting lost. The path
> is maybe 50 lines.
> 
> Staring at the code has found me one bug, but it's not relevant in this
> case. (The code to avoid copying an RFC6939 link address option in a
> relay request to the reply to the relay actually sends a zero-length
> option, instead of eliding it entirely.)
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 

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


Re: [Dnsmasq-discuss] what do the contents of /var/lib/misc/dnsmasq.leases mean?

2019-01-09 Thread Simon Kelley
21,master-wap
> dhcp-host=,192.168.0.22,gaming-wap
> #
> # SUNROOM DEVICES
> dhcp-host=,192.168.0.30,printer
> dhcp-host=,192.168.0.31,laser
> #
> # DEN DEVICES
> dhcp-host=,192.168.0.253,watchdog
> #
> # MASTER DEVICES
> dhcp-host=,192.168.0.252,keeper,infinite
> dhcp-host=,192.168.0.40,wdtv,infinite
> dhcp-host=,192.168.0.148,kodi,infinite
> #
> # UTILITY DEVICES
> #
> # REC ROOM DEVICES
> #
> # WIRELESS DEVICES
> 
> #
> # OTHER SETTINGS
> #dhcp-ignore=tag:!known
> dhcp-lease-max=1000
> 
> long term, I'd like to static configure all devices on my home nic and
> my wireless and only to do dhcp on the vlan for guest wifi. Then I could
> uncomment the dhcp-ignore line and devices would need to be explicitly
> added to the conf to get access to anything on my LAN other than the
> internet. I feel like if I understood tags better I might be able to
> figure out how to do this. Otherwise I might need to see if I can get a
> PR into NetworkManager to use different conf-dirs when multiple networks
> are shared.
> 
> So probably more than you were asking for, but I hope it helps.
> 
> Go Carefully,
> 
> SeanK
> 
> 
> On Thu, Jan 3, 2019 at 12:20 PM Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> The leftmost 0 means that the leases are infinite, they never expire,
> which might explain why you're running out of leases.
> 
> There can be duplicate leases per MAC address, but there should never be
> duplicate leases for an IP address. So I'm interested in finding out how
> you've contrived this situation. Please could you share as much
> information as possible about network and dnsmasq configuration?
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> On 02/01/2019 04:01, Sean Kelly wrote:
> > when I cat the file I see mutiple entries for the same MAC
> address, what
> > does this mean?
> >
> > 0 98:de:d0:bb:11:0c 192.168.0.10 * 01:98:de:d0:bb:11:0c
> > 0 98:de:d0:bb:11:0c 192.168.0.10 * 01:98:de:d0:bb:11:0c
> > 0 98:de:d0:2c:0e:4c 192.168.0.20 * 01:98:de:d0:2c:0e:4c
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 44:80:eb:95:2a:b4 192.168.0.66 * 01:44:80:eb:95:2a:b4
> > 0 44:80:eb:95:2a:b4 192.168.0.66 miri-phone 01:44:80:eb:95:2a:b4
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> > 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> >  Can I trim multiple entriesor is it safe to ignore them? I just
> > recently got the dnsmasq NO LEASES LEFT error and was concerned that
> > these duplicate entries contributed to the dhcp-max-leases count.
> Can I
> > delete them safely?
> >
> > Go Carefully,
> >
> > SeanK
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> <mailto: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
> <mailto: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


Re: [Dnsmasq-discuss] android client does not check ip address with DHCPREQUEST

2019-01-09 Thread Simon Kelley
RFC1531 is twice obsoleted. The current definition of DHCP is RFC2131,
which says, in para 3.2.


  The client times out and retransmits the DHCPREQUEST message if
  the client receives neither a DHCPACK nor a DHCPNAK message.  The
  client retransmits the DHCPREQUEST according to the retransmission
  algorithm in section 4.1.  The client should choose to retransmit
  the DHCPREQUEST enough times to give adequate probability of
  contacting the server without causing the client (and the user of
  that client) to wait overly long before giving up; e.g., a client
  retransmitting as described in section 4.1 might retransmit the
  DHCPREQUEST message four times, for a total delay of 60 seconds,
  before restarting the initialization procedure.  If the client
  receives neither a DHCPACK or a DHCPNAK message after employing
  the retransmission algorithm, the client MAY choose to use the
  previously allocated network address and configuration parameters
  for the remainder of the unexpired lease.  This corresponds to
  moving to BOUND state in the client state transition diagram shown
  in figure 5.


If the Android client took out DHCP lease of length (say) one hour, it's
entitled to use that address for one hour, without ever talking to the
DHCP server again. By editing the lease database, you've misconfigured
dnsmasq and caused it to lease an address to another machine which it
has already leased to the Android phone. If you want to play such games,
you need to use short leases and include delays before reusing the address.


Cheers,

Simon.


On 09/01/2019 15:48, Inigo de la Fuente wrote:
> Hi All,
> 
>  
> 
> I have performed several test and already have opened one thread about
> this issue. I have seen unexpected behavior on android when DHCPv4
> client tries to reuse a previously allocated network address and this
> address is unavailable on the server.
> 
>  
> 
> The test steps are the following:
> 
>  1. Set the range of DHCP leases to only 1. Until now, DHCP can only
> lease one address.
>  2. Connect a device and get the only IPv4 address lease available then
> disconnect.
>  3. On the server dnsmasq leases file, replace the IPv4 lease and give
> the address to other machine.
>  4. Reconnect the device on point 1.
> 
>  
> 
> Basically on windows and IOS I can see that the first message on the
> DHCP client-server communication is a DHCPREQUEST sent by the client
> with the IPV4 address that wants to reuse. Then, the server respond with
> a DHCPNAK indicating the lease is not available anymore on the server.
> After that the client tries to get a new IPV4 but is not possible
> because no IPV4 range is available. (the only available address is
> assigned).
> 
> This is the correct behavior indicated on RFC1531
> 
>  
> 
> However, on Android the DHCPv4 client does not use DHCPREQUEST and then
> it reuses the address even when that address has been reassigned to
> other machine.
> 
>  
> 
> Did someone experience that?
> 
>  
> 
> Regards and thanks in advance
> 
>  
> 
> 
> 
>  Disclaimer 
> This email and any files transmitted may contain proprietary and
> confidential information of ICT Group N.V. or any of its subsidiaries
> (“ICT”) and is intended only for the (use of the) named recipient(s)
> above. If you have received this message in error or are not the
> intended or named recipient(s) of this message, please immediately
> notify the sender by return and delete this email message from your
> computer. Any views or opinions presented are solely those of its author
> and do not necessarily represent those of ICT. You are hereby notified
> that unauthorized disclosure, use, dissemination, forwarding, printing
> or copying of this e-mail and its attachments either whole or partial of
> its contents is strictly prohibited. ICT cannot guarantee that email
> communications are secured and error-free and does not accept any
> liability for damages resulting from the use of email. The general terms
> and conditions of purchase respectively sale and delivery of ICT are
> applicable to all transactions and undertakings resulting therefrom.
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

2019-01-09 Thread Simon Kelley
On 04/01/2019 06:25, Sandeep K M wrote:
> Hi Simon,
> 
> Thanks a lot for your prompt reply.
> 
> Attached are the packet captures:
> 
> 1. Packets exchanged between client and relay (client-relay.pcap)
> 2.  Packets exchanged between relay and server (relay-server.pcap)
> 3. strace of dnsmasq (dnsmasq.trace)
> 
> Please let me know if any other information is required.  
> 
> I am not an expert in reading pcap's or strace but I do see in the
> attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE" message is
> being written to the same interface from which it received the
> "DHCPSOLICIT" packet. But still it is fails to go out of that interface.
> 
> 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14
> 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73
> 
> Any help on this would be greatly appreciated. Also is there any example
> configuration of dnsmasq dhcpv6 working with relay ? Any reference would
> be of great help.
> 

I'm sure this was tested with a relay, but the current test harnesses
here would take some work to get into a position to test this code, so
I'm going to try and use you as a tester, if that's OK?


Looking at the strace output, dnsmasq logs that it's sending a
DHCPADVERTISE reply, but it never calls sendto() to actually send the
packet. This is definitely a dnsmasq bug, and not something in your
network that's causing the packet to get lost: it never gets sent.


What's confusing me is that manually tracing the code paths from what's
known to be working (log the DHCPADVERTISE) to the sendto() call that
should send that packet, I can't see any reason why the code should fail.

Are you in a position to run dnsmasq under gdb and step through the
relevant code? I can give you detailed instructions on where to set
breakpoints and where the reply packet could be getting lost. The path
is maybe 50 lines.

Staring at the code has found me one bug, but it's not relevant in this
case. (The code to avoid copying an RFC6939 link address option in a
relay request to the reply to the relay actually sends a zero-length
option, instead of eliding it entirely.)

Cheers,

Simon.





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


Re: [Dnsmasq-discuss] Patch to cache SRV records - updated version (#3)

2019-01-09 Thread Simon Kelley
Magic, thank you.

The fix, to a high level of confidence, is

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=a90f09db4cc635941a32b973b57e58c662569625

and the problem involved querying for a SRV record for

_bookmarkdavs._tcp.p48-bookmarks.icloud.com

which returns NXDOMAIN, as it should, but drops a little logic bomb into
the cache datastructures which will detonate some unpredictable time
later, when the cache entry is freed.

Any non-existing SRV record will have the same effect.



I've also seen a tight-loop problem in my testing, which I don't think
is this problem. There's another fix,

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=2896e2485e44c04e73a0b7c9f7cbc9c8515d0800

which I think fixes that, but I'm not 100% sure I can think myself from
the error to the tight loop, so I'm doing some more testing.


Thanks for your contribution with this, and please keep running the
development code. It really helps for people to do that.

Cheers,

Simon.


On 08/01/2019 23:51, Mufasa wrote:
> The requested core dump files have been sent.  I updated my CFLAGS to use -g 
> instead of -O2 and executed the ulimit command immediately before dnsmasq is 
> launched (same script) in the fresh container.
> 
> Because of the default behavior of Ubuntu’s Docker image, core dump files 
> were not being generated nor could I set the core dump output location to a 
> directory instead of the non-functional apport configuration default, so I 
> made these additional changes to my environment to generate the files:
> 
> "docker —run”, the command to launch the container,  got new parameters 
> "--privileged --ulimit core=-1” per recommendations I found on generating 
> core dumps in a container.  This was in addition to running the ulimit 
> command in the shell script I start dnsmasq from.
> 
> The launch script now does this to set the core dump location:
> echo '/tmp/core.%h.%e.%t' > /proc/sys/kernel/core_pattern
> 
> -Daniel
> 
>> On Jan 8, 2019, at 3:14 AM, Simon Kelley  wrote:
>>
>> Thanks for the feedback, and for tracking the bleeding-edge code. The
>> following should help get useful information.
>>
>> 1) Replace -O2 with -g in your compilation flags
>> 2) run the command "ulimit -c unlimited" from the shell you start
>> dnsmasq from.
>>
>> When it goes bang, send me the core dump and the dnsmasq binary.
>>
> 
> ___
> 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


Re: [Dnsmasq-discuss] Patch to cache SRV records - updated version (#3)

2019-01-08 Thread Simon Kelley


On 08/01/2019 03:46, Mufasa wrote:
> On 01/07/2019 08:32 AM, Simon Kelley wrote:
>>/I've worked through the patch, and been inspired to clean up a few 
>>/>/long-standing nasty bits. This has the consequence that the mechanisms 
>>/>/which were added to enable storage of DNSKEY and DS RRtypes during the 
>>/>/the DNSSEC campaign are now much more general, and I've used them to 
>>/>/implement SRV caching. The new code is therefore all mine, as are any 
>>/>/bugs, but the net effect is the same as Jeremy's (I hope). />//>//>/I 
>>didn't implement a config switch to disable caching of SRV records, 
>>/>/because I can't conceive of a situation where such would be necessary. 
>>/>//>//>/Code is in the git repo now, and we're eating the new dog food here. 
>>/>/Please test away./
> 
> New to the list but just wanted to report my experience with the “new
> dog food”.
> 
> I use dnsmasq in Docker and have a script that will fully build my
> configuration from the official Ubuntu docker image and the dnsmasq git
> repository HEAD.  Its been working well for almost a year now.  I only
> once had to rollback a commit when it broke compilation and after some
> waiting, a new commit fixed the issue.
> 
> After updating to commit 5b99eae59d59a8e34a7e512059b98bbd803312f2 today,
> I’m finding that it dies with a "Segmentation fault (core dumped)" in
> about 30 minutes or less.
> 
> I compile it with CFLAGS='-Wall -W -O2 -DNO_IPV6 and launch it with
> /usr/local/sbin/dnsmasq -d --log-facility=/var/log/dnsmasq.log
> 
> If you have any advice on capturing more information about the segfault,
> let me know.
> 

Thanks for the feedback, and for tracking the bleeding-edge code. The
following should help get useful information.

1) Replace -O2 with -g in your compilation flags
2) run the command "ulimit -c unlimited" from the shell you start
dnsmasq from.

When it goes bang, send me the core dump and the dnsmasq binary.


Cheers,

Simon.

> -Daniel
> 
> ___
> 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


Re: [Dnsmasq-discuss] Patch to cache SRV records - updated version (#3)

2019-01-07 Thread Simon Kelley
I've worked through the patch, and been inspired to clean up a few
long-standing nasty bits. This has the consequence that the mechanisms
which were added to enable storage of DNSKEY and DS RRtypes during the
the DNSSEC campaign are now much more general, and I've used them to
implement SRV caching. The new code is therefore all mine, as are any
bugs, but the net effect is the same as Jeremy's (I hope).


I didn't implement a config switch to disable caching of SRV records,
because I can't conceive of a situation where such would be necessary.


Code is in the git repo now, and we're eating the new dog food here.
Please test away.


Cheers,

Simon.



On 20/12/2018 23:20, Jeremy Allison wrote:
> On 12/20/2018 03:11 PM, Simon Kelley wrote:
>> This is worth having for the removal of the archaic 16-bit limit on the
>> flags field in a cache record alone. I've been meaning to tackle that
>> for some time.
>>
>> This time of year either frees up lots of time for coding, or yields
>> none at all, and for me it's the later, but I will go through this and
>> merge it in the new year.
> 
> Oh thanks for the comments. I'm currently running this version
> under valgrind (with a minor test hack to force negative
> SRV records to explitly expire after 60 seconds to ensure
> I'm going through the cache expire code paths) and it seems
> robust so far.
> 
> There are some people in the ChromeOS Teams also looking
> at this, although as it's holiday time here in the US it
> might not get fully examined until Jan. If anyone finds
> any more errors with it under test I'll let you know
> and update it.
> 
> Cheers & thanks and Merry Christmas / Happy Holidays !
> 
> Jeremy.
> 




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

2019-01-03 Thread Simon Kelley
It would be useful to get full packet dumps rather than just tcpdump
output.

It would also be useful to run dnsmasq under strace and see what
syscalls it's making: that would tell use where the reply might be going.


Cheers,

Simon.




On 03/01/2019 07:41, Sandeep K M wrote:
> Hi All,
> 
>  
> 
> I have a simple setup with a relay agent as shown below:
> 
> 
> +--+-+
> |    dnsmasq server |
> 
> |     (ubuntu) |
> 
> +-+
>     | m1s1p7 (1040::2/120)
>             | (IP route : 2020::/120 via 1040::1 dev m1s1p7  proto
> static  metric 512  pref medium)
>             |
>     |
>     | 1/1/2 (1040::1/120)
> +--++
> |    Switch    |
> | (Relay Agent )  |
> +---+
>     | 1/1/1 (2020::1/120) 
>         |
>     | 
>     | eth1 
> +--+--+
> | Client (Ubuntu)  |
> +--+
> 
> 
> It is exactly the same as explained in the video :
> https://www.youtube.com/watch?v=2Lt1aXpCzvQ
> 
> 
> Whenever the client is requesting an IPv6 address dnsmasq is failing to
> respond with “DHCPADVERTISE” message. The “DHCPADVERTISE” has not been
> sent via the interface. The tcpdump clearly shows that “DHCPADVERTISE”
> message has not gone through the interface (m1s1p7), its only showing
> the “DHCPSOLICIT” message which has been received:
> 
>  
> 
> /root@8320:~# tcpdump -i *m1s1p7* udp port 547 or 546 -vvv -n/
> 
> //
> 
> /tcpdump: listening on m1s1p7, link-type EN10MB (Ethernet), capture size
> 262144 bytes/
> 
> //
> 
> / /
> 
> //
> 
> /06:32:37.214798 IP6 (hlim 64, next-header UDP (17) payload length: 110)
> 2020::1.547 > 1040::2.547: [udp sum ok] dhcp6 relay-fwd
> (linkaddr=2020::1 peeraddr=fe80::250:56ff:febd:7c93 (relay-message
> (*dhcp6 solicit* (xid=1894f2 (client-ID hwaddr/time type 1 time
> 599811159 005056bd7c93) (option-request DNS-server DNS-search-list
> Client-FQDN SNTP-servers) (elapsed-time 0) (IA_NA IAID:1455258771
> T1:3600 T2:5400))) (interface-ID 0024...))/
> 
>  
> 
> But the dnsmasq logs shows that it is trying to send the “DHCPADVERTISE”
> message but for some reason it’s not been sent via the interface *m1s1p7. *
> 
> * *
> 
> **
> 
> /root@8320:~# tail -f /var/log/dnsmasq_swns/dnsmasq6.log/
> 
> //
> 
> /Jan  3 06:11:20 dnsmasq[4151]: started, version 2.78 DNS disabled/
> 
> //
> 
> /Jan  3 06:11:20 dnsmasq[4151]: compile time options: IPv6 GNU-getopt
> no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth
> no-DNSSEC loop-detect inotify/
> 
> /Jan  3 06:11:20 dnsmasq-dhcp[4151]: DHCPv6, IP range 2020::10 --
> 2020::20, lease time 1h/
> 
> /Jan  3 06:12:38 dnsmasq-dhcp[4151]: DHCPSOLICIT(m1s1p7)
> 00:01:00:01:23:c0:64:57:00:50:56:bd:7c:93/
> 
> //
> 
> /Jan  3 06:12:38 dnsmasq-dhcp[4151]: DHCPADVERTISE(m1s1p7) 2020::12
> 00:01:00:01:23:c0:64:57:00:50:56:bd:7c:93/
> 
>  
> 
> *Does anyone has any clue on what is going on here ? Am I missing
> something ? Here is my dnsmasq config file contents:*
> 
>  
> 
> /root@8320:~# cat /var/run/dnsmasq_swns/dnsmasq6.conf/
> 
> //
> 
> /enable-ra/
> 
> //
> 
> /log-dhcp/
> 
> //
> 
> /log-queries/
> 
> //
> 
> /log-facility=/var/log/dnsmasq_swns/dnsmasq6.log/
> 
> //
> 
> /port=0/
> 
> //
> 
> /dhcp-script=/usr/bin/dhcp_server_leases/
> 
> //
> 
> /leasefile-ro/
> 
> //
> 
> /dhcp-lease-max=64000/
> 
> //
> 
> /dhcp-range=set:default+test,2020::10,2020::20,120/
> 
>  
> 
> Thanks
> 
> -Sandeep
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] [PATCH] Fix typo in ra-param man page section

2019-01-03 Thread Simon Kelley
Prodding me is fine, and has done the trick here.

In general, I'm way behind my inbox, and struggling to catch up. Moving
house is not helping :(

I will try and get to everything in the end, but I won't be offended is
people remind me.

Cheers,

Simon.


On 03/01/2019 05:49, Christian Weiske wrote:
> Hello,
> 
> 
>>  man/dnsmasq.8| 2 +-
>>  man/fr/dnsmasq.8 | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git man/dnsmasq.8 man/dnsmasq.8
> 
> Is there anything I can do to get this patch merged?
> 

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


Re: [Dnsmasq-discuss] what do the contents of /var/lib/misc/dnsmasq.leases mean?

2019-01-03 Thread Simon Kelley
The leftmost 0 means that the leases are infinite, they never expire,
which might explain why you're running out of leases.

There can be duplicate leases per MAC address, but there should never be
duplicate leases for an IP address. So I'm interested in finding out how
you've contrived this situation. Please could you share as much
information as possible about network and dnsmasq configuration?


Cheers,

Simon.


On 02/01/2019 04:01, Sean Kelly wrote:
> when I cat the file I see mutiple entries for the same MAC address, what
> does this mean?
> 
> 0 98:de:d0:bb:11:0c 192.168.0.10 * 01:98:de:d0:bb:11:0c
> 0 98:de:d0:bb:11:0c 192.168.0.10 * 01:98:de:d0:bb:11:0c
> 0 98:de:d0:2c:0e:4c 192.168.0.20 * 01:98:de:d0:2c:0e:4c
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 44:80:eb:95:2a:b4 192.168.0.66 * 01:44:80:eb:95:2a:b4
> 0 44:80:eb:95:2a:b4 192.168.0.66 miri-phone 01:44:80:eb:95:2a:b4
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:90:a9:6a:0b:92 192.168.0.40 * 01:00:90:a9:6a:0b:92
> 0 00:1a:62:01:17:cf 192.168.0.252 * 01:00:1a:62:01:17:cf
>  Can I trim multiple entriesor is it safe to ignore them? I just
> recently got the dnsmasq NO LEASES LEFT error and was concerned that
> these duplicate entries contributed to the dhcp-max-leases count. Can I
> delete them safely?
> 
> Go Carefully,
> 
> SeanK
> 
> ___
> 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


Re: [Dnsmasq-discuss] DHCP offers are not accepted

2018-12-31 Thread Simon Kelley
My guess is that the config file has a subtle syntax error, which means
that you're not actually configuring for infinite leases, but maybe
zero-length ones. Dnsmasq applies a floor of two minutes on leases, the
repeated renewals might indicate that is too short.

When dnsmasq starts, it logs the lease time for each DHCP address range.
Could you see what it's saying?


Cheers,

Simon.



On 31/12/2018 20:44, Marc Elbirt wrote:
> ## Expected Behaviour:
> DHCP offers should be accepted by any client
> 
> ## Actual Behaviour:
> Clients repeatedly ask for DHCP addresses, every 3 seconds, overwhelming
> pi-hole and slowing all responses (including DNS). Some client devices
> (iPhone 7) can be observed to temporarily acquire an address, and then
> drop it moments later.
> 
> ## Debug Token:
> eepv3gugqb
> 
> ## Versions:
> Dnsmasq version 2.76  Copyright (c) 2000-2016 Simon Kelley
> FTL Version v4.1.2
> Linux pi-hole 4.14.79+ #1159 Sun Nov 4 17:28:08 GMT 2018 armv6l GNU/Linux
> Raspbian GNU/Linux 9 (stretch)
> 
> ## Config notes:
> pi-hole is configured for DNS and DHCP, on subnet 192.168.2.1/24
> <http://192.168.2.1/24>. It is configured to grant infinite leases to
> any, in the range 192.168.2.129 to 192.168.2.223, and most devices
> (including the ones below) have been allocated static leases in the
> space below this range.
> 
> ## Example:
> Dec 28 08:35:18 dnsmasq-dhcp[882]: DHCPDISCOVER(wlan0) 44:61:32:xx:xx:xx 
> Dec 28 08:35:18 dnsmasq-dhcp[882]: DHCPOFFER(wlan0) 192.168.2.26
> 44:61:32:xx:xx:xx 
> Dec 28 08:35:18 dnsmasq-dhcp[882]: DHCPREQUEST(wlan0) 192.168.2.26
> 44:61:32:xx:xx:xx 
> Dec 28 08:35:18 dnsmasq-dhcp[882]: DHCPACK(wlan0) 192.168.2.26
> 44:61:32:xx:xx:xx ecobee3
> Dec 28 08:35:21 dnsmasq-dhcp[882]: DHCPREQUEST(wlan0) 192.168.2.26
> 44:61:32:xx:xx:xx 
> Dec 28 08:35:21 dnsmasq-dhcp[882]: DHCPACK(wlan0) 192.168.2.26
> 44:61:32:xx:xx:xx ecobee3
> ...
> Dec 28 08:36:23 dnsmasq-dhcp[882]: DHCPREQUEST(wlan0) 192.168.2.58
> 68:c6:3a:xx:xx:xx 
> Dec 28 08:36:23 dnsmasq-dhcp[882]: DHCPACK(wlan0) 192.168.2.58
> 68:c6:3a:xx:xx:xx PurpleAir_751
> Dec 28 08:36:26 dnsmasq-dhcp[882]: DHCPREQUEST(wlan0) 192.168.2.58
> 68:c6:3a:xx:xx:xx 
> Dec 28 08:36:26 dnsmasq-dhcp[882]: DHCPACK(wlan0) 192.168.2.58
> 68:c6:3a:xx:xx:xx PurpleAir_751
> Dec 28 08:36:28 dnsmasq-dhcp[882]: DHCPREQUEST(wlan0) 192.168.2.58
> 68:c6:3a:xx:xx:xx 
> Dec 28 08:36:28 dnsmasq-dhcp[882]: DHCPACK(wlan0) 192.168.2.58
> 68:c6:3a:xx:xx:xx PurpleAir_751
> 
> ## Notes:
> Testing with nmap reveals unexpected behavior, where lease time is set
> to the minimum dnsmasq time (2 mins):
> Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-28 08:12 PST
> Pre-scan script results:
> | broadcast-dhcp-discover: 
> |   Response 1 of 1: 
> |     IP Offered: 192.168.2.148
> |     DHCP Message Type: DHCPOFFER
> |     Server Identifier: 192.168.2.10
> |     IP Address Lease Time: 2m00s
> |     Renewal Time Value: 1m00s
> |     Rebinding Time Value: 1m45s
> |     Subnet Mask: 255.255.255.0
> |     Broadcast Address: 192.168.2.255
> |     Domain Name Server: 192.168.2.10
> |     Domain Name: 
> |_    Router: 192.168.2.1
> WARNING: No targets were specified, so 0 hosts scanned.
> Nmap done: 0 IP addresses (0 hosts up) scanned in 4.23 seconds
> 
> ___
> 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


Re: [Dnsmasq-discuss] Constant DHCPOFFER and DISCOVER in logs

2018-12-31 Thread Simon Kelley
On 31/12/2018 21:39, Jon Anderson wrote:
> Hello all,
> 
> I wanted to setup a PiHole for blocking ads and for the ability to
> modify DNS settings network-wide. I have just switched my ISP to AT
> fiber where we are required to use a supplied modem/router (ARRIS
> BGW210-700) which does not allow setting DNS servers manually. I was
> happy to find out that I could get around this by moving DHCP services
> to PiHole. I disabled the DHCP on the ARRIS and enabled the service on
> the PiHole. And now every device is using the PiHole for DNS with an
> upstream DNS from Cloudflare instead of AT’s slow DNS.
> Everything is working fine.
> When I look at the pihole-log though, I see pages and pages of this:
> 
> Dec 30 05:47:09 dnsmasq-dhcp[598]: DHCPOFFER(eth0) 192.168.1.102
> 88:96:4e:xx:xx:xx
> Dec 30 05:47:10 dnsmasq-dhcp[598]: DHCPDISCOVER(eth0) 88:96:4e:xx:xx:xx
> Dec 30 05:47:10 dnsmasq-dhcp[598]: DHCPOFFER(eth0) 192.168.1.102
> 88:96:4e:xx:xx:xx
> Dec 30 05:47:10 dnsmasq-dhcp[598]: DHCPDISCOVER(eth0) 88:96:4e:xx:xx:xx
> 
> Always the same IP. Always the same MAC address. Always between 1 and 3
> seconds apart.
> I never get anything other than OFFER and DISCOVER. It looks similar to
> the problems
> in 
> https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg03282.html
> and 
> https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg00849.html.
> It does not seem to be the same problem reported by Marc Elbirt only a
> few moments ago, though there are some similarities.
> 
> I did some digging about MAC addresses and found that the MAC address
> can tell you about the manufacturer of the device. I discovered that
> 88:96:4e corresponds to ARRIS. I checked the modem/router on it’s status
> page and found that the MAC addresses for the 2.4Ghz AP, the Guest
> network AP, and the 5Ghz AP are all very similar to the MAC address that
> seems to be having problems.
> So this seems pretty conclusive that the device that will not accept
> it’s IP address is part of the modem/router, but I’m not sure what it is
> or how to get it to accept the 192.168.1.102 or stop requesting an IP
> altogether.
> 

That looks like a client bug: it should at least do exponential back-off.


You could try using dhcp-mac and dhcp-ignore to configure dnsmasq to
just ignore requests from the offending MAc address.

Cheers,

Simon


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


Re: [Dnsmasq-discuss] DNSMASQ is offering the declined address repeatedly to the station in Sequential IP mode

2018-12-31 Thread Simon Kelley
I just pushed a fix which should solve this:



http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=e7bfd556c079c8b5e7425aed44abc35925b24043



Cheers,

Simon.


On 21/12/2018 14:48, Jangala Anvesh wrote:
> Hi,
> 
> Problem Statement :
> DNSMASQ is offering the declined address repeatedly to the station in
> Sequential IP mode.
> 
> DNSMASQ details and configuration :
> DNSMASQ version 2.78.
> 
> Mode - dhcp-sequential-ip
> dhcp-range=lan,192.168.86.20,192.168.86.250,24h
> 
> Im seeing the following messages:
> 
> 2018-08-07T03:01:37.750559+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDISCOVER(lan) 784f4331e43a
> 2018-08-07T03:01:37.750725+00:00 INFO dnsmasq-dhcp[1177]: DHCPOFFER(lan)
> 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:37.751702+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDISCOVER(lan) 784f4331e43a
> 2018-08-07T03:01:37.751872+00:00 INFO dnsmasq-dhcp[1177]: DHCPOFFER(lan)
> 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:38.815690+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPREQUEST(lan) 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:38.815896+00:00 INFO dnsmasq-dhcp[1177]: DHCPACK(lan)
> 192.168.86.21 784f4331e43a macbookpro2
> 2018-08-07T03:01:40.659116+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDECLINE(lan) 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:52.487506+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDISCOVER(lan) 784f4331e43a
> 2018-08-07T03:01:52.487672+00:00 INFO dnsmasq-dhcp[1177]: DHCPOFFER(lan)
> 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:53.557920+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPREQUEST(lan) 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:53.558117+00:00 INFO dnsmasq-dhcp[1177]: DHCPACK(lan)
> 192.168.86.21 784f4331e43a macbookpro2
> 2018-08-07T03:01:56.147878+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDECLINE(lan) 192.168.86.21 784f4331e43a
> 
> 
> We are expecting a behaviour like:
> 
> Whenever the dnsmasq receives a DHCPDELCINE message from the station and
> the station tries to connect again DNSMASQ should offer the next free
> address from the pool, but from the above sequene it is offering the
> same address.
> 
> Current Behaviour :
> 
> As per the current implementation of DNSMASQ, found out that, whenever
> DNSMASQ receives a DHCP-DECLINE message it will increment a counter.
> When offering an IP address to a client, DNSMASQ fetches the largest
> assigned address and from that address onwards it will try to allocate
> the next free address. In the process of allocating an address to a
> client, DNSMASQ will perform a PING check on the offering address and
> based on the PING result it will offer the address to the client (if
> PING fails) or it will check for the next address in the pool (when PING
> is successful).
> 
> If there are stations configured statically in the LAN network which
> blocks ICMP ECHO REQUEST and if DNSMASQ offers the same IP address(as
> PING fails) to the requesting station it will be declined. However
> DNSMASQ is not offering different IP to the station which has declined
> the IP when it tries to connect again.
> Also, if the PING reply didn't reach the DNSMASQ within the timeout,
> DNSMASQ is still trying to offer the same IP address(means declined
> address) to the clients.
> 
> Proposed alternatives:
> 
> In order to overcome this issue, we are planning to have an ARPing
> implementation along with the existing PING check in dnsmasq.
> We came across a link
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2006q3/000846.html 
> which
> discusses about the ARPing implementation.
> With the above approach, DNSMASQ will perform a ARP resolution before
> offering an address. If the ARP resolution is not successful, DNSMASQ
> will proceed to allocate the address,else DNSMASQ will try to offer the
> next free address in the pool.
> 
> 
> Please look into this issue and ARPing approach as a resoution for the
> same. If there are any other alternatives to resolve this issue please
> suggest.
> 
> Regards,
> Anvesh.
> 
> Disclaimer:This message is intended only for the designated
> recipient(s). It may contain confidential or proprietary information and
> may be subject to other confidentiality protections. If you are not a
> designated recipient, you may not review, copy or distribute this
> message. Please notify the sender by e-mail and delete this message.
> GlobalEdge does not accept any liability for virus infected mails.


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


Re: [Dnsmasq-discuss] dnsmasq crash - no core dump generated

2018-12-28 Thread Simon Kelley
This code is relevant, in src/dnsmasq.c


  if (option_bool(OPT_DEBUG))
prctl(PR_SET_DUMPABLE, 1, 0, 0, 0);



Cheers,

Simon.

On 28/12/2018 03:40, Arvind Nagarajan wrote:
> Hi All,
> 
> When dnsmasq crashes due to segfault (SIGSEGV) I am not getting a core
> file generated.
> Is this expected?
> dnsmasq is managed by systemd and started using
> systemctl start dnsmasq.
> The dnsmasq service file starts dnsmasq with '-k' option - keep in
> foreground mode.
> 
> Howerver If I run the dnsmasq in debug mode using '-d' mode the core
> dump is getting generated.
> 
> Do I need to add any signal handling code/any config knob to generate
> core dump in -k' mode.
> Any pointers regarding this will be helpful.
> 
> Thanks,
> Arvind
> 
> ___
> 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


Re: [Dnsmasq-discuss] DNSMASQ is offering the declined address repeatedly to the station in Sequential IP mode

2018-12-23 Thread Simon Kelley
The best solution to this is to stop blocking ICMP.

The simplest solution is not to use dhcp-sequential-ip. The normal
address-allocation process in DHCP perturbs the hash function when a
DECLINE reply is received, so the next allocation will be to a different
address.

Using ARP probing from the server is not a good fix, because is fails
when DHCP relay is in use and the server is on a different network to
the client. That's why ICMP is used by the server - it needs to be a
routable protocol.

If you can't use either of the the solutions above, then you'll need to
implement some sort of time-limited blacklisting of the declined
addresses, rather in the same which is done to disable static address
allocations which get declined.


Cheers,

Simon.




On 21/12/2018 14:48, Jangala Anvesh wrote:
> Hi,
> 
> Problem Statement :
> DNSMASQ is offering the declined address repeatedly to the station in
> Sequential IP mode.
> 
> DNSMASQ details and configuration :
> DNSMASQ version 2.78.
> 
> Mode - dhcp-sequential-ip
> dhcp-range=lan,192.168.86.20,192.168.86.250,24h
> 
> Im seeing the following messages:
> 
> 2018-08-07T03:01:37.750559+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDISCOVER(lan) 784f4331e43a
> 2018-08-07T03:01:37.750725+00:00 INFO dnsmasq-dhcp[1177]: DHCPOFFER(lan)
> 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:37.751702+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDISCOVER(lan) 784f4331e43a
> 2018-08-07T03:01:37.751872+00:00 INFO dnsmasq-dhcp[1177]: DHCPOFFER(lan)
> 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:38.815690+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPREQUEST(lan) 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:38.815896+00:00 INFO dnsmasq-dhcp[1177]: DHCPACK(lan)
> 192.168.86.21 784f4331e43a macbookpro2
> 2018-08-07T03:01:40.659116+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDECLINE(lan) 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:52.487506+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDISCOVER(lan) 784f4331e43a
> 2018-08-07T03:01:52.487672+00:00 INFO dnsmasq-dhcp[1177]: DHCPOFFER(lan)
> 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:53.557920+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPREQUEST(lan) 192.168.86.21 784f4331e43a
> 2018-08-07T03:01:53.558117+00:00 INFO dnsmasq-dhcp[1177]: DHCPACK(lan)
> 192.168.86.21 784f4331e43a macbookpro2
> 2018-08-07T03:01:56.147878+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDECLINE(lan) 192.168.86.21 784f4331e43a
> 
> 
> We are expecting a behaviour like:
> 
> Whenever the dnsmasq receives a DHCPDELCINE message from the station and
> the station tries to connect again DNSMASQ should offer the next free
> address from the pool, but from the above sequene it is offering the
> same address.
> 
> Current Behaviour :
> 
> As per the current implementation of DNSMASQ, found out that, whenever
> DNSMASQ receives a DHCP-DECLINE message it will increment a counter.
> When offering an IP address to a client, DNSMASQ fetches the largest
> assigned address and from that address onwards it will try to allocate
> the next free address. In the process of allocating an address to a
> client, DNSMASQ will perform a PING check on the offering address and
> based on the PING result it will offer the address to the client (if
> PING fails) or it will check for the next address in the pool (when PING
> is successful).
> 
> If there are stations configured statically in the LAN network which
> blocks ICMP ECHO REQUEST and if DNSMASQ offers the same IP address(as
> PING fails) to the requesting station it will be declined. However
> DNSMASQ is not offering different IP to the station which has declined
> the IP when it tries to connect again.
> Also, if the PING reply didn't reach the DNSMASQ within the timeout,
> DNSMASQ is still trying to offer the same IP address(means declined
> address) to the clients.
> 
> Proposed alternatives:
> 
> In order to overcome this issue, we are planning to have an ARPing
> implementation along with the existing PING check in dnsmasq.
> We came across a link
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2006q3/000846.html 
> which
> discusses about the ARPing implementation.
> With the above approach, DNSMASQ will perform a ARP resolution before
> offering an address. If the ARP resolution is not successful, DNSMASQ
> will proceed to allocate the address,else DNSMASQ will try to offer the
> next free address in the pool.
> 
> 
> Please look into this issue and ARPing approach as a resoution for the
> same. If there are any other alternatives to resolve this issue please
> suggest.
> 
> Regards,
> Anvesh.
> 
> Disclaimer:This message is intended only for the designated
> recipient(s). It may contain confidential or proprietary information and
> may be subject to other confidentiality protections. If you are not a
> designated recipient, you may not review, copy or distribute this
> message. Please notify the sender by e-mail and delete this message.
> GlobalEdge does not accept any liability for virus infected mails.

___

Re: [Dnsmasq-discuss] Infinite(?) RTR-ADVERTs being sent out [in Ubuntu NetworkManager testuite]

2018-12-20 Thread Simon Kelley
Patch below is untested because I'm away from my test rig, but it would
seem to do the right thing, ie set template->if_index _before_ calling
ra_start_unsolicited() so that if we re-enter here via an async event it
doesn't get called again.

If you could test it in your harness, that would be great :)

Cheers,

Simon.



diff --git a/src/dhcp6.c b/src/dhcp6.c
index 3932cc7..4082504 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -650,12 +650,11 @@ static int construct_worker(struct in6_addr
*local, int prefix,
/* First time found, do fast RA. */
if (template->if_index != if_index ||
!IN6_ARE_ADDR_EQUAL(>local6, local))
  {
+   template->if_index = if_index;
+   template->local6 = *local;
ra_start_unsolicited(param->now, template);
param->newone = 1;
  }
-
-   template->if_index = if_index;
-   template->local6 = *local;
  }

   }


On 20/12/2018 17:21, Iain Lane wrote:
> On Thu, Dec 20, 2018 at 01:06:30PM +, Iain Lane wrote:
>>   dnsmasq-dhcp[2010]: RTR-ADVERT(veth42) 2600::
>>
>> repeating over and over. You can view a log file including all the
>> dnsmasq log entries at [2] - it's huge though, so I suggest downloading
>> it and using a real text editor instead of your browser.
>>
>> This test starts dnsmasq in ra-only mode, and that seems to be the case
>> that's broken. Since this started happening in a new version, I was able
>> to bisect 2.79 to 2.80, and I found that commit
>> 0a496f059c1e9d75c33cce4c1211d58422ba4f62 is the first bad commit.
>> Indeed, reverting that on master causes the NM testsuite to start
>> passing again.
> 
> I attached gdb to dnsmasq while it was doing this. Here's the stack
> trace of what was going on at the time:
> 
> (gdb) bt
> #0  0x7fb1b5a7cfd4 in __GI___libc_write (fd=10, buf=0x55c255462ce8, 
> nbytes=62) at ../sysdeps/unix/sysv/linux/write.c:26
> #1  0x55c253c4fb94 in log_write () at log.c:179
> #2  0x55c253c502fd in my_syslog (priority=6, format=0x55c253c77e39 
> "RTR-ADVERT(%s) %s") at log.c:389
> #3  0x55c253c5de2e in add_prefixes (local=0x55c25545d65c, prefix=64, 
> scope=0, if_index=13, flags=4, preferred=3600, valid=3600, 
> vparam=0x7ffcd1e77ce0) at radv.c:725
> #4  0x55c253c493a0 in iface_enumerate (family=10, parm=0x7ffcd1e77ce0, 
> callback=0x55c253c5d829 ) at netlink.c:268
> #5  0x55c253c5cad4 in send_ra_alias (now=1545314006, iface=13, 
> iface_name=0x7ffcd1e77e1c "veth42", dest=0x0, send_iface=13)
> at radv.c:291
> #6  0x55c253c5d826 in send_ra (now=1545314006, iface=13, 
> iface_name=0x7ffcd1e77e1c "veth42", dest=0x0) at radv.c:553
> #7  0x55c253c5e0f8 in periodic_ra (now=1545314006) at radv.c:808
> #8  0x55c253c3e256 in lease_update_file (now=1545314006) at lease.c:355
> #9  0x55c253c52e7e in dhcp_construct_contexts (now=1545314006) at 
> dhcp6.c:789
> #10 0x55c253c36812 in newaddress (now=1545314006) at network.c:1721
> #11 0x55c253c39902 in async_event (pipe=8, now=1545314006) at 
> dnsmasq.c:1413
> #12 0x55c253c38e71 in main (argc=11, argv=0x7ffcd1e78258) at 
> dnsmasq.c:1084
> 
> There's a few places you can get an async_event of EVENT_NEWADDR. Some
> further grubbing around shows that it's coming from iface_enumerate() ->
> nl_async() -> async_event(EVENT_NEWADDR).
> 
> You'll see that iface_enumerate() is frame #4 in that trace too, so this
> smells like it might be a source of infinite recursion to me: every time
> we call add_prefixes() we also queue another call of the same thing -
> the new code is to blame via dhcp_construct_contexts() calling
> construct_worker() to enter the new block setting param->newone = 1,
> which is checked in dhcp_construct_options().
> 
> What's not clear to me is how best to cut this off. If we only called
> the new code one time that would probably solve it...
> 
> Cheers,
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Patch to cache SRV records - updated version (#3)

2018-12-20 Thread Simon Kelley
This is worth having for the removal of the archaic 16-bit limit on the
flags field in a cache record alone. I've been meaning to tackle that
for some time.

This time of year either frees up lots of time for coding, or yields
none at all, and for me it's the later, but I will go through this and
merge it in the new year.


Cheers,

Simon.


On 20/12/2018 21:38, Jeremy Allison wrote:
> On 12/20/2018 12:20 PM, Jeremy Allison wrote:
>> On Thu, 20 Dec 2018 11:53:11 -0800
>>
>> Jeremy Allison  wrote:
>>
>>> I know dnsmasq doesn't cache SRV records by design:
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579536;msg=9
>>>
>>> However, when used with Samba code (winbindd) and
>>> other Windows-integrating technology (MIT krb5)
>>> there are a lot of SRV record queries that make
>>> the whole integration stack slow if SRV records
>>> are not cached.
>>>
>>> With that in mind, here is a patch to cache
>>> SRV records positively and negatively inside
>>> dnsmasq.
>>>
>>> I'm sending here it so that people who might need
>>> this functionality have a central place to find
>>> it (it might end up being used in ChromeOS, depending
>>> on test results / review).
>>
>> Sigh. Found a bug when testing. free_mx_srv_record()
>> wasn't checking for NULL pointers on free(),
>> which can be the case for negative cache
>> records.
> 
> Third time is the charm :-). Remember to NULL
> out free'd and uninitialized pointers and
> structrures, and remove the F_SRV flag on deleting
> the cache entry.
> 
> Hopefully this is the last iteration of this.
> I can't see any more issues to address, but
> I'm still testing :-).
> 
> Jeremy.
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Multiple instances of dnsmasq on Debian with systemd

2018-12-16 Thread Simon Kelley
This is obviously a large amount of work, so thanks very much for that.

To make use of it, I need to be able to see as clearly as possible what
is being changed, and why. To that end, I'd much rather have diff files
ten  replacement files, but it's fairly easy to generate those for
myself. Having done that, I get vast amounts of noise where you've fixed
up indentation and end-of-line spaces, which makes seeing the actual
changes very difficult. However, reading carefully, I can see most of
what you describe, but also the reversion of all the changes that have
happened to the files since the Debian stable release.


Could I ask you to do the following?


1) Start with the latest code for the sysV init script, systemd unit and
defaults file. You can get these from the git repo at

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=debian/init;hb=HEAD

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=debian/systemd.service;hb=HEAD

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=debian/default;hb=HEAD


2) Make just the functional changes you've identified: no formatting or
other extraneous changes.

3) Send me context diffs (diff -u) of the changes you've made



Cheers,

Simon.


On 01/12/2018 12:20, M. Buecher wrote:
> Hello Simon,
> 
> on my first tries to start multiple dnsmasq instances on Debian 9
> "Stretch" with systemd I faced several issues and created Debian bug
> report #914305 [1].
> Yesterday I finally managed to spend several hours on the issue and
> found a clean solution for it.
> While preparing the text for the bug report I recognized that you're the
> maintainer of the Debian packages, so I decided to write to the dnsmasq
> mailing list first.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914305
> 
> 
> 
> systemd unit files [2] allow to be used for multiple instances when the
> service unit file name ends with the at symbol (@).
> Then the service can be enabled with an instance name following the at
> symbol, e.g. `systemctl enable dnsmasq@main.service`.
> The instance name is available in an escaped format in variable %i
> (lower case) when the unit file is processed.
> The attached unit file dnsmasq@.service passes the escaped instance name
> to the init.d script (minor changes to the code plus `mv -v
> /lib/systemd/system/dnsmasq.service /lib/systemd/system/dnsmasq@.service`).
> 
> The 2nd attached file is the updated init.d script for dnsmasq.
> It now recognizes the instance name via the second script paramater and
> uses it wherever needed or possible (default file, pid file, resolvconf
> protocol, log entries).
> 
> Additionally three special cases had to be handled when running multiple
> instances of dnsmasq:
> a) The original systemd unit file wants to check the configuration
> before starting the service but does not honor the settings from the
> default file (conf file and dir).
>    Therefore the option checkconfig was added to the init.d script.
>    I don't know if there's a common SysInit V standard name for such a
> function [3].
> b) `mkdir /run/dnsmasq` in the init.d script can fail as unit files are
> run in parallel, so the directory has to be checked again if mkdir failed.
> c) Only one dnsmasq instance should be the dns resolver for the local
> system and should bind to localhost.
>    Therefore revived DNSMASQ_EXCEPT="lo" in the default file (3rd
> attached file).
> 
> Additional changes to the files are typo corrections.
> 
> [2] https://www.freedesktop.org/software/systemd/man/systemd.unit.html
> [3]
> https://www.debian.org/doc/debian-policy/ch-opersys.html#writing-the-scripts
> 
> 
> 
> 
> For testing I installed openresolv and dnsmasq on latest Debian 9
> "Stretch" and created some virtual network interfaces via systemd [4].
> The main dnsmasq instance shall run on the real NIC while special
> instances shall run on the extra virtual NICs (dnsextra*).
> 
> Stopped and disabled the original service from the Debian dnsmasq package:
> `systemctl stop dnsmasq.service`
> `systemctl disable dnsmasq.service`
> `systemctl status dnsmasq.service`
> 
> Prepared dnsmasq systemd unit file for instances by renaming and
> updating it:
> `mv -v /lib/systemd/system/dnsmasq.service
> /lib/systemd/system/dnsmasq@.service`
> 
> As instance enabled systemd unit files have to be used with an instance
> name I decided to name the default dnsmasq instance simply "main".
> Not to break SysInit V compatibility a symbol link was used for the
> "renaming" of the default file.
> `ln -s -T dnsmasq /etc/default/dnsmasq.main`
> (P.S. Other idea would be to default INSTANCE in init.d to 'main' when
> instance name not given.)
> 
> Updated also init.d script and normal default file.
> 
> Then prepared two dnsmasq instances:
> 1. Default file for main instance (/etc/default/dnsmasq.main)
> Changed to DNSMASQ_OPTS="--bind-dynamic --except-interface=dnsextra*"
> This way it will avoid binding to the extra virtual NICs while still
> 

Re: [Dnsmasq-discuss] Validation for malformed DHCP packets in dnsmasq

2018-12-16 Thread Simon Kelley
I can't answer your question about if this has been fixed, as there's
not enough information to identify the problem or trigger the bug.

Can you provide  proof-concept code, or even just packet captures of the
malformed packets that cause problems?

I've confused by the "dhcp to be unresponsive from
the switch for a small amount of time." observation. What's happening
here? Note that dnsmasq can queue DHCPDISCOVER requests whilst is if
doing address-in-use testing. If that's causing the unresponsiveness
then it's expected and there are mitigations in place to avoid DOS. If,
on the other hand, the malformed packets are crashing dnsmasq and some
daemon-framework is restarting it, that's bad, and we'd like to know
about it.



Cheers

Simon.



On 10/12/2018 05:59, P, Sreelakshmi wrote:
> Hi All,
> 
>  
> 
> Does anyone has any update on this?
> 
>  
> 
> Thanks!
> 
>  
> 
> *From:* P, Sreelakshmi
> *Sent:* Friday, December 7, 2018 4:19 PM
> *To:* 'dnsmasq-discuss@lists.thekelleys.org.uk'
> 
> *Subject:* Validation for malformed DHCP packets in dnsmasq
> 
>  
> 
> Hi,
> 
>  
> 
> We are using dnsmasq 2.78. We see that there are some security
> vulnerability w.r.t malformed DHCP packets as explained below.
> 
>  
> 
> *_Problem 1:_*
> 
> A malformed dhcp discover packet can cause dhcp to be unresponsive from
> the switch for a small amount of time.  If this was repeated over time
> an attacker could make the dhcp service unresponsive DOSing the box. 
> 
>  
> 
> It starts out with the malformed discover immediately followed by a dhcp
> decline.  then the client sends another dhcp discover packet.  The
> switch does not respond to this discover. 
> 
> After about two seconds the client tries again and dhcp works as normal. 
> 
>  
> 
> *_Problem 2:_*
> 
> DHCP request with anomaly causing DOS condition
> 
>  
> 
> A Malformed DHCP request causes dhcp server to not respond for a short
> period of time.  The request is modified by reducing the size of the
> data in the mac address field in the dhcp request.
> 
> After the request is sent to the switch the client sends another dhcp
> discover which is not responded to.  After about 1.5 seconds the client
> tries again and the discover is responded to.
> 
>  
> 
> *_Problem 3:_*
> 
> DHCP discover packet with extra byte in hardware address causing DOS of
> DHCP on switch
> 
>  
> 
> If an extra byte is added to the hardware address field in a dhcp
> discover it will cause the DHCP service to become unresponsive for a
> short period of time.  If repeated it could be used as a DOS attack.
> 
>  
> 
> *_Problem 4:_*
> 
> DHCPv6 solicit with anomaly in Identity association length field causing DOS
> 
>  
> 
> When the integer value 65534 is placed in the Identity association
> length field of a dhcpv6 solicit packet the switch enters a DOS state
> for a couple seconds
> 
>  
> 
> *_Problem 5:_*
> 
> DHCPv6 solicit 2 Extra bytes trailing option status code causes DOS
> 
>  
> 
> Sending dhcpv6 solicits with extra bytes trailing the option status code
> causes the switch dhcp server to become temporarily unresponsive.
> 
>  
> 
> In a summary, to overcome this problem, DHCP packet validation has to be
> done. Has any fix related to any of these problems have gone in after 2.78?
> 
>  
> 
> Thanks in Advance!!
> 
>  
> 
> Regards,
> 
> Sree
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] DHCP from dnsmasq in docker container

2018-12-16 Thread Simon Kelley
On 13/12/2018 14:10, Craig Younkins wrote:
> First, thank you for dnsmasq!
> 
> I'm among a number of people[1][2][3][4] having trouble using dnsmasq
> for DHCP when it is running in a docker container. Everyone seems to get
> "no address range available for DHCP request via eth0" in their log
> unless they change to host networking mode.
> 
> The code path for that error message is at [5]. I'm having a little
> trouble understanding the 'contexts', but I think the problem is that
> the container is running in bridged networking mode, and thus the
> interface has an IP address outside the netmask range.
> 
> Is there a way to make this work without using host networking? Maybe
> adding the external IP to the container interface? Thank you for any
> suggestions!
> 


I'm not familiar with these docker "networking modes", can you explain
what they mean?


What's happening here is quite straightforward to understand.  A DHCP
request arrives at an interface which has the IP address 172.17.0.2 and
netmask 172.17.255.255. Dnsmasq tries to find a dhcp-range from which is
can allocate an address by looking for a DHCP range which covers the
same network. Since the only available DHCP range is
192.168.1.200,192.168.1.251 and that's not the same network, this fails.


Depending on exactly how docker is set up, something equivalent to the
ISC dhcpd's "shared-network" configuration might be the way to go. This
is a useful facility which I've considered adding before, essentially,
is allows you to tell dnsmasq that (in this case) 172.17.0.0/16 and
192.168.1.0/24 are both on the same network segment or broadcast domain.
That would allow dnsmasq to deduce that the request which comes from the
172.17.0.0/16 segment can be satisfied by a 192.168.1.0/24 address.

Note that there are other requirements needed to make this work.
Notably, a DHCP client that gets a 192.168.1.0/24 address has to have
suitable routing to allow it to route packets to 172.17.0.2, and the
reverse route is also needed.

To be clear: shared-network doesn't exist in released versions of
dnsmasq, I'm proposing new code.


Cheers,

Simon.


> Relevant sample configuration:
> addn-hosts=/etc/pihole/gravity.list
> addn-hosts=/etc/pihole/black.list
> addn-hosts=/etc/pihole/local.list
> localise-queries
> no-resolv
> cache-size=1
> log-queries=extra
> log-facility=/var/log/pihole.log
> local-ttl=2
> log-async
> server=8.8.8.8
> server=8.8.4.4
> interface=eth0
> dhcp-authoritative
> dhcp-range=192.168.1.200,192.168.1.251,24h
> dhcp-option=option:router,192.168.1.1
> dhcp-leasefile=/etc/pihole/dhcp.leases
> domain=local
> 
> root@6082bda95199:/# ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8  scope host lo
>        valid_lft forever preferred_lft forever
> 10: eth0@if11:  mtu 1500 qdisc noqueue
> state UP group default
>     link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>     inet *172.17.0.2/16 * brd 172.17.255.255 scope
> global eth0
>        valid_lft forever preferred_lft forever
> 
> To reproduce, you can run something like what is in [6], then enabling
> the DHCP server through the non-ssl web interface. `docker exec -it
> pihole /bin/bash` to get into the container and `tail -f
> /var/log/pihole.log` for the log. 
> 
> [1] https://github.com/pi-hole/docker-pi-hole/issues/355
> [2] https://discourse.pi-hole.net/t/dhcp-not-working-docker/12593
> [3] 
> https://discourse.pi-hole.net/t/no-address-range-available-for-dhcp-request-via-eth0/14350
> [4] 
> https://serverfault.com/questions/825497/running-dnsmasq-in-docker-container-on-debian-check-dhcp-ignores-dnsmasq
> [5] 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/rfc2131.c;h=56dc3d103741baeb68a730f0ce15a10338a2f885;hb=91421cb7575df7bb211dacc30dc7c7c715c38299#l345
> [6] https://github.com/pi-hole/docker-pi-hole/blob/master/docker_run.sh
> 
> Craig Younkins
> 
> ___
> 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


Re: [Dnsmasq-discuss] [PATCH] Re: dhcp-boot & dhcp-reply-delay optional tag fixes

2018-12-16 Thread Simon Kelley
Thanks both for this. Petr's more comprehensive patch is now in my tree.

Cheers,

Simon.





On 15/12/2018 09:43, Kevin Darbyshire-Bryant wrote:
> 
> 
>> On 14 Dec 2018, at 16:10, Petr Mensik  wrote:
>>
>> Hi Kevin et al,
>>
>> sure, your fix is correct one. I just found one more place where tags
>> were required. Your pointer handling is not as hopeless as you are
>> saying. :)
> 
> He he - It’s always good to get a second opinion though :-)  And you spotted 
> another place I missed as well.
> 
>>
>> Sorry for inconvenience caused by my change. I miss some tests that
>> would discover it, have to write them someday soon.
>>
>> Petr
> 
> It seems the openwrt users have a very wide range of use cases and notice 
> stuff ;-)
> 
> Your more complete fix is in openwrt master - thank you.
> 
> 
> 
> Cheers,
> 
> Kevin D-B
> 
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> ___
> 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


Re: [Dnsmasq-discuss] build failure on master with NO_DHCPv6 and fix....

2018-12-16 Thread Simon Kelley
Patch applied. Thanks.

What we really need is a script that calls make repeatedly whilst
cycling through all the possible combinations of build options.


Cheers,

Simon.



On 10/12/2018 10:34, Kevin Darbyshire-Bryant wrote:
> Hi Simon,
> 
> master has a build error when building without HAVE_DHCPv6
> 
> option.c: In function 'dhcp_context_free':
> option.c:1042:15: error: 'struct dhcp_context' has no member named 
> 'template_interface'
>free(ctx->template_interface);
> 
> Sadly, need to put in a little conditional compilation ifdef'erey
> 
> Simplest patch in the world attached
> 
> 
> 
> Cheers,
> 
> Kevin D-B
> 
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] fix ipv6 ipset bug in master

2018-12-16 Thread Simon Kelley
Ooops. My hand's up for that one. Patch applied. Thanks.


Cheers,

Simon.



On 12/12/2018 12:00, Kevin Darbyshire-Bryant wrote:
> Hi Simon,
> 
> Another one fallen out of the openwrt tree shake :-)
> 
> ipv6 ipset addresses weren’t being set correctly.  patch attached 
> 
> 
> 
> Cheers,
> 
> Kevin D-B
> 
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] [Feature Request] Tagged server and address configuration

2018-11-22 Thread Simon Kelley


On 19/11/2018 21:07, M. Buecher wrote:
> Hello Simon and dnsmasq fellows,
> 
> I blacklist several domains via host files and wanted to skip the
> blacklist for my testing client.
> Unfortunately I couldn't find a solution for this in the man page, or
> maybe I just didn't see the correct config combination.
> Or did I miss a way to configure this with the existing features?
> 
> 
> So I came up with the idea of tag-matching server and address
> configuration, like...
> --server=[tag:[,tag:],][/[]/[domain/]][[#][@|[#]]
> 
> --address=[tag:[,tag:],]/[/...]/[]
> 
> This would provide a highly flexible way to blacklist/whitelist  domains
> for specific clients.
> But I assume it may be an ugly coding hell to implement.
> 
> 

The problem lies in the fact that there's nothing in the DNS part of
dnsmasq to determine the tags - the taq-set that's used in the DHCP part
of dnsmasq is determined dynamically during each DHCP transaction:
there's no way to make it long-lived and associate it with DNS request
that arrives later.


Cheers,

Simon.



> Kind regards
> Maddes
> 
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] "no available addresses" with DHCPv6 stateful config

2018-11-20 Thread Simon Kelley
This does seem odd. Would it be possible to capture the DHCP packets,
using wireshark or tcpdump? Send the dump directly to me if you don't
want to post it in public.

I'm not sure what the status of the WIDE client is - it's not common.
Maybe worth trying the ISC client instead, for quick fix. I can't see an
obvious problem with your config.



Cheers,

Simon.

> 
> sudo /usr/sbin/dnsmasq \
>   --bogus-priv \
>   --no-hosts \
>   --dhcp-authoritative \
>   --filterwin2k \
>   --expand-hosts \
>   --domain=test \
>   --local=/test/ \
>   --log-facility=- \
>   --log-dhcp \
>   --keep-in-foreground \
>   --bind-interfaces \
>   --interface=br1002 \
>   --except-interface=lo \
>   --listen-address=2001::::1 \
>   --dhcp-range=::2,::,constructor:br1002,24h
> 
> That `listen-address` is definitely bound to the server side:
> 
> 6: br1002:  mtu 8800 qdisc noqueue
> state UP group default qlen 1000
>     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
>     inet6 2001::::1/64 scope global
>    valid_lft forever preferred_lft forever
> 
> What's happening is my DHCPv6 requests come in fine, but the server
> reports "no available addresses" even though I have what appears to be a
> valid range of available addresses:
> 
> dnsmasq-dhcp[746253]: 12629722 available DHCP range: 2001::::2
> -- 2001::::
> dnsmasq-dhcp[746253]: 12629722 client MAC address: 52:54:00:5c:f1:32
> dnsmasq-dhcp[746253]: 12629722 DHCPSOLICIT(br1002)
> 00:01:00:01:23:7e:62:3a:52:54:00:5c:f1:31
> dnsmasq-dhcp[746253]: 12629722 DHCPADVERTISE(br1002)
> 00:01:00:01:23:7e:62:3a:52:54:00:5c:f1:31 no addresses available
> dnsmasq-dhcp[746253]: 12629722 tags: dhcpv6, br1002
> dnsmasq-dhcp[746253]: 12629722 sent size: 14 option:  1 client-id 
> 00:01:00:01:23:7e:62:3a:52:54:00:5c:f1:31
> dnsmasq-dhcp[746253]: 12629722 sent size: 14 option:  2 server-id 
> 00:01:00:01:23:83:8e:6b:52:54:00:14:c5:11
> dnsmasq-dhcp[746253]: 12629722 sent size: 24 option: 13 status  2 no
> addresses available
> dnsmasq-dhcp[746253]: 626033 available DHCP range: 2001::::2 --
> 2001::::
> dnsmasq-dhcp[746253]: 626033 client MAC address: 52:54:00:5c:f1:32
> dnsmasq-dhcp[746253]: 626033 DHCPREQUEST(br1002)
> 00:01:00:01:23:7e:62:3a:52:54:00:5c:f1:31
> dnsmasq-dhcp[746253]: 626033 DHCPREPLY(br1002)
> 00:01:00:01:23:7e:62:3a:52:54:00:5c:f1:31 no addresses available
> dnsmasq-dhcp[746253]: 626033 tags: dhcpv6, br1002
> dnsmasq-dhcp[746253]: 626033 sent size: 14 option:  1 client-id 
> 00:01:00:01:23:7e:62:3a:52:54:00:5c:f1:31
> dnsmasq-dhcp[746253]: 626033 sent size: 14 option:  2 server-id 
> 00:01:00:01:23:83:8e:6b:52:54:00:14:c5:11
> dnsmasq-dhcp[746253]: 626033 sent size: 24 option: 13 status  2 no
> addresses available
> dnsmasq-dhcp[746253]: 626033 sent size: 16 option: 23 dns-server 
> 2001::::1
> 
> From my understanding of the man page and the older thread "Using IPv6
> DHCP"
> (http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q3/006306.html),
> this should be all I need to get a stateful DHCPv6 configuration. I've
> also tried every combination of options I can come up with in the
> `dhcp-range` config without success. Even if I set `static` mode and use
> a `dhcp-host` option for my test host, I get the exact same "no
> addresses available" message.
> 
> SLAAC works fine when I add `enable-ra`, and `ra-stateless` to
> `dhcp-range`, but this configuration to hand out only IPv6 addresses
> statefully never seems to work as described in that thread. The goal is
> to have a fully stateful DHCPv6 server that IPv6-only clients can get
> addresses from and, most importantly, update dnsmasq with their hostname
> (hence why I'm not using SLAAC or `ra-stateless`). The very specific
> binding config is due to me running a separate dnsmasq instance for each
> of an arbitrary number of interfaces.
> 
> Can anyone offer any advice on what I might be doing wrong here?
> 
> Thanks,
> Joshua M. Boniface
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DNS query random ports [PATCH]

2018-11-08 Thread Simon Kelley
On 07/11/2018 11:55, Petr Mensik wrote:
> Hi Simon,
> 
> I am sure this is already an old issue. I forgot to mark patch presence
> in subject. I proposed a way to fallback to kernel assigned outgoing
> ports. Is it unacceptable? Have you even noticed the patches? Could you
> check if they could be used?
> 
> I think any new deployments of dnsmasq would have working random ports
> generation built into kernel. Disadvantage of current code is it does
> not follow sysctl net.ipv4.ip_local_port_range configured in kernel.
> 

I thought, though I didn't explicitly say it in my reply, that there
were good reasons, at the time, for doing it the way it's done. Those
reasons don't apply now, but it works, so why change? The
net.ipv4.ip_local_port_range is an additional consideration, I guess
we'd have to deprecate the --min-port and --max-port dnsmasq options.



Cheers,

Simon.

> Cheers,
> Petr
> 
> On 8/21/18 11:24 PM, Simon Kelley wrote:
>> On 10/08/18 13:37, Petr Menšík wrote:
>>> Hello,
>>>
>>> we discovered our dnsmasq  were using also privileged source ports when
>>> sending queries. Interesting enough, it has right to do it, because it
>>> has to listen also on privileged port. It never drops such privilege.
>>>
>>> It was fixed in commit [1]. But my question is, why is there even custom
>>> generator or random ports, when OS can do it itself? And usually far
>>> better? So I dug a bit into it and came with patch, that would use
>>> random ports from OS by default.
>>>
>>> When I tested it, I got the same results when skipping bind() call on
>>> random ports at all. Is there some reason, why dnsmasq does not follow
>>> OS policy for source outgoing port and choses its own range by itself?
>>>
>>> 1.
>>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=baf553db0cdb50707ddab464fb3eff7786ea576c
>>>
>>
>> The random port code was added to dnsmasq in response to the Kaminsky
>> Birthday attack paper, which was in 2009. At that point, there were
>> still people seriously running routers (and therefore dnsmasq) on Linux
>> 2.0 kernels. As best I remember, I did it the way I did because I
>> couldn't be sure that all the platforms dnsmasq would run on would
>> allocate sufficiently random ports: RFC6056 was still more than a year
>> in the future.
>>
>>
>> I'm sure that code could be simplified now.
>>
>> Simon.
>>
>>
>> ___
>> 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


Re: [Dnsmasq-discuss] static lease issues?

2018-11-06 Thread Simon Kelley
On 05/11/2018 03:30, Kevin Darbyshire-Bryant wrote:
> Hi Simon, Hi List,
> 
> I’m hearing rumblings from the openwrt community that something isn’t right 
> with static leases.   The behaviour manifests itself as the statically 
> assigned host being unable to renew its lease.  e.g.
> 
> -this is okay
> Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 available DHCP 
> range: 192.168.0.100 -- 192.168.0.199
> Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 client provides 
> name: sylvester
> Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 
> DHCPDISCOVER(eth0.54) 00:11:22:33:44:55
> Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 tags: lan, known, 
> eth0.54

> Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 
> DHCPOFFER(eth0.54) 192.168.0.12 00:11:22:33:44:55
> -but later
> 
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 available DHCP 
> range: 192.168.0.100 -- 192.168.0.199
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 client provides 
> name: sylvester
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 
> DHCPREQUEST(eth0.54) 192.168.0.12 00:11:22:33:44:55
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 DHCPNAK(eth0.54) 
> 192.168.0.12 00:11:22:33:44:55 address not available
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 broadcast response
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 sent size:  1 
> option: 53 message-type  6
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 sent size:  4 
> option: 54 server-identifier  192.168.0.254
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 sent size: 21 
> option: 56 message  61:64:64:72:65:73:73:20:6e:6f:74:20:61:76...
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 available DHCP 
> range: 192.168.0.100 -- 192.168.0.199
> Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 client provides 
> name: sylvester
> Nov  4 15:52:36 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 
> DHCPDISCOVER(eth0.54) 00:11:22:33:44:55
> Nov  4 15:52:36 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 tags: lan, 
> known-othernet, eth0.54
> Nov  4 15:52:36 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 
> DHCPOFFER(eth0.54) 192.168.0.190 00:11:22:33:44:55
> 
> I have yet to see this behaviour personally, so I’m putting this out there as 
> a) anyone else b) any ideas on debugging?
> 
> 


Look at the tags on the first and second DHCPDISCOVERs. The first one is
in "known" and the second is "known-othernet".

"known" means that the host has a dhcp-host or similar configuration
which provides an address, and the address in in scope for the network
it's talking from. "known-othernet" means the same, but the the address
is NOT in scope.

That probably explains the DHCPNAK too.

The question is "what's changed". difficult to tell. Maybe the netmask
on the interface?


Cheers,

Simon.

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


Re: [Dnsmasq-discuss] [PATCH] Free config file values on parsing errors.

2018-11-02 Thread Simon Kelley
On 25/10/2018 09:36, Petr Mensik wrote:
> Hi again.
> 
> This time I have a little bit more controversal patches. But I think
> still useful. They fixes memory leaks that might occur in some cases.
> Most dnsmasq errors is fatal, so it does not matter. But some are not.
> Some parts are reloaded on SIGHUP signal, so it might leak more than once.
> 
> Some example when it changes the failures. Use dhcp-options file with
> this content:
> 
> tag:error,vendor:redhat
> option:ntp-server,1.2.3.4.5
> option6:ntp-server,[:::]
> 
> Is not fatal and dnsmasq will start. On each reload command, it would
> leak some memory. I validated it using valgrind --leak-check=full
> dnsmasq -d. This patch fixes it. It introduces something that might be
> considered constructor and destructor of selected structures. What do
> you think of it?
> 
> Comments are welcome. Another patch would be sent short after, they are
> too big together to require moderator attention.
> 

I've applied the patches. I think they're doing the right thing.

I'm a little bit concerned about how extensive the changes are, but I've
done my best to review everything, and I can't find any problems. We're
early in the 2.81 cycle, so if there is anything lurking, there's a
chance to find it.


Cheers,

Simon.


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


Re: [Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.

2018-11-02 Thread Simon Kelley
Kevin's analysis is spot-on, as is his patch, which I've just applied.


Cheers,

Simon.


On 26/10/2018 00:24, Kevin Darbyshire-Bryant wrote:
> 
> 
>> On 25 Oct 2018, at 21:38, Kevin Darbyshire-Bryant 
>>  wrote:
>>
>> I think Openwrt is safe.   There will be a loud scream from me if it isn’t 
>> :-)
>>
>> Cheers,
>>
>> Kevin D-B
>>
> 
> In fact to prove it to myself I had a go at removing the NO_FORK compile time 
> option (patch attached) and had no obvious problem with the resultant binary 
> on Openwrt.
> 
> Whether Simon implements the change as I have done or takes the opportunity 
> to simplify things that I don’t understand I don’t know, but NO_FORK v 
> OPT_NO_FORK are different things and OPT_NO_FORK relies on NO_FORK *NOT* 
> being defined.
> 
> Cheers,
> 
> Kevin D-B
> 
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] Stumped

2018-10-31 Thread Simon Kelley
I'm confused by the references to openssl in your description. Dnsmasq
with DNSSEC does NOT depend on openSSL. You just need libnettle and
libhogweed installed in the standard way, and accessible via pkg-config.

version 3.4 should be fine.


Cheers,

Simon.



On 31/10/2018 03:21, Peter Nehem wrote:
> Hello All,
>  I'm stumped I've been trying to compile dnsmasq for Centos 7.5 because
> the version for Centos 7.5 doesn't have any of the extra features turned
> on, namely dnssec and several others. But I keep getting this error
> message no matter what I do:
> 
> ccache gcc -Wall -W -O2   -DVERSION='"2.76"' -I/usr/include/dbus-1.0
> -I/usr/lib64/dbus-1.0/include   -I/usr/local/include    -c
> dnssec.c   
> dnssec.c: In function ‘dnsmasq_ecdsa_verify’:
> dnssec.c:266:36: error: ‘nettle_secp_256r1’ undeclared (first use in
> this function)
>     nettle_ecc_point_init(key_256, _secp_256r1);
>     ^
> dnssec.c:266:36: note: each undeclared identifier is reported only once
> for each function it appears in
> dnssec.c:279:36: error: ‘nettle_secp_384r1’ undeclared (first use in
> this function)
>     nettle_ecc_point_init(key_384, _secp_384r1);
>     ^
> make[1]: *** [/mnt/sdb1/dnsmasq-2.76/Makefile:157: dnssec.o] Error 1
> make[1]: Leaving directory '/mnt/sdb1/dnsmasq-2.76/src'
> make: *** [Makefile:83: all] Error 2
> 
> I have gotten it in every version I've tried to compile. I've tried
> dnsmasq-master, dnsmasq-2.80, most recent snapshot, dnsmasq-2.76. I
> tried having it read from openssl-1.1.1 that I have complied for nginx,
> but that didn't work, so I recompiled Nettle-3.4 ( I used this for the
> configure line: ./configure --enable-fat --enable-gcov
> --disable-documentation --disable-arm-neon
> --with-include-path=/opt/openssl/include/openssl ) Took a few tried to
> finally get it to compile but I got it to use the files from
> openssl-1.1.1 so that Nettle would be up to the task.
> 
>  For each try I had to copy dbus.h from my includes folder because it
> will error out and it seems to like it right in the main folder, I've
> also tried copying the whole dbus folder from includes to the src
> folder, for 2.80 I copied the nettle includes into src because it
> couldn't find that as well.
> 
> These are the changes I did to config.h each time I tried to compile:
> This was for 2.7
> 
> #define DEFLEASE 86400 /* default lease time, 1 hour */
> #define CHUSER "dnsmasq"
> #define CHGRP "dnsmasq"
> 
> #define HAVE_LUASCRIPT */
> #define HAVE_DBUS */
> #define HAVE_IDN */
> #define HAVE_CONNTRACK */
> #define HAVE_DNSSEC */
> 
> #define LEASEFILE "/var/lib/dnsmasq/dnsmasq.leases"
> 
> For 2.8
> #define HAVE_LUASCRIPT
> #define HAVE_DBUS
> #define HAVE_IDN
> #define HAVE_LIBIDN2
> #define HAVE_CONNTRACK
> #define HAVE_DNSSEC
> 
> In the makefile I chg Lua to 5.3 because Centos only has 5.1 and I added
> this for 2.8 LIBS  = -L/usr/local/lib64 - this time I didn't copy over
> the nettle includes:
> 
> crypto.c: In function ‘dnsmasq_ecdsa_verify’:
> crypto.c:297:36: error: ‘nettle_secp_256r1’ undeclared (first use in
> this function)
>     nettle_ecc_point_init(key_256, _secp_256r1);
>     ^
> crypto.c:297:36: note: each undeclared identifier is reported only once
> for each function it appears in
> crypto.c:310:36: error: ‘nettle_secp_384r1’ undeclared (first use in
> this function)
>     nettle_ecc_point_init(key_384, _secp_384r1);
>     ^
> make[1]: *** [/mnt/sdb1/dnsmasq-2.80/Makefile:161: crypto.o] Error 1
> make[1]: Leaving directory '/mnt/sdb1/dnsmasq-2.80/src'
> make: *** [Makefile:86: all] Error 2
> 
> This is line 297: nettle_ecc_point_init(key_256, _secp_256r1);
> This is line 310: nettle_ecc_point_init(key_384, _secp_384r1);
> 
> I looked through openssl to try and see how the defined this and I can't
> remember where it was at
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Can Dnsmasq be told not to advertise a specific prefix via RA?

2018-10-28 Thread Simon Kelley
Can you also add a dhcp-range for the ULA range, which deprecates it?

Cheers,

Simon.


On 27/10/2018 18:17, Christopher Martin wrote:
> Greetings,
> 
> Is it possible to prevent Dnsmasq from advertising a specific prefix via
> router advertisements?
> 
> Here's my situation. My ISP provides a dynamic IPv6 prefix which, using
> wide-dhcpv6, ends up assigned to interface bond0. Dnsmasq then
> advertises the prefix on bond0 out to the LAN. The various hosts on the
> LAN use it, together with IPv6 privacy extensions, to generate global
> IPv6 addresses. So far so good.
> 
> For reference, my config is as follows:
> 
> dhcp-range=::,constructor:bond0,ra-only,infinite
> 
> Here's the problem. I also assign a ULA to bond0 (fd00:etc.). Dnsmasq
> also advertises this prefix to the LAN, but I don't want it to, because
> then the other hosts on the LAN end up generating addresses based on it,
> including via IPv6 privacy extensions. Whereas what I want is to
> manually assign each host its own specific, unchanging and easily
> remembered ULA, which should also be the source IP used when connecting
> to various services around the LAN. Too many ULAs cause problems.
> 
> Is there a way to instruct Dnsmasq to _not_ advertise the ULA prefix,
> but to continue advertising the global prefix from my ISP? Perhaps this
> option already exists and I've simply missed it - apologies if that's
> the case.
> 
> Thanks very much,
> 
> Christopher Martin
> 
> ___
> 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


Re: [Dnsmasq-discuss] DNSSEC failure for dagjeuitactie.nl

2018-10-28 Thread Simon Kelley
There's a CNAME at the root of the domain, which is not permissible, and
the root cause of the validation failure.


https://medium.freecodecamp.org/why-cant-a-domain-s-root-be-a-cname-8cbab38e5f5c

gives some reasons why this is not a good idea.

What actually happens is that dnsmasq makes a query for the DS record
for dagjeuitactie.nl and gets back the CNAME, rather than NSEC records
from the parenet proving that the DS doesn't work. It's arguable that
this is not sensible behaviour, but the it's what happens, and it makes
it impossible for dnsmasq to do validation.

The easiest way to fix this is almost certainly to fix the domain.


Cheers,

Simon.



On 26/10/2018 15:05, Willem Bargeman wrote:
> Hi Simon,
> 
> I received a message that the website dagjeuitactie.nl
>  was not working. When I do a dig for this
> domain the status is SERVFAIL.
> 
> dig dagjeuitactie.nl  @127.0.0.1
>  -p 5353
> 
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> dagjeuitactie.nl
>  @127.0.0.1  -p 5353
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30367
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1452
> ;; QUESTION SECTION:
> ;dagjeuitactie.nl .              IN      A
> 
> ;; Query time: 101 msec
> ;; SERVER: 127.0.0.1#5353(127.0.0.1)
> ;; WHEN: Fri Oct 26 15:50:50 CEST 2018
> ;; MSG SIZE  rcvd: 45
> 
> In the log file I can see the following.
> 
> dnsmasq[5172]: query[A] dagjeuitactie.nl  from
> 127.0.0.1
> dnsmasq[5172]: forwarded dagjeuitactie.nl  to
> 127.0.1.1
> dnsmasq[5172]: validation dagjeuitactie.nl  is
> BOGUS
> 
> A query using the Cloudflare or Google DNS servers is working. 
> The domain name (dagjeuitactie.nl  and
> www.dagjeactie.nl ) is a CNAME
> for dagjeuit-web.queueup.eu .
> Dagjeuitactie.nl is not DNSSEC enabled. However, the
> domain dagjeuit-web.queueup.eu  is
> DNSSEC enabled. However this record is also a CNAME to a AWS server.
> 
> I'm not a DNSSEC expert but is this behavior correct? Is this a failure
> in Dnsmasq or is the domain not configured correctly.
> 
> Thank you!
> 
> Best regards,
> Willem Bargeman
> 
> ___
> 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


Re: [Dnsmasq-discuss] Avoid cache clearing on SIGHUP

2018-10-28 Thread Simon Kelley
The solution may be use of --hostsdir, which avoids the need for sending
SIGHUP.


Cheers,

Simon.


On 28/10/2018 10:55, Микола Василенко wrote:
> Hi all,
> 
> Is there any method to avoid DNS cache clearing on SIGHUP? I want only
> to update host info by sending SIGHUP to dnsmasq daemon. As there are no
> servers info changed (e.i. resolv.conf, servers conf), I think, there is
> no need to clear the cache as it is still up to date.
> 
> Thank in advance.
> 
> ___
> 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


Re: [Dnsmasq-discuss] [PATCH] Simplify options flags

2018-10-24 Thread Simon Kelley
On 24/10/2018 16:25, Petr Mensik wrote:
> Hi!
> 
> I have not managed it until dnsmasq 2.80 were out, but anyway. I have
> some proposal to simplify handling of options bits. Static analysis
> complains on compiler dead-code optimization. I propose having array
> instead. It adds few defines. But it allows adding any bits to defines
> and moving OPT_LAST. It will resize itself as required.
> 
> It might be possible to change unsigned int to unsigned long. It would
> use 64 bit numbers on x86_64 machines. But I guess it might not be worth
> that optimization.
> 
> Chances to get it merged?
> 
> 

Merged as is. a definite improvement.


Cheers,

Simon.




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.

2018-10-24 Thread Simon Kelley
The dnsmasq code has a range of binary compile-time options, implemented
conventionally using the C pre-processor. These options are mutually
independent, so the numnber of different versions scales as 2^n. To keep
this managable, I'm trying to limit the number of options.

I've already removed HAVE_IPV6. This was added originally to support
very ancient embedded libc versions, and to save a few bytes on very
limited machines. I think it's reasonable to assume in 2018 that nobody
wants to eliminate IPv6 support, and that nobody is running with a libc
that doesn't know about IPv6.


The next option in my sights is NO_FORK. This produces a
mostly-functional binary that never forks any new processes. It was
added long ago to support uclinux, the MMU-less version of Linux. As far
as I can tell, MMU-less linux is a dead project, and I'm minded to
remove NO_FORK. Opinions? Is this option vital to something I'm not
aware of?



Cheers,

Simon.




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Cannot look up disa.mil (dnssec related)

2018-10-23 Thread Simon Kelley
On 22/10/2018 17:56, Craig Andrews wrote:
> I'm unable to look up *.disa.mil when using dnsmasq - I'm hoping that we
> can figure out why that is.
> 
> I have dnsmasq configured to use Cloudflare's 1.1.1.1 as its upstream
> DNS server; dnsmasq is running on 192.168.0.1.
> 
> Here are some a couple tests demonstrating the problem:
> --
> $ dig disa.mil @192.168.0.1 +dnssec +short
> 
> $ dig disa.mil @8.8.8.8 +dnssec +short
> 156.112.108.76
> A 8 2 7200 20181117145327 20181018145327 52983 disa.mil.
> dMS5WbQ5xJ0HuCBPZUkuoshf0A2n1tvxA75smhcFZNS5SHSOA0zsQaSc
> YOzNdu5gH6qFXA7TbKhPYN0RcPD+vVcmtfbzv3eJZfh4343IXlBznG6w
> aLaLt+kI6GGnPQ7skNWOcO4yLct+yaeNxTT95CZnHtwRUx3vzGHS3dJF GYc=
> [candrews@craigatwork vars]$ dig disa.mil @1.1.1.1 +dnssec +short
> 156.112.108.76
> --
> So looking it up using Google's 8.8.8.8 or Cloudflare's 1.1.1.1 with
> dnssec works, but not with dnsmasq.
> 

As Matthias says elsewhere in the thread, the last sentence above
appears not to be correct: it does work with 8.8.8.8, but not with 1.1.1.1

srk@holly:~$ dig disa.mil @8.8.8.8 +dnssec +short
156.112.108.76
A 8 2 7200 20181117145327 20181018145327 52983 disa.mil.
dMS5WbQ5xJ0HuCBPZUkuoshf0A2n1tvxA75smhcFZNS5SHSOA0zsQaSc
YOzNdu5gH6qFXA7TbKhPYN0RcPD+vVcmtfbzv3eJZfh4343IXlBznG6w
aLaLt+kI6GGnPQ7skNWOcO4yLct+yaeNxTT95CZnHtwRUx3vzGHS3dJF GYc=
srk@holly:~$ dig disa.mil @1.1.1.1 +dnssec +short
156.112.108.76


The replies from 1.1.1.1 are missing the DNSSEC signatures, and this
appears to be a problem at Cloudflare, rather than a problem with
dnsmasq, or with the domain.

If I use 8.8.8.8 as upstream, dnsmasq validates fine. If I use 1.1.1.1
validation fails, because 1.1.1.1 is not returning the RRSIG RRs, even
though it's been asked to. Without those RRSIGs the reply can't be
validated.

This problem with 1.1.1.1 seems to extend to many more .mil domains.

TL;DR. Not a dnsmasq problem, not a domain problem, probably a
Cloudflare problem.

Craig, please could you report this to Cloudflare?


Cheers,

Simon.



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


Re: [Dnsmasq-discuss] Cannot look up disa.mil (dnssec related)

2018-10-22 Thread Simon Kelley
On 22/10/2018 17:56, Craig Andrews wrote:
> I'm unable to look up *.disa.mil when using dnsmasq - I'm hoping that we
> can figure out why that is.
> 
> I have dnsmasq configured to use Cloudflare's 1.1.1.1 as its upstream
> DNS server; dnsmasq is running on 192.168.0.1.
> 
> Here are some a couple tests demonstrating the problem:
> --
> $ dig disa.mil @192.168.0.1 +dnssec +short
> 
> $ dig disa.mil @8.8.8.8 +dnssec +short
> 156.112.108.76
> A 8 2 7200 20181117145327 20181018145327 52983 disa.mil.
> dMS5WbQ5xJ0HuCBPZUkuoshf0A2n1tvxA75smhcFZNS5SHSOA0zsQaSc
> YOzNdu5gH6qFXA7TbKhPYN0RcPD+vVcmtfbzv3eJZfh4343IXlBznG6w
> aLaLt+kI6GGnPQ7skNWOcO4yLct+yaeNxTT95CZnHtwRUx3vzGHS3dJF GYc=
> [candrews@craigatwork vars]$ dig disa.mil @1.1.1.1 +dnssec +short
> 156.112.108.76
> --
> So looking it up using Google's 8.8.8.8 or Cloudflare's 1.1.1.1 with
> dnssec works, but not with dnsmasq.
> 
> --
> # dnsmasq --version
> Dnsmasq version 2.80test3  Copyright (c) 2000-2018 Simon Kelley
> Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6
> no-Lua TFTP conntrack ipset auth DNSSEC no-ID loop-detect inotify dumpfile
> 
> This software comes with ABSOLUTELY NO WARRANTY.
> Dnsmasq is free software, and you are welcome to redistribute it
> under the terms of the GNU General Public License, version 2 or 3.
> --
> 
> Thanks in advance for your help and for this great software,
> ~Craig

I can reproduce this, and checking with DNSviz doesn't show any problems
with the domain, so this could well be a dnsmasq/DNSSEC problem.

I'll try and find time to do some forensics on it in the next day or two.


Cheers,

Simon.




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] WG: AW: AW: clients of DHCPv6 with constructed IPv6 address range are not notified on address range change

2018-10-19 Thread Simon Kelley
On 18/10/2018 20:32, Andrey Vakhitov wrote:
> Hello Simon,
> 
> the patch seems to work reliable, I've not seen any glitches so far. I'd 
> suggest to apply it to main branch.

The patch is in 2.80, released yesterday.

Simon.

> 
> -Ursprüngliche Nachricht-
> Von: Andrey Vakhitov  
> Gesendet: Samstag, 6. Oktober 2018 20:31
> An: 'Simon Kelley' ; 
> 'dnsmasq-discuss@lists.thekelleys.org.uk' 
> 
> Betreff: AW: AW: AW: [Dnsmasq-discuss] clients of DHCPv6 with constructed 
> IPv6 address range are not notified on address range change
> 
> Hello Simon,
> 
>>> I've reactivated the patch locally and observing it since 4 days. 
>>> Todays night associated
>>> IPv6 names got lost again directly during IP prefix change process, 
>>> the log shows it clearly (see log 1). So I would vote again for 
>>> retrying during some extended timeframe even if the host isn't reachable.
> 
>> OK, done. Patch is here:
>>
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ee1df06aabaa
>> 8f212eaa7102f6d62cb25bfb35e9
> 
> Thanks a lot for your great support! I've applied the patch and will monitor 
> the behaviour.
> 
> Best Regards,
> --
> Andrey Vakhitov
> 
> E-Mail:  and...@vakhitov.netStuttgart, Germany
> 
> 
> 
> 
> 


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


[Dnsmasq-discuss] Announce: dnsmasq-2.80

2018-10-18 Thread Simon Kelley
I just published dnsmasq-2.80, available at

http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.80.tar.gz

Changelog attached below.


Cheers,

Simon.


version 2.80
Add support for RFC 4039 DHCP rapid commit. Thanks to Ashram
Method for the initial patch and motivation.

Alter the default for dnssec-check-unsigned. Versions of
dnsmasq prior to 2.80 defaulted to not checking unsigned
replies, and used --dnssec-check-unsigned to switch
this on. Such configurations will continue to work as before,
but those which used the default of no checking will need to be
altered to explicitly select no checking. The new default is
because switching off checking for unsigned replies is
inherently dangerous. Not only does it open the possiblity of   
forged replies, but it allows everything to appear to be working
even when the upstream namesevers do not support DNSSEC, and in
this case no DNSSEC validation at all is occuring.

Fix DHCP broken-ness when --no-ping AND --dhcp-sequential-ip
are set. Thanks to Daniel Miess for help with this.

Add a facilty to store DNS packets sent/recieved in a
pcap-format file for later debugging. The file location
is given by the --dumpfile option, and a bitmap controlling
which packets should be dumped is given by the --dumpmask
option.

Handle the case of both standard and constructed dhcp-ranges on
the same interface better. We don't now contruct a dhcp-range if
there's already one specified. This allows the specified
interface to have different parameters and avoids advertising
the same prefix twice. Thanks to Luis Marsano for spotting this
case.

Allow zone transfer in authoritative mode if auth-peer is
specified, even if auth-sec-servers is not. Thanks to Raphaël
Halimi for the suggestion.

Fix bug which sometimes caused dnsmasq to wrongly return answers
without DNSSEC RRs to queries with the do-bit set, but only when
DNSSEC validation was not enabled.
Thanks to Petr Menšík for spotting this.

Fix missing fatal errors with some malformed options
(server, local, address, rebind-domain-ok, ipset, alias).
Thanks to Eugene Lozovoy for spotting the problem.

Fix crash on startup with a --synth-domain which has no prefix.
Introduced in 2.79. Thanks to Andreas Engel for the bug report.

Fix missing EDNS0 section in some replies generated by local
DNS configuration which confused systemd-resolvd. Thanks to
Steve Dodd for characterising the problem.

Add --dhcp-name-match config option.

Add --caa-record config option.

Implement --address=/example.com/# as (more efficient) syntactic
sugar for --address=/example.com/0.0.0.0 and
--address=/example.com/::
Returning null addresses is a useful technique for ad-blocking.
Thanks to Peter Russell for the suggestion.

Change anti cache-snooping behaviour with queries with the
recursion-desired bit unset. Instead to returning SERVFAIL, we
now always forward, and never answer from the cache. This
allows "dig +trace" command to work.

Include in the example config file a formulation which
stops DHCP clients from claiming the DNS name "wpad".
This is a fix for the CERT Vulnerability VU#598349.





signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Duplicate IP detection with fixed IP

2018-10-15 Thread Simon Kelley
On 08/10/18 11:39, Bernard CLABOTS wrote:

> => So My iPhone is legit.
> 
> "Servers with knowledge of the client's configuration parameters
> 
>   respond with a DHCPACK message to the client.  Servers SHOULD NOT
>   check that the client's network address is already in use; the
>   client may respond to ICMP Echo Request messages at this point."
> 
> => Invalidates the fix you did in 2017:
> "
> 
> commit 5ce3e76fbf89e942e8c54ef3e3389facf0d9067a
> 
> Author: Simon Kelley 
> 
> Date:   Fri Apr 28 22:14:20 2017 +0100
> 
>  
> 
>     DHCPv4: do ICMP-ping check in all cases other that current lease.
> 
> "


This was partially reverted in 1d224949cced9e82440d00b3dbaf32c262bac2ff



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


[Dnsmasq-discuss] Announce: dnsmasq-2.80rc1

2018-10-15 Thread Simon Kelley
As far as I'm aware, the development tree is in a good state at the
moment, and I'd like to begin the process to release 2.80. Accordingly
I've tagged the first release candidate.

A tarball is available here:

http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.80rc1.tar.gz

Please, if you can, download, build and test.


Cheers,

Simon.




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] multiple soa

2018-10-15 Thread Simon Kelley
I have to confess I never considered this as a valid possibility, but to
does make sense, maybe.

The sane, backward-compatible way to do it might be to extend the syntax
of auth-soa, to allow a zone name to be included, so your second
auth-soa line would become

auth-soa=sub.mobile-test.ru,2018101101,sub.mobile-test.example.ru,120,120,604800

So, no, you can't do this with the existing code, sorry. It's a possible
future enhancement.

Cheers,

Simon.



On 15/10/18 20:43, Алексей Кузнецов wrote:
> no chance?
> 
> On Thu, Oct 11, 2018 at 7:08 PM Алексей Кузнецов
> mailto:kuznetsovalexe...@gmail.com>> wrote:
> 
> # My zones and their subnets
> auth-zone=mobile-test.example.ru 
> auth-zone=ns1.mobile-test.example.ru 
> 
> 
> # SOA config
> auth-soa=2018101101,mobile-test.example.ru
> ,120,120,604800
> 
> # Slave NS: nameserver2.provider.com
>  (50.60.70.80)
> # Secondary NS (slave NS at IT)
> auth-sec-servers=msk-dc1.example.ru 
> auth-sec-servers=msk-dc2.example.ru 
> auth-sec-servers=msk-dc3.example.ru 
> auth-sec-servers=msk-DC1.example.ru 
> auth-sec-servers=msk-DC2.example.ru 
> auth-sec-servers=msk-DC3.example.ru 
> # Allow zone transfers to secondary NS
> auth-peer=172.17.8.75
> auth-peer=172.17.8.74
> auth-peer=172.17.8.7
> 
> # Authoritative DNS on interface eth0
> auth-server=ns1.mobile-test.example.ru
> ,ens160
> 
> If i add these lines
> auth-zone=sub.mobile-test.example.ru 
> auth-soa=2018101101,sub.mobile-test.example.ru
> ,120,120,604800
> i have error
> dnsmasq[10843]: dnsmasq: syntax check OK.
> dnsmasq[10847]: dnsmasq: illegal repeated keyword at line 29 of
> /etc/dnsmasq.d/dnsmasq.conf
> 
> line 29 is auth-soa=2018101101,sub.mobile-test.example.ru
> ,120,120,604800
> 
> On Wed, Oct 10, 2018 at 1:40 PM Petr Mensik  > wrote:
> 
> Second soa in one zone cannot be added. One zone has one soa.
> Can you
> please share relevant configuration parts?
> 
> On 10/09/2018 11:46 AM, Алексей Кузнецов wrote:
> > Hello, i set zone with soa record and its work fine. I want
> add second soa
> > zone but dnsmasq say dublicate options in config. How to add
> second soa?
> >
> >
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> 
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
> 
> -- 
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com   PGP:
> 65C6C973
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] IETF RFC 5011 "Automated Updates of DNS Security (DNSSEC) Trust Anchors" supported?

2018-10-15 Thread Simon Kelley
On 11/10/18 00:28, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> Hi,
> 
> the old root-KSK will be deleted today at 16:00 UTC and the TTLs will
> run out not later than 48 hours.
> 
> Does Dnsmasq support IETF RFC 5011 or are there any plans to implement
> IETF RFC 5011?
> 

No, and probably not.

My take on this is that anything running dnsmasq has net access, by
definition, and really should have a method of doing automatic updates
for security fixes, etc. As such it has a method of authentication put
in place by the software providers, and that is the best way to update
the root key.


The RFC5011 method is surprisingly limited. Any software image with only
has the original key "baked in" will not update to the new key using
RFC5011 now, since 5011 relies on a period when the new key is published
and the old still trusted during which the host is active.


Cheers,

Simon.

> Regards,
> 
> Renne
> 
> ___
> 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


Re: [Dnsmasq-discuss] Release of V2.80

2018-10-10 Thread Simon Kelley



On 10/10/18 03:35, Donald Muller wrote:
> Hi Simon,
>  
> I believe that a while ago you mentioned that you were going to be
> releasing 2.80 soon. Do you have a target date yet?
>  

The trite answer to this is always "when it's ready".

There have been two or thee issues over the last week or two that came
up, and needed to be fixed before 2.80. I think they are all done now,
so I intend to make the first release candidate in the next day or two,
unless someone finds another show-stopper!


Cheers,

Simon.


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


Re: [Dnsmasq-discuss] Large AXFR through dnsmasq causes dig to hang with partial results

2018-10-10 Thread Simon Kelley



On 10/10/18 11:02, Connor Bell wrote:
> Hi everyone,
> 
>  
> 
> I’ve had a strange issue I’ve been trying to resolve over the past few
> days where dnsmasq seems to only be allowing part of a zone transfer
> through, causing dig to hang.
> 
>  
> 
> I opened a Stackoverflow post to track it with most of the information
> I’ve found.
> 
> https://serverfault.com/questions/933956/large-axfr-through-dnsmasq-causes-dig-to-hang-with-partial-results
> 
> 
>  
> 
> With a tcpdump comparing a request with dnsmasq acting as forwarder and
> without, I can see in both cases that the upstream bind server replies
> with two packets, 2521 bytes and 189 bytes. When digging dnsmasq, the
> first packet is read out correctly and dig sits and waits for the second
> packet, which for some reason it never seems to receive.
> 
>  

A single packet of 2521 bytes doesn't seem to correspond with the
transfer hanging after 700 lines - it's pretty difficult to get 700
lines of output from one 2500 bytes packet, I think.

I suspect that what's happening is that the zone transfer exceeds 65536
bytes,
which is the limit for a single mesage over TCP. AXFR have special-case
continuation methods to push the transfer into multiple messages. (if
the message doesn't end with a repeat of the SOA record at the start of
the transfer, then expect further messages)

Dnsmasq, forwarding replies in TCP mode, was never really designed with
AXFR in mind, and doesn't implement this function.

Does it really make sense to do AXFR through dnsmasq: surely you'd talk
directly to the authoritative sever for the domain of interest?


Cheers,

Simon.

> When digging bind directly, dig receives both packets and reads out the
> answer correctly. I’m guessing I’m hitting a packet size limit causing
> it to split the response, but why does dig not receive the second packet
> from dnsmasq?
> 
>  
> 
> Kind regards,
> 
> Connor Bell
> 
> 
> 
> ___
> 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


Re: [Dnsmasq-discuss] TCP DNSSEC request over IPv6 abandoned in v2.79

2018-10-05 Thread Simon Kelley
On 05/10/18 06:06, Josh Soref wrote:
> Simon Kelley  wrote:
>> You say "When I perform DNSSEC validation over IPv6" which implies, but
>> doesn't state, that the same test works when talking to usptream DNS
>> servers over IPv4? Is that the case? Certainly, a quick test here works
>> over IPv4. I'm wondering if I need to resurrect my severely bit-rotted
>> IPv6 tunnel setup?
> 
> Fwiw, I found https://tunnelbroker.net/ to be very easy to set up...
> (Everything else related to dns is harder...)
> 

I used to use sixxs, but that's gone now.

My ISP (EE) seems to be rolling out IPv6, so it might be best to try and
get the stuff at this end set up for that. Being mobile makes it all
more difficult.



Cheers,

Simon.

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


Re: [Dnsmasq-discuss] Authoritative and recursive service from the same interface

2018-10-05 Thread Simon Kelley
On 28/09/18 23:46, Simon Kelley wrote:
> On 28/09/18 23:07, Marc Heckmann wrote:
>> Very nice, I will test this.
>>
>> I am curious though: what will be used for the NS record if the
>> auth-server configuration is omitted?
> 
> 
> It appears to return an NS record of "." ie the DNS root. Which is not
> particularly sensible. This may need some more thought
> 


With a little more clarity of thought, it's clear that omitting
auth-server is not sensible, but it should be possible to omit the
interface name(s) from auth-server.

I just pushed an update which does this: it crashes with an error if an
auth-zone is defined bu there is no auth-server. It allows auth-server
to have no interface-names or addresses, just the glue record domain name.



Cheers,

Simon.

> Simon.
> 
>>
>> -m
>>
>>
>> On Fri, Sep 28, 2018 at 4:42 PM Simon Kelley > <mailto:si...@thekelleys.org.uk>> wrote:
>>
>> On 28/09/18 02:33, Marc Heckmann wrote:
>> > Hello,
>> >
>> > I'm currently running dnsmasq in a Docker container and have setup a
>> > domain for which dnsmasq is to be authoritative for. This is to do
>> > subdomain delegation to the dnsmasq server. I am using the
>> auth-server &
>> > auth-zone configuration options for this. This works as expected
>> and is
>> > verifiable using dig with the "+norecurse" option to query for the NS
>> > and SOA records. However, as it's a Docker container, I only have and
>> > actually need a single interface (eth0) and when I specify eth0 in the
>> > "auth-server" option, i.e "auth-server=,eth0", I noticed
>> > that it stops answering recursive queries for names that it is not
>> > authoritative for.
>> >
>> > I worked around this by replacing "eth0" with an IP that is not
>> present
>> > in the container's network namespace and dnsmasq now does what I want
>> > which is to answer to both non-recursive and recursive queries
>> from the
>> > same interface.
>> >
>> > My question is the following: Are there any side effects to this hack?
>> > Is there any reason why dnsmasq should not be able to provide
>> recursive
>> > and authoritative service from the same interface? I can
>> understand the
>> > security reasons for wanting to prevent this on an Internet exposed
>> > interface, but why not at allow for an option to officially support
>> > providing both kinds of service on the same interface?
>> >
>> > Thanks.
>> >
>> > -m
>> >
>> >
>>
>>
>> This patch, in the pending 2.80 release, addresses this, is allows you
>> to omit the auth-server configuration and get both recursive and
>> authoritative answers on the interface(s) that dnsmasq is listening on.
>>
>> 
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=397c0502e255ea0a470982666dea93e0b2f52043
>>
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>> >
>> > ___
>> > Dnsmasq-discuss mailing list
>> > Dnsmasq-discuss@lists.thekelleys.org.uk
>> <mailto: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
>> <mailto: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


Re: [Dnsmasq-discuss] Authoritative and recursive service from the same interface

2018-09-28 Thread Simon Kelley
On 28/09/18 23:07, Marc Heckmann wrote:
> Very nice, I will test this.
> 
> I am curious though: what will be used for the NS record if the
> auth-server configuration is omitted?


It appears to return an NS record of "." ie the DNS root. Which is not
particularly sensible. This may need some more thought

Simon.

> 
> -m
> 
> 
> On Fri, Sep 28, 2018 at 4:42 PM Simon Kelley  <mailto:si...@thekelleys.org.uk>> wrote:
> 
> On 28/09/18 02:33, Marc Heckmann wrote:
> > Hello,
> >
> > I'm currently running dnsmasq in a Docker container and have setup a
> > domain for which dnsmasq is to be authoritative for. This is to do
> > subdomain delegation to the dnsmasq server. I am using the
> auth-server &
> > auth-zone configuration options for this. This works as expected
> and is
> > verifiable using dig with the "+norecurse" option to query for the NS
> > and SOA records. However, as it's a Docker container, I only have and
> > actually need a single interface (eth0) and when I specify eth0 in the
> > "auth-server" option, i.e "auth-server=,eth0", I noticed
> > that it stops answering recursive queries for names that it is not
> > authoritative for.
> >
> > I worked around this by replacing "eth0" with an IP that is not
> present
> > in the container's network namespace and dnsmasq now does what I want
> > which is to answer to both non-recursive and recursive queries
> from the
> > same interface.
> >
> > My question is the following: Are there any side effects to this hack?
> > Is there any reason why dnsmasq should not be able to provide
> recursive
> > and authoritative service from the same interface? I can
> understand the
> > security reasons for wanting to prevent this on an Internet exposed
> > interface, but why not at allow for an option to officially support
> > providing both kinds of service on the same interface?
> >
> > Thanks.
> >
> > -m
> >
> >
> 
> 
> This patch, in the pending 2.80 release, addresses this, is allows you
> to omit the auth-server configuration and get both recursive and
> authoritative answers on the interface(s) that dnsmasq is listening on.
> 
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=397c0502e255ea0a470982666dea93e0b2f52043
> 
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> <mailto: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
> <mailto: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


Re: [Dnsmasq-discuss] Authoritative and recursive service from the same interface

2018-09-28 Thread Simon Kelley
On 28/09/18 02:33, Marc Heckmann wrote:
> Hello,
> 
> I'm currently running dnsmasq in a Docker container and have setup a
> domain for which dnsmasq is to be authoritative for. This is to do
> subdomain delegation to the dnsmasq server. I am using the auth-server &
> auth-zone configuration options for this. This works as expected and is
> verifiable using dig with the "+norecurse" option to query for the NS
> and SOA records. However, as it's a Docker container, I only have and
> actually need a single interface (eth0) and when I specify eth0 in the
> "auth-server" option, i.e "auth-server=,eth0", I noticed
> that it stops answering recursive queries for names that it is not
> authoritative for.
> 
> I worked around this by replacing "eth0" with an IP that is not present
> in the container's network namespace and dnsmasq now does what I want
> which is to answer to both non-recursive and recursive queries from the
> same interface.
> 
> My question is the following: Are there any side effects to this hack?
> Is there any reason why dnsmasq should not be able to provide recursive
> and authoritative service from the same interface? I can understand the
> security reasons for wanting to prevent this on an Internet exposed
> interface, but why not at allow for an option to officially support
> providing both kinds of service on the same interface?
> 
> Thanks.
> 
> -m
> 
> 


This patch, in the pending 2.80 release, addresses this, is allows you
to omit the auth-server configuration and get both recursive and
authoritative answers on the interface(s) that dnsmasq is listening on.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=397c0502e255ea0a470982666dea93e0b2f52043



Cheers,

Simon.


> 
> ___
> 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


Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers

2018-09-27 Thread Simon Kelley
On 27/09/18 20:54, gravit...@gmx.com wrote:
> Gotcha! :)
> Thank you very much Simon, it is clearly a donge driver bug, since
> DHCPDISCOVER comes indeed with both bytes 2 and 3 =0
> Please, last effort from you, tell me in what file.c did you put that if
> which "falls back to broadcast".
> I will try to patch it myself and bypass it with some kind of new
> option, kind a "--dhcp-unicast", to always force the use of mac, no
> matter what.
> That solution will be *a lot* better than my dirty frames reinjection...
>  


On src/dhcp.c, around line 400


  if ((ntohs(mess->flags) & 0x8000) || mess->hlen == 0 ||
 mess->hlen > sizeof(ifr.ifr_addr.sa_data) || mess->htype == 0)
{
  /* broadcast to 255.255.255.255 (or mac address invalid) */
  dest.sin_addr.s_addr = INADDR_BROADCAST;
  dest.sin_port = htons(daemon->dhcp_client_port);
}
  else
{
  /* unicast to unconfigured client. Inject mac address direct
into ARP cache.


Have fun!



Cheers,

Simon.

> *Sent:* Thursday, September 27, 2018 at 7:43 PM
> *From:* "Simon Kelley" 
> *To:* gravit...@gmx.com, dnsmasq-discuss@lists.thekelleys.org.uk
> *Subject:* Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
> On 27/09/18 20:24, gravit...@gmx.com wrote:
>> Hi Simon,
>> thank you for your answer.
>> I confirm no --dhcp-broadcast option.
>>  
>> I dont really want to bother too much... but if you could just give me a
>> couple of examples of that last thing.
>> I mean, could you just give me a simple example of "hardware address
>> length field is zero or greater than 16"?
>> And/or a simple example of "hardware address type field is zero."?
>> We talking about the ?
>> Or, how can I check on Linux the "hardware address length field" and
>> "hardware address type"?
>>  
> 
> 
> In the DHCPDISCOVER packet, these are bytes 2 and 3. Byte 1 is 1
> (BOOTREQUEST) and byte 2 is the "hardware address type", whilst byte
> three is the "hardware address length", which is typically 6 for what
> people normally think of as MAC addresses.
> 
> 
> Cheers,
> 
> Simon.
> 
>> After that I promise I wont bother anymore ;)
>> Thanks
>>  
>> *Sent:* Wednesday, September 26, 2018 at 4:36 PM
>> *From:* "Simon Kelley" 
>> *To:* dnsmasq-discuss@lists.thekelleys.org.uk
>> *Subject:* Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
>> On 26/09/18 17:33, Simon Kelley wrote:
>>> On 24/09/18 11:45, gravit...@gmx.com wrote:
>>>>
>>>> Amof, the first and only frames my dongle sends on eth at start, are
>>>> some Dhcp DISCOVER, no arps at all.
>>>> Please note that such Dhcp DISCOVER frames come with the broadcast bit
>>>> NOT set.
>>>> Afaik, that meas my dongle is indeed asking the Dhcp server to send a
>>>> unicast response, directly to its mac.
>>>> Instead QNSMASQ sends those Dhcp OFFER frames to broadcast.
>>>> Why it happens so?
>>>>  
>>>
>>> I can offer two reasons why it might be so. The first is that there's a
>>> bug in dnsmasq, which is not unheard-of, but this is old code and a bug
>>> has not been observed before. The second is that you're running dnsmasq
>>> configured to always send broadcasts, using the --dhcp-broadcast option.
>>>
>>> Check all the dnsmasq configuration files, that's the sort of thing that
>>> gets slipped in because is solves someone's problem one time, and "it
>>> can't do any harm".
>>>
>>>
>>
>> Looking at the code, it also falls back to broadcast if the "hardware
>> address length field is zero or greater than 16, or if the "hardware
>> address type" field is zero.
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>> ___
>> 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


Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers

2018-09-27 Thread Simon Kelley
On 27/09/18 20:24, gravit...@gmx.com wrote:
> Hi Simon,
> thank you for your answer.
> I confirm no --dhcp-broadcast option.
>  
> I dont really want to bother too much... but if you could just give me a
> couple of examples of that last thing.
> I mean, could you just give me a simple example of "hardware address
> length field is zero or greater than 16"?
> And/or a simple example of "hardware address type field is zero."?
> We talking about the ?
> Or, how can I check on Linux the "hardware address length field" and
> "hardware address type"?
>  


In the DHCPDISCOVER packet, these are bytes 2 and 3. Byte 1 is 1
(BOOTREQUEST) and byte 2 is the "hardware address type", whilst byte
three is the "hardware address length", which is typically 6 for what
people normally think of as MAC addresses.


Cheers,

Simon.

> After that I promise I wont bother anymore ;)
> Thanks
>  
> *Sent:* Wednesday, September 26, 2018 at 4:36 PM
> *From:* "Simon Kelley" 
> *To:* dnsmasq-discuss@lists.thekelleys.org.uk
> *Subject:* Re: [Dnsmasq-discuss] No Broadcast Dhcp Offers
> On 26/09/18 17:33, Simon Kelley wrote:
>> On 24/09/18 11:45, gravit...@gmx.com wrote:
>>>
>>> Amof, the first and only frames my dongle sends on eth at start, are
>>> some Dhcp DISCOVER, no arps at all.
>>> Please note that such Dhcp DISCOVER frames come with the broadcast bit
>>> NOT set.
>>> Afaik, that meas my dongle is indeed asking the Dhcp server to send a
>>> unicast response, directly to its mac.
>>> Instead QNSMASQ sends those Dhcp OFFER frames to broadcast.
>>> Why it happens so?
>>>  
>>
>> I can offer two reasons why it might be so. The first is that there's a
>> bug in dnsmasq, which is not unheard-of, but this is old code and a bug
>> has not been observed before. The second is that you're running dnsmasq
>> configured to always send broadcasts, using the --dhcp-broadcast option.
>>
>> Check all the dnsmasq configuration files, that's the sort of thing that
>> gets slipped in because is solves someone's problem one time, and "it
>> can't do any harm".
>>
>>
> 
> Looking at the code, it also falls back to broadcast if the "hardware
> address length field is zero or greater than 16, or if the "hardware
> address type" field is zero.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> ___
> 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


  1   2   3   4   5   6   7   8   9   10   >