On 23/10/2012 11:49 a.m., Matthew Goff wrote:
On Sun, Oct 21, 2012 at 9:14 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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
