Someone suggested to disable pmtu on squid and on the linux gw. I was able to disable it on linux: echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc That hasn't change anything. Now, do I really need to disable it on squid in order to work? I read this: disable-pmtu-discovery= Control Path-MTU discovery usage: off lets OS decide on what to do (default). transparent disable PMTU discovery when transparent support is enabled. always disable always PMTU discovery. In many setups of transparently intercepting proxies Path-MTU discovery can not work on traffic towards the clients. This is the case when the intercepting device does not fully track connections and fails to forward ICMP must fragment messages to the cache server. If you have such setup and experience that certain clients sporadically hang or never complete requests set disable-pmtu-discovery option to 'transparent'. but, that option is "unrecognized" by squid. Is it really necessary to disable it on squid? If so, how? I'm running 3.0.24 and 3.1.9. Thanks. --- On Fri, 11/12/10, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > From: Amos Jeffries <squid3@xxxxxxxxxxxxx> > Subject: Re: Problems with hotmail and facebook > To: squid-users@xxxxxxxxxxxxxxx > Date: Friday, November 12, 2010, 1:46 AM > On 12/11/10 19:20, Landy Landy > wrote: > > > > > > --- On Fri, 11/12/10, Amos Jeffries<squid3@xxxxxxxxxxxxx> > wrote: > > > >> From: Amos Jeffries<squid3@xxxxxxxxxxxxx> > >> Subject: Re: Problems with hotmail > and facebook > >> To: squid-users@xxxxxxxxxxxxxxx > >> Date: Friday, November 12, 2010, 12:05 AM > >> On 12/11/10 15:44, Landy Landy > >> wrote: > >>> Amos. > >>> > >>> Thanks for your quick reply. > >>> > >>> I haven't tried a newer version yet. The > problem > >> started two days ago and I've been using that > version for > >> over a year now and it worked well. > >>> > >>> --- On Thu, 11/11/10, Amos Jeffries wrote: > >>> > >>>> From: Amos Jeffries > >>>> On 12/11/10 15:11, Landy Landy > >>>> wrote: > >>>>> Hello. > >>>>> > >>>>> Our network is experiencing problems > loading > >> or > >>>> accessing facebook and hotmail inbox and > others > >> when I use > >>>> squid. I am using: > >>>>> > >>>>> I use google's public dns and our > local isp > >>>> provider's. > >>>>> > >>>>> I tried to login to my hotmail account > and got > >> this: > >>>>> > >>>>> Squid Cache: Version 3.0.STABLE24 > >>>>> configure options: > >> '--prefix=/usr/local/squid' > >>>> '--sysconfdir=/etc/squid' > '--enable-delay-pools' > >>>> '--enable-kill-parent-hack' > '--disable-htcp' > >>>> '--enable-default-err-language=Spanish' > >>>> '--enable-linux-netfilter' > >> '--disable-ident-lookups' > >>>> '--localstatedir=/var/log/squid3.1' > >> '--enable-stacktraces' > >>>> '--with-default-user=proxy' > '--with-large-files' > >>>> '--enable-icap-client' > '--enable-async-io' > >>>> '--enable-storeio=aufs' > >> '--enable-removal-policies=heap,lru' > >>>> '--with-maxfd=32768' > >>>>> > >>>>> When I try accessing these pages > without > >> having to > >>>> pass through squid everything works fine. > >>>>> > >>>>> Does anyone has an idea of what can be > causing > >> this? > >>>> > >>>> Could you give any details about what the > problems > >> actually > >>>> are please? > >>> > >>> Noticed that hotmail sometimes just hangs > after > >> providing the username and password. People > started calling > >> today and are driving me crazy. > >>> > >>> Also today I noticed this (Response not valid) > when > >> replying to a thread on dslreports.org: > >>> > >>> //////////////////////////////////// > >>> > >>> Mientras se intentaba procesar la petición: > >>> > >>> POST > /speak/wisp?enc=L2ZvcnVtL3dpc3A%3D;really > >> HTTP/1.1 > >>> Host: www.dslreports.com > >>> Connection: keep-alive > >>> Referer: http://www.dslreports.com/speak/wisp?enc=L2ZvcnVtL3dpc3A%3D > >>> Content-Length: 2580 > >>> Cache-Control: max-age=0 > >>> Origin: http://www.dslreports.com > >>> Pragma: no-cache > >>> Content-Type: multipart/form-data; > >> boundary=----WebKitFormBoundarynmpKtsJY1cReuJwT > >>> Accept: > >> > application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > >>> User-Agent: Mozilla/5.0 (X11; U; Linux i686; > en-US) > >> AppleWebKit/534.7 (KHTML, like Gecko) > Chrome/7.0.517.44 > >> Safari/534.7 > >>> Accept-Encoding: gzip,deflate,sdch > >>> Accept-Language: en-US,en;q=0.8 > >>> Accept-Charset: > ISO-8859-1,utf-8;q=0.7,*;q=0.3 > >>> Cookie: > >> > __utmz=260971928.1285198857.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); > >> > __utma=260971928.458537925.1285198857.1285422374.1285465733.3; > >> dsl=6402462798:1587616; bbruid=1587616 > >>> > >>> Ha ocurrido el siguiente problema: > >>> > >>> Respuesta no válida. > >>> > >>> El mensaje de Respuesta HTTP recibido del > servidor > >> contactado no pudo ser entendido o tenía alguna > >> malformación. Por favor contacte al operador del > sitio web. > >> Quizas su administrador del caché pueda darle a > Ud. más > >> detalles acerca de la naturaleza exacta del > problema en caso > >> de ser necesario. > >>> > >>> Su administrador del caché es optimumwireless@xxxxxxxxxxxx > >>> > >>> //////////////////////////////////// > >>> > >>> Things are not as they used to be. I checked > the > >> cache.log file and can't find anything there. What > do you > >> recommend me to do? > >>> > >> > >> The POST is requesting "sdch" (aka binary diff > encoding) > >> responses. If > >> you or any other proxy along that supply path are > doing > >> anything with > >> ICAP besides straight AV scanning that could be > corrupting > >> the diffs. > >> > >> The problem is in the response to that POST. The > newer > >> 3.1.9 logs what > >> the problems is at debug level 1 ("debug_options > ALL,1") > >> including the > >> URL for tracking. > >> > >> With that info you can drill down into the > oprocessing are > >> or a tcpdump > >> log and find out what the response actually is. > >> > > Amos, > > As I mentioned earlier, I noticed the problem happen > on website running AJAX code. I don't know if it makes sense > but, hotmail, yahoo, and facebook all use ajax... and > by the way 3.1.9 hasn't really change anything. > > I know. The mechanism used to make the requests does not > affect the > debugging process. They are all just HTTP traffic by the > time it reaches > Squid. > Since 3.1 has not fixed it I suggest you take > advantage of its > slightly better debug output to help track down the > problem. Then if the > speed is an issue revert to 3.0 to use the workaround > found. > > Amos > -- > Please be using > Current Stable Squid 2.7.STABLE9 or > 3.1.9 > Beta testers wanted for 3.2.0.3 >
