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.
Amos
Received on Thu Jan 10 2013 - 06:24:31 MST
This archive was generated by hypermail 2.2.0 : Thu Jan 10 2013 - 12:00:03 MST