[clamav-users] Partial downloads of updates

[G.W. Haywood]

Hello again,

On Fri, 3 Aug 2018, David Rosenstrauch wrote:

> ... wireshark screenshot at http://darose.net/packets-dropped.png
> which shows a download ... humming along nicely, when all of a
> sudden it looks like the that remote host seems to jump way ahead in
> the sequence numbering ...

Well that's obviously problematic.  As you say, the sequence did get
out of shape.  The packet lengths seem to be all over the place, when
I'd expect them to be more consistent for a file download.

In your OP the download which failed was daily-24792.cdiff; that same
file took under a second to download here and it came from the same IP
as it happens:

Sun Jul 29 02:18:25 2018 -> WARNING: Local version: 0.100.0 Recommended version: 0.100.1
...
Sun Jul 29 02:18:25 2018 -> daily.cvd version from DNS: 24792
Sun Jul 29 02:18:26 2018 -> Retrieving http://db.uk.clamav.net/daily-24792.cdiff
Sun Jul 29 02:18:26 2018 -> Trying to download http://db.uk.clamav.net/daily-24792.cdiff (IP: 2400:cb00:2048:1::6810:ba8a)
Sun Jul 29 02:18:26 2018 -> Downloading daily-24792.cdiff [100%]
Sun Jul 29 02:18:26 2018 -> cdiff_apply: Parsed 500 lines and executed 500 commands

I think we can suppose it's not a mirror problem, but stranger things
have happened.

There might be contention with other users or services - does this
happen at all hours of the day or is it more likely at certain times?
Joel suggested trying a later version of the package, did you do that?
I had a quick look at the changes but I saw nothing addressing this
specifically.  As these aren't big files, my money's on path issues -
something like fragmentation or MTU lengths.

Your IP 2604:2000:14c4:c2da::2 indicates the ISP is Time Warner cable,
I guess anything could happen there.  Do you have a way of using a
different connection, say run another box elsewhere for a few days?

Do you have a way of forcing IPv4 transport for all downloads?  I see
again from your OP that you managed an IPv4 download.

> ... "ifconfig" on my server shows 17 Rx dropped packets on eth0.

The data lost seems likely to be more than 17 packets if the average
packet size is about what I see in your screenshot.

> ... behind a Netgear WNDR3700 router.

You might try a different model of router, I don't know it personally
but on a quick search I do see the odd problem report.  I've had my
own issues with Netgear kit, especially Gigabit switches which will
suddenly go off the reservation and need to be rebooted.  It seems to
be either just some examples of the same model, or the way that they
get hammered, I never have got to the bottom of it.

In any event it doesn't look like a ClamAV problem, so we might be
straying a  little off-topic for this list.

HTH

-- 

73,
Ged.