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
Received on Thu Jan 10 2013 - 03:45:53 MST
This archive was generated by hypermail 2.2.0 : Thu Jan 10 2013 - 12:00:03 MST