enko
_
From: Albert ARIBAUD
Sent: вторник, октября 25, 2016 2:51 ДП
Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
To: John Knight
Cc:
Hi John,
Yes, you can submit patches to the list.
However, 2.55 is quite old with respec
Hi All,
Here is the patch file I generated to fix the issue with poll_resolv that I was
seeing with dnsmasq 2.55:
- Begin Patch -
diff -Naur dnsmasq-2.55/src/dnsmasq.c dnsmasq-2.55_new/src/dnsmasq.c
--- dnsmasq-2.55/src/dnsmasq.c2016-10-20 10:43:23.609655958 -0700
+++
ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Monday, October 24, 2016 1:56 PM
To: John Knight
Cc: dnsmasq-discuss@lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
Hi John,
Yes, you can submit patches to the list.
However, 2.55 is quite old with
t; To: 'Albert ARIBAUD'
> Cc: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: RE: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an
> hour
>
> Hi Albert,
>
> My comments inline.
>
> John
>
> > Hi All,
>
> > The main while(1) loop uses select() to
lbert ARIBAUD'
Cc: dnsmasq-discuss@lists.thekelleys.org.uk
Subject: RE: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
Hi Albert,
My comments inline.
John
> Hi All,
> The main while(1) loop uses select() to determine if it has work to
> do. In most cases, it appears
Hi Albert,
My comments inline.
John
> Hi All,
> The main while(1) loop uses select() to determine if it has work to
> do. In most cases, it appears to use timeout of 0, which I believe
> means just wait indefinitely for work on the file descriptors. Other
> times, it appears that the timeout
Hi John,
Le Tue, 18 Oct 2016 22:36:07 +
John Knight a écrit:
> Hi All,
> The main while(1) loop uses select() to determine if it has work to
> do. In most cases, it appears to use timeout of 0, which I believe
> means just wait indefinitely for work on the file descriptors. Other
> times,
Hi All,
Still trying to figure this one out, At this point, I don't think the issue is
caused by time going backwards, although I am convinced that there are issues
with dnsmasq when time does go backwards. There is a lot of previous
discussion on the backwards time issue.
What I am pursuing
Hi Albert,
Actually the second issue relating to the variable last_change not being a
static is NOT specifically related to how dnsmasq handles time. Without the
static definition of last_change, the "if(difftime(statbuf.st_mtime,
last_change)" ALWAYS evaluates to > 0, which is not what the co
Hi,
Le Fri, 14 Oct 2016 19:09:31 +0200
Albert ARIBAUD a écrit:
> How exactly is that second is totally related to how dnsmasq
> handles time?
Ahem. Rolling that back.
How is that second issue related to now dnsmasq handles time?
With apologies.
Amicalement,
--
Albert.
Hi,
Le Fri, 14 Oct 2016 19:46:13 +0500
"Vladislav Grishenko" a écrit:
> > But timeouts can occur, TTLs can get past, etc. To treat those
> > properly, dnsmasq needs to know how much time has flown while it
> > was sleeping (if it ever does, of course).
>
> It does (actually not due sleeping,
dislav Grishenko
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Friday, October 14, 2016 7:04 PM
> To: Vladislav Grishenko
> Cc: 'John Knight' ; dnsmasq-
> disc...@lists.thekelleys.org.uk; 'Simon Kelley'
>
Hi Vladislav,
Le Fri, 14 Oct 2016 11:52:33 +0500
"Vladislav Grishenko" a écrit:
> Hi, Albert,
>
> > 1. HAVE_BROKEN_RTC should be used for, well, broken RTCs. Here, we
> > are not dealing with broken RTC.
>
> Root issue from original mail:
> > One of which acknowledges potential problem if th
On 10/14/2016 02:52 AM, Vladislav Grishenko wrote:
Hi, Albert,
1. HAVE_BROKEN_RTC should be used for, well, broken RTCs. Here, we are
not dealing with broken RTC.
Root issue from original mail:
One of which acknowledges potential problem if the clock goes backwards...
As for me it's indeed
henko
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Friday, October 14, 2016 2:40 AM
> To: Vladislav Grishenko
> Cc: John Knight ; dnsmasq-
> disc...@lists.thekelleys.org.uk; Simon Kelley
> Subject: Re: [Dnsmasq-discuss] Dnsmasq not re
Hi All,
Well, I believe I have found another issue with the function poll_resolv().
The variable last_change needs to be static. Otherwise, the
difftime(statbuf.st_mtime, last_change) always is a rather large number... the
number of seconds since time 0 (the initialized value of last_change a
Best Regards, Vladislav Grishenko
>
> _
> From: John Knight
> Sent: четверг, октября 13, 2016 11:00 ПП
> Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an
> hour To: Albert ARIBAUD
> Cc:
>
>
> Hi Albert,
>
> That sounds like a very good idea
HAVE_BROKEN_RTC is
enabled.
Best Regards, Vladislav Grishenko
_
From: John Knight
Sent: четверг, октября 13, 2016 11:00 ПП
Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
To: Albert ARIBAUD
Cc:
Hi Albert,
That sounds like a
q-discuss@lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Dnsmasq not resolving addresses for an hour
Hi,
Just a generic comment: from what I can see, all absolute times in dnsmasq are
returned bu dnsmasq_time() which calls either times() or time(). This, IIUC,
corresponds to CLOCK_REALTIME in cloc
Hi,
Just a generic comment: from what I can see, all absolute times in
dnsmasq are returned bu dnsmasq_time() which calls either times() or
time(). This, IIUC, corresponds to CLOCK_REALTIME in clock_gettime(),
which is indeed affected when (re)setting the time.
Maybe a fix to time jump issues wou
Hi,
I think I may know what the issue is... it appears that the time may be changed
by ntp in my failure scenario as suggested by the URLs referencing ntp in the
dnsmasq.log file. There are numerous references to difftime in dnsmasq code.
One of which acknowledges potential problem if the clo
21 matches
Mail list logo
