That's old code, and pre-dates detailed git logs, but it's fairly clear
that the test is implementing this part of RFC 5107
When servicing a DHCPREQUEST message, the DHCP server would normally
look at the Server Identifier option for verification that the
address specified there is one
I just committed a patch which does this, and some other changes to make
this work better.
Cheers,
Simon.
On 29/12/17 21:56, e9hack wrote:
> Hi,
>
> since some time, the log is flooded with messages like this:
>
> Fri Dec 29 20:53:50 2017 daemon.warn dnsmasq[20961]: reducing DNS packet size
Do you have an interface configured with an address in fd01::/64 ?
Cheers,
Simon.
On 15/01/18 18:03, Matthew Keeler wrote:
> I setup a new vm running version 2.78 of dnsmasq.
>
> I have this in my config:
>
> enable-ra
> dhcp-range=fd01::,ra-stateless,ra-names,64,24h
>
> According to
An interesting problem has turned up in DNSSEC validation. It turns out
that NSEC records expanded from wildcards are allowed, so a domain can
include an NSEC record for *.example.org and an actual query reply could
expand that to anything in example.org and still have it signed by the
signature
Patch applied.
Cheers,
Simon.
On 18/01/18 14:15, Neil Jerram wrote:
> On Sun, Jan 14, 2018 at 10:35 PM Simon Kelley <si...@thekelleys.org.uk
> <mailto:si...@thekelleys.org.uk>> wrote:
>
> On 14/01/18 18:14, Neil Jerram wrote:
> > Thanks for looking at thi
Use log-queries to see what's happening. You should be looking for
outgoing queries which don't see an answer.
Cheers,
Simon.
On 16/01/18 15:34, john doe wrote:
> Hi,
>
> First of all a big thank you for dnsmasq.
> It's an easy dhcp, dns, read only tftp server to configure.
>
>
> On a
My guess is that you need to add the domain to the last two.
eg _sip._tcp gets the domain (as specified to dnsmasq by the domain
keyword) added automatically, so assuming
domain=guido.org
srv-host=_sip._tcp,sipx2.example.org,5060,20,10
You'll get a SRV records called
_sip._tcp.guido.org
once
>
> Beyond “gaaahh why didn’t I think of SIGINT”….. excellent. Understand
> the reasoning, agree, running chez Kevin and backport for LEDE master
> submitted.
>
and there's still SIGQUIT available!
Out of interest, how does the LEDE plumbing deal with a restart of
dnsmasq _after_ ntp
On 14/01/18 18:14, Neil Jerram wrote:
> Thanks for looking at this, Simon. Some thoughts below...
>
> On Sat, Jan 13, 2018 at 5:34 PM Simon Kelley <si...@thekelleys.org.uk
> <mailto:si...@thekelleys.org.uk>> wrote:
>
> I'm in favour, in theory at least
Right, I thought about this again, and concluded that whilst sharing the
"now use the time" function with something other than "reload loads of
stuff" is an improvement, it doesn't really get us that much farther to
share with something else, since conflicts could still arise.
For instance
Patch applied. I hope I'm not walking into an argument here
Cheers,
Simon.
On 05/01/18 07:25, Geert Stappers wrote:
> Happy New Year,
>
>
> What is the judgement on the patch below?
>
> On Wed, Dec 27, 2017 at 08:55:22PM +0100, Geert Stappers wrote:
>> Development of EtherBoot gPXE was
The process umask is explicitly set to 022 in dnsmasq.c, to change that,
you're going to have to edit the source and recompile.
Cheers,
Simon.
On 12/01/18 13:17, BUGHUNTER wrote:
> Hi,
>
> I am trying to set the umask for the logfile generated by dnsmaq, but it
> seems to ignore the way I am
On 24/11/17 19:46, Akram B.A wrote:
> Hi Simon
> Some answers inline sorry for the netiquette
>
> Sent from my iPhone
>
>> On 24 Nov 2017, at 17:56, Simon Kelley <si...@thekelleys.org.uk> wrote:
>>
>> A couple of possible problems with this are as f
On 04/10/17 22:45, Nathan Sullivan wrote:
> Hi Simon,
>
> It looks like there was a regression introduced in v2.69, specifically
> the commit:
>
> commit d68c2ca2b7896d6127f9b32d402f299e0b9cf593
> Author: Simon Kelley <si...@thekelleys.org.uk
> <mailto:si...@thekell
The patch looks good to me.
va_start() needs to be called before any use of CHECK_LIMIT because the
code-path if the check fails always calls va_end().
THe two rfc1035.c patches you refer to are cleanups for problems without
security implications. They are in this commit for the mainline:
I've just released a new stable version of dnsmasq 2.78
Download is available at
http://thekelleys.org.uk/dnsmasq/dnsmasq-2.78.tar.gz
This is a bugfix release, and, amongst other things, addresses a set of
serious security vulnerabilities. Update should be mandatory.
CHANGELOG is attached
I've just released dnsmasq-2.78, which addresses a series of serious
security vulnerabilities which have been found in dnsmasq by the Google
security team. Some of these, including the most serious, have been in
dnsmasq since prehistoric times, and have remained undetected through
multiple
On 28/09/17 17:35, Jeff wrote:
> I have a server my.natted.server NAT'ed behind a public firewall, with
> config lines for both of my upstream ISP nameservers:
> server=
> server=
>
> I chose to use both ISP nameservers for redundancy, but this is not a
> requirement.
>
> I see dnsmasq query
> Any news on this one (and the follow up patch)?
Apologies for the radio-silence. Patches applied.
Cheers,
Simon.
signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
Patch applied, thanks
(and your name is in the git-log, even if it's not in the translation..)
Cheers,
Simon.
On 17/07/17 18:53, Chris Novakovic wrote:
> On 17/07/2017 18:50, Chris Novakovic wrote:
>> Commit 730c6745 makes a number of fixes to typos, among them the
>> messages reporting
>
> Attaching small example patch.
>
> Cheers,
> Petr
>
> Dne 8.7.2017 v 22:27 Simon Kelley napsal(a):
>> I considered not passing SRV record names to IDN, but I can forsee
>> more subtle problems (We allow _ in hostnames, for instance.) So I've
>> fix
Thanks everyone who's been working on this, and apologies for going MIA
until now.
Looking through the code, I think I can seen what's happening:
memset(((char *)header) + qlen, 0,
(limit - ((char *)header)) - qlen);
Concentrate on the calculation of the length of the memset
(limit
id 3 suspend+thaw
> cycles with no segv).
>
> Thanks.
>
> Bye
> Arne
>
>
> Simon Kelley <si...@thekelleys.org.uk> schrieb am 18:07 Samstag, 22.Juli
> 2017:
>
>
> On 21/07/17 12:17, AW wrote:
>
>> Hi!
>>
>> Is there anything new
On 21/07/17 12:17, AW wrote:
> Hi!
>
> Is there anything new in 2.77 (compared to 2.76), that might cause a
> segmentation fault directly after a file has been sent?
> Jul 16 09:24:01 neo dnsmasq-tftp[1967]: sent
> /var/dnsmasq/tftpboot/pxe/x86_64-efi/core.efi to 192.168.1.2
> Jul 16 09:24:01 neo
On 29/06/17 06:37, Todd Sankey wrote:
> On our guest network we often have visitors that stay for a few days
> coming and going. We also have a few itinerant workers who show up every
> few weeks for a few days. Then there is the set of one-time visitors.
>
> The current mechanism of address
Looking at the code, a prefix is only advertised if and address with the
prefix exists on the interface AND the prefix length on the interface is
less than or equal to the prefix being advertised.
My IPv6 foo is not up to justifying that at the moment, but it certainly
explains what you are
For query that's going to a subdomain, the only behaviour available is
that the first attempt at the query goes to one of the available servers
(it's not specified which one), and if the query is retried, it's sent
to all the available servers.
Cheers,
Simon
On 05/07/17 18:55, Dev Sidious
I considered not passing SRV record names to IDN, but I can forsee
more subtle problems (We allow _ in hostnames, for instance.) So I've
fixed this, for some value of "fixed", by not passing any domain name
being parsed, which has one or more underscores, to IDN.
That seems a reasonable
On 04/07/17 09:06, Chris Novakovic wrote:
> On 03/07/2017 15:53, Brian Rak wrote:
>> I'd like to be able to classify DHCP requests based on the interface
>> they come in on. I'd like to have a tag based on the interface name
>> (so, if the request came in over br0, I'd have a br0 tag to match
Also, insure that TCP connections to 8.8.8.8 and 8.8.4.4 are not being
blocked in your firewall.
Cheers,
Simon.
On 03/07/17 09:35, Hamish Moffatt wrote:
> On 29/06/17 09:42, Hamish Moffatt wrote:
>> On 29/06/17 07:05, Simon Kelley wrote:
>>> Your text says 2.75, but the log
=361dfe515879b5adabf3702b8be692c4fb6bf3a7
Is there any way you could upgrade to 2.77?
Cheers,
Simon.
On 03/07/17 09:35, Hamish Moffatt wrote:
> On 29/06/17 09:42, Hamish Moffatt wrote:
>> On 29/06/17 07:05, Simon Kelley wrote:
>>> Your text says 2.75, but the log says 2.76. There's a signific
On 22/06/17 14:12, Jason A. Donenfeld wrote:
> Hello Simon,
>
> In dnsmasq.conf:
>
> interface-name=martino,lan # 10.10.10.1, 2a07:f32:8fe8:8a61::1
> interface-name=martino,guest # 10.11.0.1, 2a07:f32:8fe8:8a63::1
> interface-name=martino,remote # 10.10.11.1, 2a07:f32:8fe8:8a62::1
>
On 28/06/17 13:25, Keith Lyons wrote:
> I have Dnsmasq configured for option 82 for three different subents:
> 10.192.4.x, 10.192.5.x and 10.192.9.x, all of the clients get the proper
> IP's as expected via the Option 82 statements, but the 10.192.5 and
> 10.192.9.x clients are getting the Gateway
Look at --localise-queries inthe dnsmasq man page. That may be the
solution you're looking for.
Cheers,
Simon.
On 27/06/17 18:22, Oliver Rath new wrote:
> Hi List,
>
> I have same szenario with 4 NICs with different address-spaces:
>
> 192.168.96.0/24
>
> 192.168.97.0/24
>
>
On 28/06/17 03:20, Rosen Penev wrote:
> AFAIK Clang and GCC both support it. Any other relevant compilers?
>
>
What do *BSD use? dnsmasq supports them? Policy is C89 and always has been.
Cheers,
Simon.
> On Tue, Jun 27, 2017, 15:40 Simon Kelley <si...@thekelleys.org.
Patch applied, with the exception of the gcc-specific __attribute__ stuff.
Cheers,
Simon.
On 27/06/17 00:37, Rosen Penev wrote:
> ---
> contrib/lease-tools/dhcp_lease_time.c | 8
> src/auth.c| 6 +++---
> src/cache.c | 2 +-
>
Dnsmasq is licensed under the Gnu GPL, which gives you the right to use
it for commercial purposes. There is plenty of information on the net
about exactly what you can a can't do under the GPL, but unless you want
to modify dnsmasq and distribute the results without making the source
code
n the strict-order
> option to try and circumvent this.
>
> Roger
>
>
> On 27 June 2017 10:31:59 am Simon Kelley <si...@thekelleys.org.uk> wrote:
>
>> What's probably happening is this.
>>
>> 1) query arrives from client,
>> 2) UDP socket o
REFUSED is returned if dnsmasq has no upstream server configured it can
send to, or if there are a very large number of queries in flight, and
the internal table tracking them is full. You could try bumping the
dns-forward-max
parameter if you have a very busy network.
Cheers,
Simon.
On
Can you reproduce the crash? What triggers it?
2.55 is seven years old now, and predates our use of git, so it's pretty
difficult to point to a fix, but I suspect that this bug is long gone.
Finding how to reproduce it and showing that it doesn't happen with
newer releases would be the best way.
On 16/06/17 18:16, Jason A. Donenfeld wrote:
> Hey Simon,
>
> Fast forward 5 years from when I wrote the original ipset patch for
> dnsmasq, and I too have a need for nftables support with it. Did you
> ever figure out how to add nft sets to dnsmasq? If not, maybe I'll
> take a stab at it in the
On 14/06/17 14:46, Hans Dedecker wrote:
> If a DNS server replies REFUSED for a given DNS query in strict order mode
> no failover to the next DNS server is triggered as the logic in reply_query
> excluded strict order mode by mistake.
The above may well be true.
>
> Also checking for not strict
Matthias,
No problem. We've all been there. There has been more than one broken
release as a result of my mistakes. It's part of the reality we inhabit.
Cheers,
Simon.
On 07/06/17 21:08, Matthias Andree wrote:
> Am 07.06.2017 um 00:06 schrieb Simon Kelley:
>> Ugh. Apologies fo
The debian packaging is managed in the same git repository as the rest
of the source code ('cause I'm the Debian maintainer). It's removed from
the release tarballs, but if you get a snapshot from the gitweb pages,
you get the complete thing.
Ugh. Apologies for letting that one through. How annoying.
I've committed Chris's patch into git.
I'll leave it a week or two in case anything similar emerges, and then
push another release.
Cheers,
Simon.
On 06/06/17 14:17, Steven Shiau wrote:
>
> On 2017/06/06 05:30, Chris Novakovic
On 23/05/17 07:05, Andriy Gapon wrote:
> On 23/05/2017 01:14, Simon Kelley wrote:
>> To the best of my knowledge it's _only_ PXE clients which can accept
>> extra options from a proxy. PXE is a superset of DHCP, which includes
>> that functionality. The DHCP clients r
On 23/05/17 13:09, Floris Bos wrote:
> On 05/11/2017 01:36 PM, Simon Kelley wrote:
>> As stated in the thread you link to, if you're netbooting an OS via PXE
>> then one the OS starts, it will do DHCP again, and that's the time to
>> send arbitrary options.
>
> Re
On 12/05/17 15:35, Andriy Gapon wrote:
> On 11/05/2017 14:36, Simon Kelley wrote:
>> The design is that dnsmasq sends the options expected by a PXE client if
>> it's acting as a proxy (because the whole proxy thing is part of the PXE
>> spec: a normal DHCP client doe
On 12/05/17 16:32, Pali Rohár wrote:
> On Friday 12 May 2017 17:15:20 Simon Kelley wrote:
>> There are so many layers of quotes here that I've completely lost
>> track of what we were trying to achieve, and how to achieve it. My
>> memory is that we'd failed to come up with an
Heads up. I just pushed another release candidate.
http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.77rc5.tar.gz
Cheers,
Simon.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
:49, Matthias Andree wrote:
> Am 20.05.2017 um 22:50 schrieb Simon Kelley:
>> I've just mase the fourth, and probably final, release candidate for
>> dnsmasq-27. Please download, compile and run, and report any problems
>> ASAP. If all looks OK, 2.77 will happen in t
circumstances? If it doesn't, that's your
problem, you're assuming UDP is reliable, when it ain't.
Cheers,
Simon.
On 18/05/17 23:45, Guido Pepper wrote:
> Hello.
> We are running dnsmasq version
>
> /usr/sbin/dnsmasq --version
> Dnsmasq version 2.76 Copyright (c) 2000-2016 Simon K
I've just mase the fourth, and probably final, release candidate for
dnsmasq-27. Please download, compile and run, and report any problems
ASAP. If all looks OK, 2.77 will happen in the next week.
http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.77rc4.tar.gz
Cheers,
Simon.
On 15/05/17 11:20, Kevin Darbyshire-Bryant wrote:
>
>
> On 15/05/17 11:06, Bastian Bittorf wrote:
>> * Simon Kelley <si...@thekelleys.org.uk> [12.05.2017 08:33]:
>>> Oops. "It compiles - ship it" bites back.
>>>
>>> 2.77rc3 fixes
Ah, didn't read this before my previous reply.
dhcp_release is getting called, but dnsmasq is not getting the packet
(dhcp_release works by faking up a DHCP message as if it's coming from
the DHCP client, which tells the server to release the lease.)
If you can't see the packet in your packet
he release packet.
>
> Thanks,
> GP
>
> On 2017-05-17 14:39, Simon Kelley wrote:
>
>> Ah, didn't read this before my previous reply.
>>
>> dhcp_release is getting called, but dnsmasq is not getting the packet
>> (dhcp_release works by faking up a DHCP mes
You're assuming a lot of knowledge of OpenStack which is strictly
off-topic here.
Given that, a couple of observations.
1) If dnsmasq is getting a DHCPELEASE packet, it will log that. Given
you're not seeing that in logs, then either dhcp_release is not being
invoked, or it's getting the wrong
On 09/05/17 10:21, Pali Rohár wrote:
> On Sunday 02 October 2016 11:43:43 Pali Rohár wrote:
>> On Wednesday 27 January 2016 13:37:27 Pali Rohár wrote:
>>> On Wednesday 20 January 2016 20:15:23 Simon Kelley wrote:
>>>> Dnsmasq identifies IPv6 clients via their MA
gfxpayload=800x600x16,800x600 --- auto=true url=dc10b
> DEBCONF_DEBUG=5 tasks= hostname= interface=00:26:9e:03:9d:e5
> partman-auto/disk=/dev/sda
>
>
>
> On Fri, Apr 28, 2017 at 5:53 PM, Simon Kelley
> <si...@thekelleys.org.uk <mailto:si...@thekelleys.or
Oops. "It compiles - ship it" bites back.
2.77rc3 fixes this, and we're currently eating the dog-food chez Kelley.
Cheers,
Simon.
On 11/05/17 15:49, Kevin Darbyshire-Bryant wrote:
>
>
> On 10/05/17 22:31, Simon Kelley wrote:
>> Just committed a patch which sh
You're trying to invent yet another way of solving the "naming IPv6
hosts" problem, made more difficult by the fact that they change
addresses as the delegated prefix changes.
There are a couple of other possibilities.
1) If you're using DHCP for IPv4, look at the dnsmasq "ra-names"
facility,
The design is that dnsmasq sends the options expected by a PXE client if
it's acting as a proxy (because the whole proxy thing is part of the PXE
spec: a normal DHCP client doesn't know how to deal with it.) The
replies to the PXE client are constructed using the information given in
the
Just committed a patch which should make this work again without needing
--no-ping.
I've tagged it as 2.77rc2, so please could a LEDE package be built, and
this behaviour tested.
Cheers,
Simon.
On 10/05/17 14:11, Bastian Bittorf wrote:
> * Simon Kelley <si...@thekelleys.org.uk> [1
OK, answering my own question, Debian support for libidn2 seems to be
rather behind, so at least for now, my life with Debian maintainer hat
on is easier if the option to build with libidn is retained. I shall
commit the patch forthwith.
Cheers,
Simon.
On 09/05/17 23:12, Simon Kelley wrote
On 10/05/17 14:11, Bastian Bittorf wrote:
> * Simon Kelley <si...@thekelleys.org.uk> [10.05.2017 15:05]:
>> I wonder if this is to do with the extension of the ping-test to more
>> cases. Please could you try adding
>>
>> no-ping
>>
>> to the config, an
Yes. I'll look at putting code to suppress the ARP check. on loopback.
Cheers,
Simon.
On 10/05/17 14:11, Bastian Bittorf wrote:
> * Simon Kelley <si...@thekelleys.org.uk> [10.05.2017 15:05]:
>> I wonder if this is to do with the extension of the ping-test to more
>> cases.
root@box:~ dnsmasq -v
> Dnsmasq version 2.77test5 Copyright (c) 2000-2016 Simon Kelley
> Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP
> no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID
> loop-detect inotify
>
> # kernel tested with non working
ted there is problem with lease database. I could then move old
> leases file and retry with empty database from the startup script.
>
> What do you think?
I think that just logging a warning is best. I don't want to add yet
another obscure config option.
Cheers,
Simon.
>
> Dne 29.
On 09/05/17 19:35, Petr Menšík wrote:
> Hi Simon, hi everyone.
>
> Fedora wants to move from IDN 2003 to IDN 2008 support. Dnsmasq already
> supports IDN, but only older version. There is really little of IDN to
> support. I made a patch that allows explicit support for libidn2 along
> with
:
>
>
> On 09/05/17 01:39, Simon Kelley wrote:
>> That was a horrible one.
>>
>> Fix committed, and an optimistic 2.77rc1 tag added.
>
> Sadly a tad optimistic. From the original reporter, and I can confirm
> 'domain-needed' is the crash enabling option:
>
>
That was a horrible one.
Fix committed, and an optimistic 2.77rc1 tag added.
I really hope to get out a 2.77 release soon.
Cheers,
Simon.
On 08/05/17 13:30, Kevin Darbyshire-Bryant wrote:
> Hi Simon,
>
> Got a report in LEDE land about a SIGSEGV issue, I'm able to replicate
> easily as
How do your machines get their IPv6 addresses, and specifically, their
changed IPv6 addresses after the prefix changes.?If you're using DHCPv6
with dnsmasq as the server, then something like this is already
available: if you have a dhcp-range line which has the constructor:
keyword, then you can
This is actually another instance of the parse_hex bug, which caused a
certain amount of confusion.
Anyway, fixes for that and the hostname_isequal() one committed to git.
Thanks for running these tests.
(In case it's not obvious, these are not security problems, since they
rely on malformed
h removing it completely.
>
> If nothing can be done, or be deemed unfeasible to be done, my opinion
> is that not much harm is done, since there is a way of getting things
> working (manual IP).
>
> So, for me (3) it is.
>
> Cheers.
>
> On Fri, Apr 7, 2017 at 11:00
> Simon, is there any chance of a 'test5' bundling all the latest tweaks
> into a tarball? It's much easier to get the LEDE guys to accept a test
> release tarball than it is loads of patchesand it means the code
> would get tested by a wider community.
>
Done.
As soon as we reach a
On 24/04/17 15:42, Petr Mensik wrote:
> Thank you for accepting that patches. I agree that some garbage is
> far more likely to appear in dhcp-script mode. I would myself welcome
> error log from wrong formatted lease file as well. If I understand it
> well, that file will be overwritten after the
On 27/04/17 17:42, Carl Karsten wrote:
> I am looking for the syntax of dhcp vendor options, and then how to
> access them in grub-net. I think. maybe there is a better way.
>
> I pxe boot grub, which boots di (Debian Installer) and pass a preseed file.
>
> I am trying to work out a nice way
On 27/04/17 22:02, Jason Kary wrote:
> Hi Folks,
>
> I have a basic setup for DHCP relay across VLANS in DNSMASQ.
>
> My configuration file looks like:
>
>
> bogus-priv
> interface=ens160
> log-dhcp
> dhcp-range=10.168.102.100,10.168.102.150,255.255.255.0,12h
>
>
> The
> What I did to fix it was to send a NACK to the initial DHCP request,
> which luckily convinced the ISC DHCP client to stop asking for the
> same IP address in the following DHCP discovery. However, NACK will
> not quarantee all DHCP clients will do the same, so the case where
> DHCP discovery
On 24/04/17 10:16, Alin Năstac wrote:
> On Sun, Apr 23, 2017 at 5:46 PM, Simon Kelley <si...@thekelleys.org.uk> wrote:
>> On 20/04/17 10:34, Alin Nastac wrote:
>>> Hosts that migrate from one network to another could request their
>>> old IP address which m
On 20/04/17 10:34, Alin Nastac wrote:
> Hosts that migrate from one network to another could request their
> old IP address which might be already in use by another statically
> configured host. Currently non-authoritative dnsmasq servers will
> ignore such requests, but ISC DHCP client will send
I like this. (Almost) completely backwards compatible, obvious to use,
solves a problem. What do people think?
I think the implementation is over-complex: calling find_config() with
the context set to NULL is all that's needed to implementthe search, but
that's a detail.
Cheers,
Simon.
On
On 22/04/17 07:12, Harald Dunkel wrote:
> Hi folks,
>
> dnsmasq 2.76, as packaged for openBSD 6.1:
>
> dnsmasq.log contains tons of lines like
>
> :
> :
> Apr 22 04:08:46 dnsmasq-dhcp[70140]: not giving name nas1.example.com to the
> DHCP lease of 10.0.0.239 because the name exists in
ter for backward
> compatibility to start with empty leases as before.
>
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com PGP: 65C6C973
>
> - Original Message -
> From: "Simon Kelley" <si...@thekelleys
I like this. Yes, I know you can do it with shell magic, but this is
easier and what I would expect to happen.
I've changed the patch quite a lot:
1) Don't go to large effort to report "never happen" errors from pipe(),
just silently handle them in the same way as fork()
2) Don't do any of this
On 15/04/17 01:39, James Feeney wrote:
> It seems that, every so often, dnsmasq needs to be restarted - unless we blame
> WIDE dhcpv6. Here, dnsmasq has been running for about a week, and a newly
> started dhcpv6 client will show things like this in the log:
>
> dhcp6c[412]:
Patch applied.
Cheers,
Simon.
On 01/04/17 22:27, Floris Bos wrote:
> dnsmasq's startup script seems to assume users always want to use
> dnsmasq as local DNS resolver, and tells resolvconf to put
> "nameserver 127.0.0.1" in /etc/resolv.conf
> The problem with this is that if users just want
On 10/02/17 01:22, Reddeiah Raju Konduru wrote:
> Hi,
>
> I am using dnsmasq 2.72. In dhclient after setting client identifier to
> device mac address, I could see client-identifier option in DISCOVER and
> REQUEST messages. But dhcp server(dnsmasq) not setting client identifier
> option in OFFER
On 10/04/17 00:09, Floris Bos wrote:
> On 04/09/2017 11:28 PM, Simon Kelley wrote:
>> Patch accepted, with one change
>>
>>
>>> snprintf(daemon->namebuff+oldlen,
>>> sizeof(daemon->namebuff)-oldlen, "%.2x-%.2x-%.2x-%.2x-%.2x-%.2x/"
On 30/03/17 12:38, Floris Bos wrote:
> Adds option to delay replying to DHCP packets by one or more seconds.
> This provides a workaround for a PXE boot firmware implementation
> that has a bug causing it to fail if it receives a (proxy) DHCP
> reply instantly.
>
> On Linux it looks up the exact
Patch accepted, with one change
> snprintf(daemon->namebuff+oldlen, sizeof(daemon->namebuff)-oldlen,
> "%.2x-%.2x-%.2x-%.2x-%.2x-%.2x/",
daemon->namebuff is a char *, so sizeof(daemon->namebuff) is 4 or 8 and
sizeof(daemon->namebuff)-oldlen is a negative number which is a large
On 08/04/17 17:33, Patryk Szczygłowski wrote:
> 2017-04-04 22:24 GMT+01:00 Simon Kelley <si...@thekelleys.org.uk>:
>
>> Which version of dnsmasq are you using? I just tested this domain using
>> the development code, and got the correct result.
>>
>
>
> dn
On 08/04/17 12:01, Floris Bos wrote:
> On 04/08/2017 12:00 AM, Simon Kelley wrote:
>>
>> But RFC 6842 assures us that no clients are broken by this change :)
>>
>> The options here, as I see it are
>>
>> 1) revert the change and don't support 6842
>> 2)
On 06/04/17 14:01, Pedro MG Palmeiro wrote:
> Dnsmasq trunk replies are being ignored by some devices, in my case, two
> epson printers (AL-M200).
> Dnsmasq 2.76 works fine.
>
> This could be related with
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;
>
On 30/03/17 12:38, Floris Bos wrote:
> Adds option to delay replying to DHCP packets by one or more seconds.
> This provides a workaround for a PXE boot firmware implementation
> that has a bug causing it to fail if it receives a (proxy) DHCP
> reply instantly.
>
> On Linux it looks up the exact
The overriding objection to this is that it adds to the syntax and
semantics of the resolv-file format, but dnsmasq doesn't "own" that
format: it's actually a libc configuration file, and dnsmasq takes
advantage of the fact that the format is "well known" to extract useful
information from it. If
Which version of dnsmasq are you using? I just tested this domain using
the development code, and got the correct result.
dnsmasq: query[A] patryk.one.pl from 127.0.0.1
dnsmasq: forwarded patryk.one.pl to 8.8.4.4
dnsmasq: forwarded patryk.one.pl to 8.8.8.8
dnsmasq: dnssec-query[DS] pl to 8.8.8.8
This is a real problem, and I plan to look at it (and all the other
stuff I've been ignoring.) ASAP. I'm moving house just now, so very
short of time. If I don't produce something by the end of next week,
please prod me again.
Cheers,
Simon.
On 27/03/17 16:37, Patryk Szczygłowski wrote:
>
On 22/03/17 16:30, Risto Suominen wrote:
> Mar 20 22:12:00 risto-Macmini dnsmasq[30248]: using nameserver
> 8.8.8.8#53(via eth0)
This indicates that dnsmasq has been configured to force the packets to
the upstream server via eth0. To do that requires an operation on the
socket which can only
> v1->v2:
> * Add man page description of the extended server syntax (thanks Simon Kelley)
>
> Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discu
901 - 1000 of 3281 matches
Mail list logo
