2.48 release is now available and includes the fix for this bug.
Cheers,
Simon.
--
DHCP Request Cycle can get caught in infinite loop
https://bugs.launchpad.net/bugs/327703
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bug
Thierry Carrez wrote:
> Simon:
> Good news. Do you plan to push that release to Debian soon ?
>
It went last night, so should be in unstable very soon, if not already.
Cheers,
Simon.
--
DHCP Request Cycle can get caught in infinite loop
https://bugs.launchpad.net/bugs/327703
You received this
Public bug reported:
Binary package hint: debian-installer
The netboot.tar.gz tarball has symlinks at the top level from pxelinux.0 to
ubuntu-installer/$ARCH/pxelinux.0 and pxelinux.cfg to
ubuntu-installer/$ARCH/pxelinux.cfg
This causes a problem is more than one arch netboot is installed, or i
Simon Kelley here: I'm the principal author of dnsmasq.
I have a couple of questions for FactTech:
1) Was the text message in the DHCPNAK log entry the same as the initial
reporter's ("address reserved")?
2) Is there any other dhcp-host line in the dnsmasq configuration w
I think I've deduced what is happening here. The combination of the
dhcp-host line and the /etc/hosts entry generates the equivalent of
dhcp-host=name,192.168.X.X
When you run Ubuntu, the DHCP requests send the name, so dnsmasq find
and uses this line, and all is good.
When the machine was reboo
Because a DHCP server has to cope with "strange" packets from
unconfigured and half-configured clients, it's not possible always to
bind the DHCP listening socket to an IP address. However, when --bind-
interfaces is set, dnsmasq does set the SO_REUSEADDRESS flag on the
socket, so that it is possib
A useful bit of information here: ISC dhcpd uses raw sockets to grab
incoming packets before they pass through the IP stack and IP tables, it
therefore doesn't suffer from problems caused by broken firewall rules.
Dnsmasq uses standard IP sockets so that all incoming packets are
filtered by iptable
Thierry Carrez wrote:
> @Simon: what are the options from a dnsmasq perspective ?
>
Some background: dnsmasq can run in two modes.
Default mode: dnsmasq binds the wildcard address and does network magic
to determine which interface request packets actually come from, so that
the results can be
Emmet Hikory wrote:
>>From a brief look at the code, it appears that the relevant section is
> in src/dnsmasq.c : 169-189. In this mode, if unable to access an
> interface because it doesn't exist, dnsmasq should poll the interface
> for a configurable timeout to see if it becomes available before
Something else that's required: we need to stop a libvirt-started
dnsmasq from picking up configuration left around by a removed system
dnsmasq, so the start-dnsmasq pseudo-code in libvirt becomes.
echo dhcp-range=interface:virt0, >/etc/dnsmasq.d/libvirtf
if system dnsmasq is not installed or
Emmet Hikory wrote:
> Actually, I filed this bug more as a result of the comments in the
> libvirt code, which indicate that at least one user of dnsmasq found it
> unable to accomplish an operation that seemed to make sense based on the
> documentation with a particular corner-case configurati
More context from the dnsmasq side of things:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-
discuss/2009q4/003369.html
Missing from the public archive is the result of adding "ip addr show"
to the dnsmasq startup script, it looks like this:
1: lo: mtu 16436 qdisc noop state DOWN
link/l
Worryingly, I've just encountered this whilst doing a dist-upgrade from
9.04 to 9.10. The 9.04 installation was a complete re-partition and
install on an Acer Aspire one, so it's possible that the remains of the
toy Linux distro it came with caused the confusion; also possible is
that the problem
dhcp-range for static ranges is
dhcp-range=,static,..
ie, there's only one address before the static keyword.
Simon.
On 28/10/2018 12:55, Lutz Heitmüller wrote:
> Public bug reported:
>
> Description:Ubuntu 18.04.1 LTS
> Release:18.04
> __
> dnsmasq:
> Insta
tftp-root is a security feature. The tftp protocol is entirely
unauthenticated, and if a request was allowed to go outside the
specified root directory, than that effectively makes all readable files
on the host available for internet-wide access, which is not generally
desirable. If you want TFTP
This was fixed upstream, in release 2.77.
Simon.
On 18/07/18 14:59, Frank Klaassen wrote:
> Public bug reported:
>
> If one would add a CNAME-record that would point to itself like so:
> CNAME=test.example.com,test.example.com
>
> This will result in a segfault and crash of the dnsmasq process
On 09/11/13 19:07, Philip Potter wrote:
> I agree that the postinst is a better place than the init script to run
> "resolvconf -u".
>
> I'm not sure that it should be conditional on IGNORE_RESOLVCONF though -
> given that the update script will be run next time anything touches
> resolvconf, what'
This is useful, thanks. A couple of questions:
1) Is this easily reproducible?
2) Could you tell me exactly what command-line flags dnsmasq is being
started with?
Cheers,
Simon.
On 27/04/14 18:02, Dave Gilbert wrote:
> Public bug reported:
>
> I hit a case where dnsmasq was running at 100%
On 27/04/14 18:53, Dave Gilbert wrote:
> Hi Simon,
> 1) Apparently so - I just rebooted the vm to see if I could repeat it, and
> it was already stuck at 100% and non-responsive.
> (and blueskaj who confirmed it was seeing the same problem on irc)
> 2) /usr/sbin/dnsmasq --no-resolv --kee
On 27/04/14 18:53, Dave Gilbert wrote:
> Hi Simon,
> 1) Apparently so - I just rebooted the vm to see if I could repeat it, and
> it was already stuck at 100% and non-responsive.
> (and blueskaj who confirmed it was seeing the same problem on irc)
> 2) /usr/sbin/dnsmasq --no-resolv --kee
Are we clear that this is a dnsmasq problem, and not a systemd-resolved
one? Can you add --log-queries to the dnsmasq configuration and see what
dnsmasq is doing? That should demonstrate if the loop is dnsmasq
forwarding to itself, of if the problem is something else.
Cheers,
Simon.
On 13/03/
Ok, so the amplification is arising from dnsmasq looping queries around
127.0.0.1 -> 127.0.0.53 -> 127.0.0.1 -> .
It would be really useful to get dnsmasq's idea of what it's upstreams
are. We know that 127.0.0.1 is in the list from your previous post, and
I guess that dnsmasq has success
Looking again. the loop probably involves systemd-resolverd too, dnsmasq
forwards to 127.0.0.53 which is systemd-resolverd, and systemd-resolverd
then returns it to dnsmasq at 127.0.0.1
Why, oh why is Ubuntu running both?
Cheers,
Simon.
On 14/03/17 11:15, Paul wrote:
> I have cpulimit(1) wat
Whenever the set of servers to which dnsmasq is forwarding queries
changes, the whole set is logged to syslog. It would be useful to have
that information.
On 13/03/17 00:01, Paul wrote:
> Restarting dnsmasq immediately stops an ongoing DNS storm.
>
The actual upstream server used can change unpr
Testing this, the results are not quite as clear-cut as the example. I
don't always see the same errors.
Also, I don't understand why the send() calls in dig, which are sending
UDP packets over the loopback interface, should return the invalid
argument. ARP is not needed over loopback, surely?
L
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The underlying problem is that 2.73 accidentally change the meaning of
dnsmasq --conf-file
from "don't read any conf-file" to "read the default conf-file".
This is a bug, not a feature, and I've just committed a fix to git.
Cheers,
Simon.
On
On 27/09/13 10:37, Franck wrote:
> Public bug reported:
>
> Since I upgraded to Saucy, my local dnsmasq instance seems to lose its
> primary dns server and fallback to secondary dns.
> Since the primary dns is a dnsmasq instance that knows of local servers, and
> the secondary one is external, my
What configuration was in use to get that exact error message. If
dnsmasq is binding the wildcard address (0.0.0.0), I'd expect to see a
message like
dnsmasq: failed to create listening socket for port 53
Whilst if dnsmasq is configured to bind the hosts addresses, I'd expect
to see something li
I'm sympathetic to aim, but this solution is rather fragile, there are
plenty of ways to get dnsmasq to read configuration from places other
than /etc/dnsmasq.conf and /etc/dnsmasq.d/*, for instance adding
conf-file=/path/to/more/configuration
to the existing config files.
It's also possible to
*** This bug is a duplicate of bug 1042275 ***
https://bugs.launchpad.net/bugs/1042275
On 06/10/15 11:08, Alkis Georgopoulos wrote:
> Hi Robie,
>
> while this also happens in Debian, the use case is more common in Ubuntu,
> because NetworkManager is patched to use a spawned dnsmasq instance
On 13/05/12 11:00, Wolf Rogner wrote:
> Public bug reported:
>
> dnsmasq does not resolve DNS names correcty.
>
> Applications like Thunderbird or tools like ssh rely on working name
> resolution. However, if there never was a working name resolution,
> dnsmasq never gets to know about the DNS name
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thomas, this is fixed upstream. I'll add (LP: #1416895) to the
changelog.
Cheers,
Simon.
On 01/02/15 21:04, Thomas Hood wrote:
> Confirmed that the bug affects 2.72-2.
>
> $ cat /etc/dnsmasq.conf | tail -n 2 # Include all files in a
> directory
I think the following, much simpler, patch should solve the problem.
Simon.
diff --git a/src/dbus.c b/src/dbus.c
index 93c597c..4696442 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -156,13 +156,16 @@ static void dbus_read_servers(DBusMessage *message)
dbus_message_iter_get_basic(&it
Annoyingly, I still can't reproduce this on the systems I have
available. On a system where the problem occurs, can it be reproduced
when dnsmasq is started standalone with the same command-line
parameters? The idea situation would be to get the bug to show up in a
dnsmasq instance running under gd
On 08/05/14 22:18, James Hunt wrote:
> A bit of debugging shows that the culprit is blockdata_expand() which is
> being called via blockdata_init(). The issue seems to be that
> blockdata_expand() is passed a parameter of zero. That function then
> mallocs zero bytes (successfully seemingly), the p
On 01/05/14 07:45, Colin King wrote:
> I'm seeing this too, strace show it spinning on:
>
> select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0])
> recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket)
> accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket)
> select(8
On 02/05/14 12:00, Adam Smith wrote:
> LSOF output below. I tried to put a strace in init.d but failed
> miserably
>
> lsof | grep dnsmasq
>
> dnsmasq 1430 dnsmasq cwd unknown
>/proc/1430/cwd (readlink: Permission denied)
> dnsmasq 1430
On 12/03/14 13:24, fish wrote:
> Public bug reported:
>
> Hi,
>
> I'm running dnsmasq in a (docker) container. If I tried to start dnsmasq
> without arguments and it failed with:
>
> dnsmasq: setting capabilities failed: Operation not permitted
>
> Guess this is expected because the contain
On 03/02/13 07:48, Thomas Hood wrote:
>> there's still the unresolved question
>> of whether re-enabling --strict-order
>> will suffice as a workaround, since
>> 12.10 relies on DBus to populate the
>> nameservers. Is there any extra
>> information on this?
>
> Please try it and report back. :-)
On 04/02/13 15:36, Sergio Callegari wrote:
> On 04/02/2013 15:40, Simon Kelley wrote:
>> On 03/02/13 07:48, Thomas Hood wrote:
>>>> there's still the unresolved question
>>>> of whether re-enabling --strict-order
>>>> will suffice as a workaroun
On 04/02/13 22:05, Thomas Hood wrote:
> Simon in #49:
>> It doesn't work [...] the order of servers given to the DBus
>> interface isn't preserved internally
>
> Aha, so the answer to my question
>
>> Will switching on strict-order have the same effect
>> now that nameserver addresses are sent over
Belay my previous comment about 1072899, it looks like network manager
is losing the second server before it ever gets to dnsmasq. Not a
dnsmasq problem.
Simon.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
On 06/02/13 08:59, Thomas Hood wrote:
> Hi Simon.
>
> Before I forget to ask: can you please update dnsmasq(8) to include
> under "--strict-order" a description of what happens when nameserver
> addresses are passed in via D-Bus instead of via a file?
>
> You wrote,
>> you can very easily provide
On 06/02/13 09:18, Thomas Hood wrote:
> [...cont'd after "in order to fix"...] bug #1072899, dnsmasq will
> have to be enhanced such that proposition #1 is true. But we can
> discuss the details of that in bug #1072899.
>
> There is a close analogy between the problem here (bug
> #1003842) and a
On 15/02/13 18:00, Steve Langasek wrote:
> Public bug reported:
>
> On a raring system, the dnsmasq instance spawned by libvirt is not
> forwarding DNS requests to the upstream resolver. dnsmasq is run as:
> /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
>
Steve, what version
On 15/02/13 18:52, Steve Langasek wrote:
> On Fri, Feb 15, 2013 at 06:35:40PM -0000, Simon Kelley wrote:
>> On 15/02/13 18:00, Steve Langasek wrote:
>>> Public bug reported:
>
>>> On a raring system, the dnsmasq instance spawned by libvirt is not
>>>
On 15/02/13 19:52, Marc Deslauriers wrote:
> I was waiting for 2.66 to come out.
>
> Simon, is a 2.66 release planned soon?
>
Probably not soon. There are no current showstopper issues, but there's
a lot of new code over 2.65, so it will need a reasonably long
release-candidate period to get it
On 29/10/12 21:50, Glenn Coombs wrote:
> The nm-dns-dnsmasq.conf file only shows information relating to the 1st
> server - it seems to have totally ignored the 2nd server:
>
> $ cat /var/run/nm-dns-dnsmasq.conf
> server=/kl.imgtec.org/192.168.15.221
> server=/79.168.192.in-addr.arpa/192.168.15.221
On 31/05/12 08:47, Thomas Hood wrote:
> In addition to devising an algorithm for dnsmasq to detect all and only
> NNNs, the implementation of which will no doubt take a while, we should
> consider implementing a quick fix too, along the lines suggested by
> Sergio in #19. NM could be changed to do
On 31/05/12 14:57, Scott Moser wrote:
> this looks like something we should pull in.
> Since Ubuntu has unmodified debian package, and debian maintainer is upstream
> maintainer, we should probably let the quantal package get synced from
> debian. Then, we can patch the 12.04 Ubuntu version in a
On 27/07/12 16:10, Launchpad Bug Tracker wrote:
> This bug was fixed in the package dnsmasq - 2.62-3ubuntu1
>
> ---
> dnsmasq (2.62-3ubuntu1) quantal; urgency=low
>
>* debian/rules: install the dnsmasq dbus configuration in dnsmasq-base,
> since
> users of the standalone binar
On 17/08/12 19:26, Mathieu Trudel-Lapierre wrote:
> Any news about this?
>
> There's actually multiple issues here; one of them being that loopback
> probably isn't ready yet, which is something we fixed in NetworkManager
> (which had the same issue) by depending on it through upstart before
> star
On 11/06/12 19:57, Thomas Hood wrote:
> But, second, there is a problem connecting the resolver to the NM-
> controlled dnsmasq such that the latter stays out of the way of the
> general local nameserver which currently wants to listen on the IPv4
> wildcard address. Using address ::1 for nm-dnsm
On 11/06/12 20:41, Thomas Hood wrote:
> Aha, I had tried this and it didn't work... in version 2.57. But I see
> that quantal already has 2.62.
>
>> Another instance of dnsmasq will run without interfering with that,
> providing only that --bind-interfaces is set.
>
> Just to make sure I understan
On 12/06/12 10:05, Alkis Georgopoulos wrote:
> Note that while bind-interfaces can be specified multiple times,
> defining except-interfaces more than once is a syntax error in my
> dnsmasq 2.59-4.
>
Are you sure? That should be allowed.
Simon.
--
You received this bug notification because yo
On 12/06/12 11:24, Thomas Hood wrote:
> Hmm, just tested this myself. You can't use "except-interface=lo"; it
> seems you have to use "listen-address=10.1.2.3". Perhaps Simon knows a
> better way.
>
If you want to listen on an address which doesn't appear on an interface
(ie 127.0.1.1) then you
On 12/06/12 20:31, Thomas Hood wrote:
> (Executive summary of the following: I think we should fix this by
> making nm-dnsmasq listen at ::1.)
>
> Thanks for your much-needed help, Simon.
>
> It is good to know that the "except-interface" avenue is available. We
> want, however, to be able to enjo
On 13/06/12 11:07, Thomas Hood wrote:
> OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
> as follows.
>
> 1. Either we accept that nm-dnsmasq is incompatible with every standalone
> nameserver and enforce this in a better way;
> 2. or we force every standalone nameserver i
On 13/06/12 11:07, Thomas Hood wrote:
> OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
> as follows.
>
> 1. Either we accept that nm-dnsmasq is incompatible with every standalone
> nameserver and enforce this in a better way;
> 2. or we force every standalone nameserver i
On 14/06/12 16:06, Thomas Hood wrote:
> @Alkis: IIUC dnsmasq in bind-interfaces mode will not start to listen on
> any addresses assigned to interfaces after dnsmasq has started. So,
> yes, she would have to restart standalone dnsmasq if she wants it to
> listen on those newly assigned addresses.
On 15/06/12 10:19, Thomas Hood wrote:
> $ cat /run/nm-dns-dnsmasq.conf
> server=/17.172.in-addr.arpa/172.17.1.2
> server=192.168.1.254
> server=...
>
> The first "server=" line reflects the fact that I am connected to a VPN.
> This can't be expressed in resolv.conf syntax.
FYI only,
It's possib
On 15/06/12 08:04, Thomas Hood wrote:
> Alkis: This relies on the assumption that NM's configuration text can be
> dropped in alongside whatever other configuration text is present and
> that dnsmasq will still work properly. This assumption is, er,
> questionable.
There was an attempt, some time
On 15/06/12 14:54, Christian Parpart wrote:
> Hey, thanks, and now I also found this one:
>
> https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898
>
> which is exactly what I was talking about (interesting that I didn't
> find earlier).
>
> However, the last commenter says he's pulling
On 15/06/12 15:01, Thomas Hood wrote:
>> -- Solvable by moving nm-dnsmasq to another port:
> There's one more snippet after this dealing with the IPv6 case. That
> should be it. Any obvious problems I'm overlooking?
>
Applications that don't use the libc resolver? I don't know if such
exist be
On 18/06/12 18:11, Thomas Hood wrote:
> Hi Stéphane,
>
> Changing the default of dnsmasq to bind-interfaces wouldn't have been a
> very good solution because some people run dnsmasq without installing
> those other packages and rely upon the "unbound" mode. The implemented
> solution is better be
On 18/06/12 21:08, Thomas Hood wrote:
> @Simon: This is pretty much what I had in mind (comment #88) as a long-
> term solution. How difficult do you think that this would be?
Don't know. I'm working on it now: seems to be behaving:
dnsmasq: new IPv4: 192.168.3.1
dnsmasq: new IPv6: fe80::f0f6:48
On 19/06/12 10:10, Chris Halse Rogers wrote:
> Additionally, I'd like to know what the likely impact of adding bind-
> interfaces to dnsmasq is on users. What (if anything) will break on
> users' systems?
>
Three things change.
1) Dnsmasq loses the ability to provide service on dynamically crea
On 20/06/12 10:56, Thomas Hood wrote:
> I can imagine that it will take a lot of care to avoid introducing races
> inside dnsmasq.
It's OK: notification of new interfaces comes via netlink, so it gets
synchronised via the select() call just like everything else.
Have I mentioned yet that Simon i
>Simon, do you think that dnsmasq could misbehave as described here?
The only way I can see for this to occur is if a DNS server is return wrong (ie
NXDOMAIN or NODATA) answers, no answer shouldn't be a problem.
I suggest adding --log-queries to the dnsmasq configuration to try and
get a handle
>Simon Kelley might have written dnsmaskq with the assumption that all
DNS servers upstream have the same view about the >namespace. However,
this is not how RFC sees it nor how it is set up in a majority of
installations.
Can you provide an authoritative reference for that?
As far as I c
> To be frank, when changing the default system resolver, expected
> behavior should be the default. It's all well and good saying that
> non-equivalent resolvers are 'bad' - and in the case of dnsmasq, that
> might be true - but that's a value judgement that shouldn't have a place
> in this scenar
Thomas in #17
A heuristic for this is difficult, because you have to prove a negative.
If we can assume the first nameserver has local addresses, we can never
return a reply from any other nameserver until we have the reply from
the first one, in case the first one has different data. Once we see
> Simon, your suggestion (call it "#18") differs from the suggestion in #17 in
> two ways. First, #18 sends the first-received reply back
> to the client without waiting for the results of comparison with other
> results whereas #17 does wait. Second, #18 switches to
> strict-order mode when *a
On 08/12/11 12:57, Thomas Schweikle wrote:
> Yes, that's right, but there are interfaces not started from
> /etc/network/interfaces or Network Manager:
> * VMware Workstation / Player installs interfaces starting VMware daemons
> * VirtualBox installs interfaces
> * KVM may install an additional b
On 20/12/11 20:55, Thomas Schweikle wrote:
> H. If this is the reason, how to force dnsmasq not to respond on
> some interfaces, while listening on all others, with different
> configurations per interface?
>
> Wouldn't it be better to configure dnsmasq even for interfaces not there
> at start
On 02/01/12 09:44, Thomas Schweikle wrote:
>> That's exactly what happens without --bind-interface, interfaces which
>> are configured in dnsmasq but don't exist at startup generate a warning
>> only, and start to work when they are created.
>
> This seems to be correct.
>
>> Packets from interfa
An addition to my last reply:
If a DHCP request is received via in interface which doesn't have an IP
address, there will be a log message, but the request will be otherwise
ignored.
Cheers,
Simon.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
On 17/05/12 10:19, Wolf Rogner wrote:
> I recreated the situation by restarting the network manager.
>
> resolv.conf contains link to 127.0.0.1
> /run/nm-dns-dnsmasq.conf contained my name server already.
>
> However, even dig does not resolv correctly. Here are the results (my
> network is 10.x.
Launchpad Bug Tracker wrote:
> You have been subscribed to a public bug:
>
> Binary package hint: resolvconf
>
> in /etc/resolvconf/resolv.conf.d/base I have
>
> search domain1.local domain2.local
>
> When trying to connect to a host in domain2.local using only the
> hostname, only the first do
On 08/02/12 08:33, Ritesh Raj Sarraf wrote:
> On Wednesday 08 February 2012 03:54 AM, Serge Hallyn wrote:
>> @Ritesh,
>>
>> Unfortunately I don't know that that many people would read the README :)
>> It is worth adding though, thanks for the suggestion.
>>
>> In addition, I will add an LXC section
On 08/07/13 15:02, Thomas Hood wrote:
> What do you think, Simon?
>
> ** Changed in: dnsmasq (Ubuntu)
> Status: Incomplete => New
>
I'm confused: dnsmasq won't cache a negative answer if it has no
upstream servers. To cache a negative answer it has to _receive_ a
negative answer (and th
> Whatever is going on, it's more complex. Maybe the problem is that
> dnsmasq gets a negative answer from some upstream server, and then
> gets a new upstream server which has the correct information? The
> solution then is --clear-on-reload but I think NM sets that?
but --clear-on-reload
On 24/07/13 20:33, Thomas Hood wrote:
> Hi Simon,
>
> I think we've established that the submitter is having a problem with
> dnsmasq server, not with NetworkManager-controlled dnsmasq. So it would
> be interesting to know if clear-on-reload fixes the submitter's problem.
> (He already said that no
Fixed in developement version.
thttp://hekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=edf0bde0c6837b010560c40e6b74d2f67b64da09
Simon.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1203430
Title:
To Ubuntu triagers: This is a real bug, but it only affects code which
provides compatibility with very old (pre-Ubuntu) Debian installations
which might have interface configuration in /etc/default/dnsmasq. The
accepted place for such configuration has always been /etc/dnsmasq.conf
during the
On 12/11/10 19:09, Dave Walker wrote:
> Public bug reported:
>
> Binary package hint: dnsmasq
>
> *** glibc detected *** /usr/sbin/dnsmasq: double free or corruption
> (top): 0x08ab60b8 ***
>
> (As initially reported: http://lists.thekelleys.org.uk/pipermail
> /dnsmasq-discuss/2010q3/004369.html)
>
Acknowledge that RFC non-compliance. Fixing this is actually a fairly
big ask, since the problem is not that dnsmasq omits the SOA when
answering from cache, but that dnsmasq doesn't cache SOA records. The
design philosophy was (and is) to cache only a few RR types to make the
code and data str
On 12/02/2025 17:16, jean-christophe manciot wrote:
> Now, if I add dhcp-range option, for instance:
> dhcp-range=192.168.0.50,192.168.0.150,12h
>
> DHCP ports are open on **all** interfaces instead of just lo as specified
> earlier:
> /usr/bin/netstat -tunpevaW | grep dnsmasq
> udp0
On 14/02/2025 13:38, jean-christophe manciot wrote:
> With the following setup:
>
> port=0
> interface=eth0
> bind-interfaces
> dhcp-range=192.168.1.2,192.168.1.254
>
> I get:
> # /usr/bin/netstat -tunpevaW | grep dnsmasq
> udp0 0 0.0.0.0:67 0.0.0.0:*
It's not clear from this if there's at least one dhcp-range in
/etc/dnsmasq.conf, but from the posted logs, it looks like there isn't.
If so that's the problem. No dhcp-range -> no DHCP server -> no port 67
socket.
Simon.
On 12/02/2025 16:57, jean-christophe manciot wrote:
> Public bug reporte
On 17/02/2025 13:47, jean-christophe manciot wrote:
>> In order to allow multiple dnsmasq instances (for instance in the
>> libvirt case) dnsmasq sets REUSEPORT on DHCP sockets, and, if exactly
>> one interface is specified in the configuration, it sets SO_BINDTODEVICE.
> No, it does not work: if d
91 matches
Mail list logo
