[squid-users] large downloads got interrupted

[Amos Jeffries]

On 28/06/2016 8:46 p.m., Eugene M. Zheganin wrote:
> Hi,
> 
> recently I started to get the problem when large downloads via squid are
> often interrupted. I tried to investigate it, but, to be honest, got
> nowhere. However, I took two tcpdump captures, and it seems to me that
> for some reason squid sends FIN to it's client and correctly closes the
> connection (wget reports that connection is closed), and in the same
> time for some reason it sends like tonns of RSTs towards the server. No
> errors in logs are reported (at least on a  ALL,1 loglevel).
> 

It sounds like a timeout or such has happened inside Squid. We'd need to
see your squid.conf to see if that was it.

What version are you using? there have been a few bugs found that can
cause unrelated connections to be closed early like this.

> Screenshots of wireshark interpreting the tcpdump capture are here:
> 

?? URL sems not to have made it to the mailing list.


> Squid(2a00:7540:1::4) to target server(2a02:6b8::183):
> 
> http://static.enaza.ru/userupload/gyazo/e5b976bf6f3d0cb666f0d504de04.png
> (here you can see that all of a sudden squid starts sending RSTs, that
> come long way down the screen, then connection reestablishes (not on the
> screenshot taken))

Screen dump of packet capture does not usually help. We usually only ask
for packet captures when one of the dev needs to personally analyse the
full traffic behaviour.

A cache.log trace at debug level 11,2 shows all the HTTP messages going
through in an easier format to read. There might be hints in there, but
if it is a timeout like I suspect probably not.

> 
> Squid(fd00::301) to client(fd00::73d):
> 
> http://static.enaza.ru/userupload/gyazo/ccf4982593dc6047edb5d734160e.png  (here
> you can see the client connection got closed)

So Squid is closing both connections from the middle. That is pointing
strongly at a timeout, bug, or error in the data transfer.

Amos