On 23/10/2012 11:49 a.m., Matthew Goff wrote:
> On Sun, Oct 21, 2012 at 9:14 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> Do you have any info on how far into the system the packets supposedly going
>> to Google get before the hang? and what happens (or not) to cause hang?
> Thanks; that was enough to get me thinking about this a bit
> differently. I ran Wireshark on my Squid box monitoring the bridge
> interface and the issue seems to be MTU related. The MTU on my HE.net
> tunnel (all my IPv6 traffic) is 1280 on my edge router. The Wireshark
> capture of attempting to access google.com showed frames going through
> larger than that, followed by the ICMPv6 too big message listing the
> 1280 MTU. The too big messages were from the LAN side of my edge
> router directed to my client machine. The other test website I tried
> was ipv6.whatismyipv6.com which only had one or two packets with a too
> big error after which the MTU was respected.
>
> A cursory Google search (after shutting down my v6 on my client) only
> found one similar instance but it was related to a buggy VMware
> driver, and impacted all v6 traffic. Google is really the only site I
> can reliably repeat this failure over v6 on, and prior to redirecting
> my v6 traffic through Squid (same network layout otherwise) I did not
> have this issue. I tried enabling httpd_accel_no_pmtu_disc and had the
> same results, so I'm not certain where else to go with this but am
> happy to provide any further details needed.
If I am reading that correctly you are saying the ICMPv6 'too big'
packets are not going to Squid, but to the client machine?
Which would make it a TPROXY bug, since the outbound connection from
Squid is where the MTU should be lowered at the kernel level.
Or are they *addressed* to the client machine and caught by TPROXY
properly but MTU not respected?
Amos
Received on Tue Oct 23 2012 - 03:40:56 MDT
This archive was generated by hypermail 2.2.0 : Wed Oct 24 2012 - 12:00:04 MDT