Re: [squid-users] websites not responding

On Wed, Jan 9, 2013 at 10:24 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 10/01/2013 4:45 p.m., Amos Jeffries wrote:
>>
>> On 10/01/2013 3:32 p.m., Simon Matthews wrote:
>>>
>>> Amos,
>>>
>>> thanks for your reply. See my notes below.
>>>
>>> On Wed, Jan 9, 2013 at 1:55 AM, Amos Jeffries <squid3_at_treenet.co.nz>
>>> wrote:
>>>>
>>>> On 9/01/2013 5:27 p.m., Simon Matthews wrote:
>>>>>
>>>>> I am finding that some websites do not respond when queried through
>>>>> squid.
>>>>>
>>>>> I looked at this page, which suggests some solutions:
>>>>>
>>>>>
>>>>> http://squidproxy.wordpress.com/2007/06/05/thinsg-to-look-at-if-websites-are-hanging
>>>>> but I don't think it gives any useful suggestions. I tried setting the
>>>>> mss to 1200 without success.
>>>>>
>>>>> The basic reason that I don't think these suggestions are appropriate
>>>>> for the problems I am seeing is simply that queries from the same
>>>>> machine using telnet or wget (but not from squid) do get responses, so
>>>>> the problem appears to be related to squid, rather than the networking
>>>>> setup.
>>>>
>>>>
>>>> So where are the packets disappearing?
>>>>
>>>> The article is a bit old but those are still the main reasons. Nowdays
>>>> things are also compounded by IPv6 and ICMPv6 packets also having
>>>> ECN/PMTU/WSS issues, you need to check whether Squid is performing IPv4
>>>> or
>>>> IPv6 then followup carefully in each of those protocols. Note that wget
>>>> and
>>>> telnet can easily use a different version of IP with better results.
>>>>
>>>> If you can mention some specific sites (or better specific URLs) which
>>>> are
>>>> failing maybe someone can take a look and see if its just your or a
>>>> bigger
>>>> issue.
>>>>
>>> The site that is giving problems is http://www.dmv.ca.gov
>>>
>>> Here are some tcpdumps:
>>> wget, bypassing the proxy:
>>> tcpdump -i eth0 host 134.186.15.29
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>> decode
>>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>>> 19:51:53.580924 IP 98.248.55.206.34654 > 134.186.15.29.http: Flags
>>> [S], seq 3438916088, win 14600, options [mss 1460,sackOK,TS val
>>> 1020431 ecr 0,nop,wscale 7], length 0
>>> 19:51:53.603836 IP 134.186.15.29.http > 98.248.55.206.34654: Flags
>>> [S.], seq 3339908004, ack 3438916089, win 65535, options [mss 1380],
>>> length 0
>>> 19:51:53.603907 IP 98.248.55.206.34654 > 134.186.15.29.http: Flags
>>> [.], ack 1, win 14600, length 0
>>> 19:51:55.449109 IP 98.248.55.206.34654 > 134.186.15.29.http: Flags
>>> [P.], seq 1:16, ack 1, win 14600, length 15
>>> 19:51:55.673140 IP 134.186.15.29.http > 98.248.55.206.34654: Flags
>>> [.], ack 16, win 65535, length 0
>>> 19:51:56.776100 IP 98.248.55.206.34654 > 134.186.15.29.http: Flags
>>> [P.], seq 16:17, ack 1, win 14600, length 1
>>> 19:51:56.800028 IP 134.186.15.29.http > 98.248.55.206.34654: Flags
>>> [P.], seq 1:1136, ack 17, win 65535, length 1135
>>> 19:51:56.800099 IP 98.248.55.206.34654 > 134.186.15.29.http: Flags
>>> [.], ack 1136, win 15890, length 0
>>> 19:51:56.800118 IP 134.186.15.29.http > 98.248.55.206.34654: Flags
>>> [F.], seq 1136, ack 17, win 65535, length 0
>>> 19:51:56.801280 IP 98.248.55.206.34654 > 134.186.15.29.http: Flags
>>> [F.], seq 17, ack 1137, win 15890, length 0
>>> 19:51:56.828107 IP 134.186.15.29.http > 98.248.55.206.34654: Flags
>>> [.], ack 18, win 65535, length 0
>>>
>>>
>>> wget via the proxy:
>>> tcpdump -i eth0 host 134.186.15.29
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>> decode
>>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>>> 19:51:03.118935 IP 98.248.55.206.34653 > 134.186.15.29.http: Flags
>>> [S], seq 2175513684, win 14600, options [mss 1460,sackOK,TS val
>>> 1007816 ecr 0,nop,wscale 7], length 0
>>> 19:51:03.140282 IP 134.186.15.29.http > 98.248.55.206.34653: Flags
>>> [S.], seq 3122380782, ack 2175513685, win 65535, options [mss 1380],
>>> length 0
>>> 19:51:03.140361 IP 98.248.55.206.34653 > 134.186.15.29.http: Flags
>>> [.], ack 1, win 14600, length 0
>>> 19:51:03.140684 IP 98.248.55.206.34653 > 134.186.15.29.http: Flags
>>> [P.], seq 1:204, ack 1, win 14600, length 203
>>> 19:51:03.385677 IP 98.248.55.206.34653 > 134.186.15.29.http: Flags
>>> [P.], seq 1:204, ack 1, win 14600, length 203
>>
>>
>> Interesting. Packet being sent to the server but nothing arriving back
>> .... nothing at all.
>>
>> A 15 byte packet seems to get a response where a 203 byte packet does not.
>> I don't think this is a Squid problem, but appears to be a TCP/IP problem.
>>
>> Amos
>
>
> Looking into this a bit further I think it is a web server problem.
>
> When Squid emits the X-Forwarded-For header for IPv6 clients the server does
> not respond. I have seen some servers like these appear to be crash or the
> script generating the page crash when the X-Forwarded-For header contains
> detais they are not expecting (but are correctly in accordance with the
> definition of XFF header).
>
> You can avoid this with:
> acl noXFF dstdomain .dmv.ca.gov
> request_header_access X-Forwarded-For deny noXFF
>
> That will prevent the XFF being delivered to that broken site, but leave it
> in place for other sites which need it.

Thanks. That solved the problem.

I still have a problem with linkedin, but it is rather different. Some
pages (including the home page) load with only a subset of what should
be on the page. I don't know if this is an issue with squid or my
browser.

>
> Amos
Received on Thu Jan 10 2013 - 15:35:09 MST