Re: [squid-users] Squid fails loading pages, repeat 3 second disconnects shoutcast]

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 08 Feb 2012 11:20:15 +1300

On 08.02.2012 10:33, mgomon wrote:
> <b>OS: Ubuntu 11.04 Natty 64bit
> Squid Cache: Version 2.7.STABLE9</b>
>
> I am running Squid through IE, Chrome and Firefox. Every page I load
> either does not load all the way or fails to load at all. Also any
> page no
> matter the site that has flash content does not load the flash at
> all. I
> also tried Shoutcast through Winamp and every single time I start the
> stream... with in 3 seconds exactly... it stops.
>
> --> cache.log using ALL,2 (<b>Trying to access gmail and also a
> shoutcast
> playlist</b>)
> <raw>2012/02/08 00:54:36| Parser: retval 1: from 0->286: method 0->2;
> url
> 4->275; version 277->285 (1/1)
> 2012/02/08 00:54:36| The request GET
>
> http://www.google.com/recaptcha/api/reload?c=03AHJ_Vuu7IT_CXsb32MmOv-sTdSos6TkiumllwIY_nCw33uUJ9UEiRFb8HMEC1oBQ-V6ZjEpCIF21BgfyuC0sdQjq5zAByANBd-qAuWVxVPYNuO9TZ6UVBNBohQ9_P-gE-AAG0wjYXS4mQz8L4UJwo0A0fu2TQePchQ&k=6LfEHroSAAAAAHMm1oJ-Wk-Wmk1n8nutKcpM_mJ6&reason=t&type=image
> is ALLOWED, because it matched 'all_ip'
> 2012/02/08 00:54:37| The reply for GET
>
> http://www.google.com/recaptcha/api/reload?c=03AHJ_Vuu7IT_CXsb32MmOv-sTdSos6TkiumllwIY_nCw33uUJ9UEiRFb8HMEC1oBQ-V6ZjEpCIF21BgfyuC0sdQjq5zAByANBd-qAuWVxVPYNuO9TZ6UVBNBohQ9_P-gE-AAG0wjYXS4mQz8L4UJwo0A0fu2TQePchQ&k=6LfEHroSAAAAAHMm1oJ-Wk-Wmk1n8nutKcpM_mJ6&reason=t&type=image
> is ALLOWED, because it matched 'all'
> 2012/02/08 00:54:37| clientReadRequest: FD 26: no data to process
> ((11)
> Resource temporarily unavailable)

> 2012/02/08 00:54:37| Parser: retval 1: from 0->222: method 0->2; url
> 4->211; version 213->221 (1/1)
> 2012/02/08 00:54:37| The request GET
>
> http://www.google.com/recaptcha/api/image?c=03AHJ_VusHCEpBxnyuf7IaBo_Rmto3eVoPH-bwEhe0rRoDgwJHnA8iYxIJyRhmQt7C6yaFpRoKkfddbuu86LV_3q1elMioo_zbPoF9mYw8KqEWsdrsTTbCYoGQKLh11HFm0yVxBtFmQhSlXkh0Au6m7fG4I4b2xtZOtw
> is ALLOWED, because it matched 'all_ip'
> 2012/02/08 00:54:37| The reply for GET
>
> http://www.google.com/recaptcha/api/image?c=03AHJ_VusHCEpBxnyuf7IaBo_Rmto3eVoPH-bwEhe0rRoDgwJHnA8iYxIJyRhmQt7C6yaFpRoKkfddbuu86LV_3q1elMioo_zbPoF9mYw8KqEWsdrsTTbCYoGQKLh11HFm0yVxBtFmQhSlXkh0Au6m7fG4I4b2xtZOtw
> is ALLOWED, because it matched 'all'
> 2012/02/08 00:54:37| storeCreate: Selected dir '0' for obj size
> '3600'
> 2012/02/08 00:54:37| clientReadRequest: FD 26: no data to process
> ((11)
> Resource temporarily unavailable)

> 2012/02/08 00:55:02| sslReadClient: FD 40: read failure: (104)
> Connection
> reset by peer

This is a mix of FD 26 which is running along fine apparently with
google requests and and FD 40 which is having problems.

If we assume that FD 40 is the client connection to Squid and FD 26 is
the connection to google. This appears to be requests being fetched from
google successfully, and the client disconnecting suddenly ~30 seconds
after the last one is sent.

Conclusion: persistent client connections with a 30 second timeout?
normal, no problems there.

NP: some bits earlier in your cache.log should indicate how FD 40/26
were setup to check that assumption.

> 2012/02/08 01:04:06| Parser: retval 1: from 0->52: method 0->2; url
> 4->41;
> version 43->51 (1/0)
> 2012/02/08 01:04:06| The request GET
> http://cp.internet-radio.org.uk:15701/ is ALLOWED, because it matched
> 'all_ip'

Hmm, what is this "all_ip" thing? an attempt at redefining locally
what IPs exist on the Internet? (which is what "all" means in
squid-speak).

> 2012/02/08 01:04:06| peerSourceHashSelectParent: Calculating hash for
> 63.117.221.135
> 2012/02/08 01:04:06| The reply for GET
> http://cp.internet-radio.org.uk:15701/ is ALLOWED, because it matched
> 'all'
> 2012/02/08 01:04:06| aclMatchRegex: match '^ICY.[0-9]' found in 'ICY
> 200 OK'
> 2012/02/08 01:04:06| HTTP/0.9 response, disable everything
> 2012/02/08 01:04:12| clientReadRequest: FD 13: (104) Connection reset
> by peer
> 2012/02/08 01:04:12| fwdAbort:
> http://cp.internet-radio.org.uk:15701/</raw>

*Ten minutes later* an ICY request on FD 13 aborted by the client
browser 6 seconds after starting to stream. As far as Squid is aware it
was fine. Again this appears to be normal for the Squid section of the
transfer.

This looks all the world to me like something in the user agent
screwing up.

>
> I have tried all kinds of settings from what I could find on google
> searches... nothing seems to work or help. I have been at this for a
> couple days playing with the configuration and again, nothing has
> helped.
> I am great need of some assistance here.

Can you please check this with 3.1 or later which support ICY
(SHOUTcast) protocol relay better. The 2.7 workaround is a bit
experimental.

I've tested the 3.1 support a year ago with WinAmp, RealPlayer, and
MediaPlayer with good results. There is always the possibility they may
have changed the details and broken things since then though.

Amos
Received on Tue Feb 07 2012 - 22:20:18 MST

This archive was generated by hypermail 2.2.0 : Wed Feb 08 2012 - 12:00:02 MST