On Wed, Jan 9, 2013 at 10:24 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> >>> 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
