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 you
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 have
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 enjoy the
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-dnsmasq
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 understand
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-dnsmasq
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 understand
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 an
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 an
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 *any*
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 can see
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 scenario,
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
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.x.x
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.x.x
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 names.
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 names.
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 to the
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 to the
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
Server Team, which is
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 interfaces which
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 interfaces which
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
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 startup,
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 startup,
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
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
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 domain is
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 domain is
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
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)
This
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)
This
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 configuration.
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 configuration.
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,ip range /etc/dnsmasq.d/libvirtf
if system dnsmasq is not
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,ip range /etc/dnsmasq.d/libvirtf
if system dnsmasq is not
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
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: LOOPBACK mtu 16436 qdisc noop state DOWN
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
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
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.
--
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
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
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
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
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 which might
apply
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
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 which might
apply
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
101 - 156 of 156 matches
Mail list logo
