On 07/03/2022 22:06, Geoff Back wrote:
On 07/03/2022 18:20, Simon Kelley wrote:
A quick test of the current development code fails to reproduce this,
which is puzzling.
One thing to check: having a dhcp-host line which associates an address
with a name is not enough to make this work:
On 07/03/2022 18:20, Simon Kelley wrote:
> A quick test of the current development code fails to reproduce this,
> which is puzzling.
>
>
> One thing to check: having a dhcp-host line which associates an address
> with a name is not enough to make this work: there needs to be an active
> DHCP
On 07/03/2022 20:51, Frank Liu wrote:
On Mon, Mar 7, 2022 at 10:46 AM Simon Kelley wrote:
A quick test of the current development code fails to reproduce this,
which is puzzling.
One thing to check: having a dhcp-host line which associates an address
with a name is not enough to make
On Mon, Mar 7, 2022 at 1:39 PM Simon Kelley wrote:
>
>
>
> On 07/03/2022 20:51, Frank Liu wrote:
> > On Mon, Mar 7, 2022 at 10:46 AM Simon Kelley
> > wrote:
> >>
> >> A quick test of the current development code fails to reproduce this,
> >> which is puzzling.
> >>
> >>
> >> One thing to check:
On Mon, Mar 7, 2022 at 10:46 AM Simon Kelley wrote:
>
> A quick test of the current development code fails to reproduce this,
> which is puzzling.
>
>
> One thing to check: having a dhcp-host line which associates an address
> with a name is not enough to make this work: there needs to be an
A quick test of the current development code fails to reproduce this,
which is puzzling.
One thing to check: having a dhcp-host line which associates an address
with a name is not enough to make this work: there needs to be an active
DHCP lease in place to be able to resolve
You can set the source address of upstream queries in the --server
option, which can work in some circumstances (and can ensure that the
replies also come back via the VPN, which isn't a given.
In general, this is a routing question: you need to route traffic to
1.1.1.1 via the VPN and do
On Mon, Mar 07, 2022 at 03:26:11PM +, Ian Bonham wrote:
> Hi Everyone,
>
> I can't thank you enough for the work on DNSMASQ, it's an utterly brilliant
> piece of software. I'm amazed at the flexibility it gives me in securing my
> home network, thank you all who put in so much effort.
>
>
I think it's very likely that the crash is fixed in later versions,
based only on how old 2.81 is.
If you want to find out what the problem is and write or backport the
fix I suggest building a binary for dnsmasq with debugging symbols and
either running it under gdb, or enabling core dumps.
On 06/03/2022 15:16, Matus UHLAR - fantomas via Dnsmasq-discuss wrote:
On 02.03.22 19:24, Simon Kelley wrote:
The behaviour on this alternated between what you observed and what
you advocate a few times before settling.
The problem with waiting for all replies is that a common source of
Hi Everyone,
I can't thank you enough for the work on DNSMASQ, it's an utterly brilliant
piece of software. I'm amazed at the flexibility it gives me in securing my
home network, thank you all who put in so much effort.
Gushing aside, I'm stuck on one config I can't figure out though, so I
Thanks Geert.
Sorry to ask, can we expect this crash to be resolved with a later version?
Because we need to undergo a complete regression test on many devices. So
there could be some hesitation on such upgrades.
Or is there a way to figure out this crash and get an upstream patch?
Regards,
Arjun
On Mon, Mar 07, 2022 at 10:37:33AM +0530, Arjun D R wrote:
> Hi Team,
>
> We are facing a dnsmasq crash on version 2.81. We are not aware of steps to
> trigger the crash, but we used to get this crash frequently.
>
> Crash Details:
>
>
> Dnsmasq logs:
>
>
> Is it a known
13 matches
Mail list logo
