On Sunday 01 July 2018 02:17:41 Gary R. Schmidt wrote:
> On 01/07/2018 10:22, Gene Heskett wrote:
> > I'm still logging this about every other freshclam run:
> >
> > Sat Jun 30 18:49:53 2018 -> nonblock_connect: connect(): fd=4
> > errno=101: Network is unreachable
> > Sat Jun 30 18:49:53 2018 ->
On 01/07/2018 21:05, Reindl Harald wrote:
Am 01.07.2018 um 08:17 schrieb Gary R. Schmidt:
On 01/07/2018 10:22, Gene Heskett wrote:
I'm still logging this about every other freshclam run:
Sat Jun 30 18:49:53 2018 -> nonblock_connect: connect(): fd=4 errno=101:
Network is unreachable
Sat Jun 30
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am So den 1. Jul 2018 um 13:22 schrieb Gary R. Schmidt:
> Do any machines *not* have IPv6 stacks installed these days?
Yes. If you don't have and/or need IPv6 connectivity, it is probably the
safest measurement to switch it off completely (by kerne
On Sunday 01 July 2018 08:22:03 Gary R. Schmidt wrote:
> On 01/07/2018 21:05, Reindl Harald wrote:
> > Am 01.07.2018 um 08:17 schrieb Gary R. Schmidt:
> >> On 01/07/2018 10:22, Gene Heskett wrote:
> >>> I'm still logging this about every other freshclam run:
> >>>
> >>> Sat Jun 30 18:49:53 2018 ->
On 01/07/2018 23:00, Gene Heskett wrote:
On Sunday 01 July 2018 08:22:03 Gary R. Schmidt wrote:
[SNIP]
Now, testing for IPv6 connectivity might turn a temporary failure into
a permanent one, which is not good,
Needs an explanation. Udev is the only thing that will turn a temp
failure permane
On 01/07/2018 22:37, Reindl Harald wrote:
[SNIP]
> do you see any ipv6 address here? the stack is disabled and even in that
> cases freshclam comes with ipv6 error messages
>
Do you know the difference between running an IPv6 stack and doing a
name lookup for an record?
Cheers,
On 02/07/2018 00:35, Reindl Harald wrote:
Am 01.07.2018 um 16:33 schrieb Gary R. Schmidt:
On 01/07/2018 22:37, Reindl Harald wrote:
[SNIP]
do you see any ipv6 address here? the stack is disabled and even in that
cases freshclam comes with ipv6 error messages
Do you know the difference betwe
Gentlemen, we’ve descended into a “who is better” contest. I suggest we stop.
Sent from my iPhone
> On Jul 1, 2018, at 10:43, Gary R. Schmidt wrote:
>
>> On 02/07/2018 00:35, Reindl Harald wrote:
>>
>>> Am 01.07.2018 um 16:33 schrieb Gary R. Schmidt:
>>> On 01/07/2018 22:37, Reindl Harald
On Sunday 01 July 2018 10:20:59 Gary R. Schmidt wrote:
> On 01/07/2018 23:00, Gene Heskett wrote:
> > On Sunday 01 July 2018 08:22:03 Gary R. Schmidt wrote:
>
> [SNIP]
>
> >> Now, testing for IPv6 connectivity might turn a temporary failure
> >> into a permanent one, which is not good,
> >
> > Nee
The debug flag on the freshclam invocation seems only to report on the
processing that happens *after* the cvd is successfully downloaded.
So... I went to a more basic level and captured the actual network
traffic with pcap and then examined it with wireshark.
I found an update attempt that faile
On 7/1/18 8:24 PM, Paul Kosinski wrote:
My conclusion is that the cause of this is a typical race condition:
the DNS TXT record is updated before Cloudflare has propagated the new
cvd file to all the mirrors.
Is this a problem?
dp
___
clamav-users m
Seems to me that it's only a problem if it takes a significant amount of time
between the DNS update and the mirror updates. I don't have a good feel for how
long that is from the postings so far, but it does sound like it may have
increased as a result of the move from ClamAV mirrors to the Cla
What makes it a problem? You can never dl it until it is available, so the
problem is you become aware of it too soon. But think about what that means.
Your choices are to know immediately when an update is available and try to get
it, or wait until every mirror is synchonized, become notified,
As far as the client mirrors.dat file, it's updated locally by freshclam to
indicate either success or failure for a specific IP. After a specific number
of failures (I've forgotten what that is) the IP is given a “time-out” which
precludes it's use until some amount of time passes. Under normal
My interest is if a non-synched mirror would trigger an entry in which case many
false entries are possible. That is a cascading error that would be complicated
by close-in-time updates. Just noodling out of the box a bit, here.
dp
On 7/1/18 9:28 PM, Al Varnell wrote:
As far as the client mi
I suspect the use of IPv6 would double the number of failures, but each should
be counted against a separate IP, so that doesn't strike me as contributing. It
would be interesting to know the interval between checks for those experiencing
this problem. That, along with knowing how long it takes
Maybe these are dumb questions; if so, please ignore.
But doesn't it make more sense to update all the mirrors first, before changing
the DNS? Is there some mechanism to do it that way round?
Anyway, it seems to be working OK here in Oz, for now.
Cheers
Bill
-Original message-
> From:A
17 matches
Mail list logo
