Greetings. I have a tunnel on one of the London servers and it's fantastic. Working a treat and has done for a long time. I noticed today that I was no longer able to browse youtube. Well I could browse the pages but not the videos. I was met with "an error occured please try later" on all videos. I've tried clearing browser cache etc to default. Even a different machine. I have noticed that if I disable ipv6 youtube works fine over normal ISP ipv6. Do you have any suggestions? I am not a master of ipv6 but learning all the time. Thanks muchly!
Quote from: mhisani on August 14, 2012, 08:15:47 AMI have noticed that if I disable ipv6 youtube works fine over normal ISP ipv6.
Was that really what you intended to say? The problems are not necessarily caused by your setup or the tunnel server. It could also be a problem on the youtube side. If anybody else using the same tunnel server would test it as well, then their feedback could help narrow down the cause.
If you want us to help debugging this any further, we will need more information to work with. Packet dumps showing which resources are being fetched in the two cases, and where it gets stuck in case of IPv6, would make it much easier.
It would also help if you'd mention your IPv4 and IPv6 addresses, such that we can probe your connection to see if there are any obvious problems with it.
Finally you can try to use a few of the IPv6 connectivity tests available on the net. I have one on http://netiter.dk/test-ipv6 and Jason Fesler has one on http://test-ipv6.com/
Update:I have noticed that many people still read this post, and visit the test link, I mentioned above (which btw is migrating to a new URL (http://test-ipv6.netiter.dk/)). So I figured that as long as I can still edit this post, I can use this section to provide as up to date information on the subject as possible.
Currently symptoms suggest the problem is on the YouTube side. It is not a problem on the client or the tunnel server. But various aspects can affect the frequency of the problems leading to the impression, that it might be a problem with a specific tunnel server. As of now, the best guess about a reason is this posting on page two of the thread:
Quote from: lozzd on November 01, 2012, 06:38:31 AM
I'm seeing a similar issue with the 403's.
If you use Chrome's developer tools on the "Network" tab you can watch it download chunks of the video.
The request is to http://o-o---preferred---sn-aigezn7y---v3---lscache6.c.youtube.com/videoplayback
and then a whole bunch of query parameters. Part of that parameter is the IP address... I can see my IPv6 address in there no problem.
What I think is happening is YouTube's security is throwing a wobbly, because Chrome is varying between requesting bits from IPv4 and IPv6. The reason for this is one I came up against recently on the customer portal of a DNS provider. Basically, whenever a request is made both an IPv4 and an IPv6 request are made for the same thing simultaneously and whoever sends the ACK back first, is the "fastest" so that connection is used. In the case of very well connected places (e.g. Youtube) the different between v4 and v6 is so negligable, a few milliseconds means one is faster, then the other. This means YouTube see some of the requests from v4, and some from v6, which triggers their protection.
Very annoying and AFAIK nothing you can do about it except not using IPv6.
I found a couple of IP addresses and tried traceroute. Nothing obviously wrong.
traceroute to mhisani-1.tunnel.tserv5.lon1.ipv6.he.net (2001:470:1f08:1d83::1), 30 hops max, 80 byte packets
1 2001:470:28:940:5d75:c1f4:e0a0:f8ec 0.366 ms 0.835 ms 15.189 ms
2 2001:470:27:940::1 62.462 ms 66.677 ms 56.864 ms
3 2001:470:0:11e::1 60.647 ms 21.930 ms 32.782 ms
4 2001:470:0:22f::1 58.123 ms 62.335 ms 77.702 ms
5 2001:470:0:3f::1 73.057 ms 70.236 ms 85.968 ms
6 2001:470:1f08:1d83::1 65.719 ms 65.879 ms 55.445 ms
traceroute to 2001:470:1f08:1d83::2 (2001:470:1f08:1d83::2), 30 hops max, 80 byte packets
1 2001:470:28:940:5d75:c1f4:e0a0:f8ec 0.367 ms 0.848 ms 6.814 ms
2 2001:470:27:940::1 67.239 ms 76.227 ms 70.950 ms
3 2001:470:0:11e::1 79.207 ms 47.050 ms 58.941 ms
4 2001:470:0:22f::1 76.449 ms 80.736 ms 84.112 ms
5 2001:470:0:217::2 91.184 ms 83.449 ms 84.022 ms
6 2001:470:0:67::2 73.255 ms 73.940 ms 69.212 ms
7 2001:470:1f08:1d83::2 89.540 ms 83.803 ms 87.994 ms
Well you seem to have got my address and sure enough ipv6 browsing etc works just fine. Both those tests you linked show me as 10/10 or all green and You are a winner! :)
Is there anything else you'd like from me? Apologies for not being quite the pros you guys are.
I guess it is possible it's youtube.
You have a problem with fragmented packets. If I do a traceroute to 2001:470:1f08:1d83::1 (which is the server side of the tunnel) using fragmented packets. It works just fine. If I do a traceroute to 2001:470:1f08:1d83::2 (which is the client side of the tunnel) using fragmented packets, I get no reply.
I don't know if that may be the reason for your problem. I think YouTube would use an MSS value low enough to avoid any such MTU issues. Your connection appears to handle 1472 byte packets just fine as long as they are not fragmented.
Quote from: mhisani on August 14, 2012, 09:46:59 AMBoth those tests you linked show me as 10/10 or all green and You are a winner! :)
I checked the log on my test to see which IPv6 address you accessed it from, I then tried to run a traceroute6 to that IP. I got no route to host errors from 2001:470:1f08:1d83::2 (which means they are send by your tunnel endpoint). The errors are ICMPv6 type 1 code 3.
1 2001:470:28:940:5d75:c1f4:e0a0:f8ec 0.510 ms 21.087 ms 21.738 ms
2 2001:470:27:940::1 69.427 ms 49.155 ms 55.285 ms
3 2001:470:0:11e::1 55.538 ms 40.181 ms 44.395 ms
4 2001:470:0:22f::1 72.385 ms 79.886 ms 82.161 ms
5 2001:470:0:3f::1 82.639 ms 82.828 ms 83.239 ms
6 2001:470:0:67::2 70.347 ms 74.742 ms 75.096 ms
7 2001:470:1f08:1d83::2 99.331 ms 100.719 ms 104.946 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * 2001:470:1f08:1d83::2 479.838 ms !H 352.091 ms !HI assume that means either the computer you accessed the test from is disconnected from the network right now, or it is using privacy extension and switched to a different IP address since then. Either way, I couldn't test to see if pinging that host behind your gateway would reveal more than just pinging your gateway.
Apologies I had to disable it on my pc due to needing to look on youtube.
First of all thankyou for being so helpful. I have renabled it on the pc
IPv6 Address. . . . . . . . . . . : 2001:470:1f09:1d83:ed5a:e61c:37a0:5720
Is what my pc is now. I will leave ipv6 on from now on.
Thankyou
Quote from: kasperd on August 14, 2012, 09:55:43 AMI think YouTube would use an MSS value low enough to avoid any such MTU issues. Your connection appears to handle 1472 byte packets just fine as long as they are not fragmented.
I tried to do a tcpdump while playing a video on YouTube. After being confused by the extremely large number of TCP connections involved in watching just a single video, I took a look on the MSS values.
I found that they would send three different MSS values in their SYN packets: 1410, 1416, and 1440. Subtracting 40 bytes of IPv6 header and 20 bytes of TCP header from your 1472 MTU gives an MSS value of 1412. That means if your gateway was one of the endpoints, it would use an MTU of 1412. But more importantly, any TCP connection you open on which the MSS is 1412 or less, should be immune to the MTU problem I noticed on your connection.
Comparing that with the observed MSS values I realize that I was probably mistaken when I thought YouTube would avoid those problems. Of the MSS values I observed, only the MSS of 1410 was small enough. The MSS of 1416 and 1440 would be too large for your tunnel, thus they would require PMTU discovery.
If the tunnel is correctly configured on your gateway, then PMTU discovery may still work, and the MSS sent by your gateway will be only 1412. But hosts on your LAN know nothing about the tunnel and presumably use native IPv6 when communicating with the gateway, thus those will use an MSS of 1440.
That means the segment size agreed upon by the endpoints while setting up the TCP connections is going to be too large, and PMTU discovery will be required. Some TCP stacks will not reduce the size of the segment that triggered the packet too big message. So one end of the connection will send a 1440 byte segment, which with TCP and IPv6 headers mean a 1500 byte IPv6 packet. That will trigger a packet too big error from the tunnel endpoint. The sending host could retransmit the segment as two smaller segments, but I have observed systems that instead will fragment the segment.
If the fragmentation issue that I mentioned earlier affects not just packets for the gateway but also the computers that you try to stream videos from, then it could cause TCP connections to stall.
This is all just a hypothesis, we would need to see actual packet dumps from your network to confirm it.
Okay I won't lie I do not know how to do what you're asking of me. Would you be able to point me in the right direction? Many thanks
Quote from: mhisani on August 14, 2012, 01:23:20 PM2001:470:1f09:1d83:ed5a:e61c:37a0:5720
That is different from the IP I found in my log. The IP you mention does not respond to ICMP echo requests, which makes debugging harder. I do believe it is the correct IP though as I observer different behaviour when I do a traceroute to that IP compared to other random IPs in your /64.
A traceroute to 2001:470:1f09:1d83:ed5a:e61c:37a0:5720 shows replies all the way until your gateway, then no replies from that point on. Which is most likely caused by the gateway forwarding the echo requests, and your computer ignoring them.
A traceroute to random addresses in your /64 OTOH results in no route to host errors from your gateway. The no route to host errors appear to show up only a few hops after the gateway, but that is probably just caused by the number of probes the traceroute command sends before the neighbour discovery times out on the gateway.
So I believe the difference I observe between the two IPs is due to the gateway actually performing a successful neighbour discovery on one IP and not on the other.
Figuring out what happens with regards to fragmentation is quite difficult when I cannot send a packet to the computer and get a reply. I have ideas for how I might be able to come up with some code changes on my end, that could find out more, but I don't know when I would have time to actually write that code.
If you can make your computer respond to echo request, I can certainly find out more.
It would also be convenient to look at some packet dumps. Do you have wireshark, tcpdump or something similar installed on the computer or the gateway?
I could use any tools like that admittedly I'd need to know how.
Also I managed to get IPv6 pinging working seems one of the windows firewall rules said reply to ping on local subnet only fixed that at least. hope that helps.
Quote from: mhisani on August 14, 2012, 02:53:37 PMI could use any tools like that admittedly I'd need to know how.
It would be most useful to run tcpdump on the tunnel endpoint itself and analyse the packet traces with wireshark afterwards. However it is probably easier to get started with those tools by just running wireshark on the computer that you are attempting to connect to YouTube from.
Before you try to access the video, start wireshark. Then choose to start a packet trace on the network interface you will use for the IPv6 communication. Next try to access the video. As soon as you get an error go back to wireshark and stop the capture. If you succeed in getting some actual packets this way, then choose to save the trace to a file.
Let me know if this is doable. Then I'll explain what we can do to analyse the dump.
Quote from: mhisani on August 14, 2012, 02:53:37 PMAlso I managed to get IPv6 pinging working seems one of the windows firewall rules said reply to ping on local subnet only fixed that at least. hope that helps.
It still doesn't respond. I can still see it is online as I get different result on that IP compared to others on the segment.
I noticed that your gateway does do something weird with fragmented packets. If I try to do a traceroute with fragmented packets to an unused IP on your network, I get no route to host replies from your gateway. Those no route to host replies contain the first fragment of the echo request packets. That is not surprising. However what is surprising is that I only get those messages back, if I send both fragments. If I only send the first fragment of a ping, then the gateway does not send the error back, even though it should.
It looks as if the gateway is trying to reassemble fragmented packets, which it is not supposed to do. The gateway might contain some sort of firewall that will reassemble fragmented packets in order to decide which filtering rules to apply.
I'm also seeing the same effect, in that I can quite happily view youtube video content on ipv4, but all video content errors with "An error occurred. Please try again later"
I have a Cisco 1812 (running 15.1) terminating a BT FTTC connection (PPPoE, but with RFC4638 so MTU is 1500) and terminating the HE.net tunnel, then all traffic goes through a Cisco ASA Firewall (running 8.4.4)
As this was working quite happily a few weeks ago (been on holiday...) and looking at my rancid diffs, there have been no changed to either the ASA or the 1812, I'm pointing the finger at YouTube....
Quote from: thermionic on August 15, 2012, 10:53:49 AMI'm also seeing the same effect, in that I can quite happily view youtube video content on ipv4, but all video content errors with "An error occurred. Please try again later"
You are also using tserv5.lon1. It could be that the YouTube streaming servers serving your area are to blame. I did some traceroutes towards your network, and I did not observe any MTU problems. And I could indeed transfer 1480 byte IPv6 packets in both directions.
Could either of you try to look up the AAAA record for mydnsv6.kasperd.net such that I can find out which DNS server you are using?
I do occasionally see the "An error occurred. Please try again later" error, but it always go away if I reload the page.
mhisani@joggler:~$ host mydnsv6.kasperd.net
mydnsv6.kasperd.net has IPv6 address 2001:470:0:67::2
Quote from: mhisani on August 15, 2012, 12:06:40 PM
mhisani@joggler:~$ host mydnsv6.kasperd.net
mydnsv6.kasperd.net has IPv6 address 2001:470:0:67::2
I tried switching to that DNS server. But that was not enough to reproduce the problem. Unfortunately that doesn't rule out any possibilities, as users coming through different tunnel servers can still be directed to different streaming servers through other means than DNS.
So, we are probably going to need some packet traces to have any chance of identifying the problem. Has either of you managed to dump some packets while attempting to access a video.
Youtube seems to be working. Looking into it to be sure.. if so it's annoying to not know the cause :/
I'm having the same issue, also using a FTTC connection (not with BT) on tserv5.lon1. MTU set to 1280 in advanced options to prevent fragmentation breaking. Everything else is working fine right now.. Just YouTube randomly giving me errors (sometimes in the middle of videos!). I'm not sure if it's intermittently working because occasionally its going via v4 and sometimes via v6 or whether v6 is just being flaky.
Quote from: lozzd on August 21, 2012, 08:29:19 AMMTU set to 1280 in advanced options to prevent fragmentation breaking.
Just in case somebody isn't aware. There is an MTU setting for each direction on such a tunnel. What you set in the webinterface is the MTU in the direction from the tunnel server to your own gateway. The MTU from your own gateway to the tunnel server is a configuration option on your own gateway.
If you want to avoid MTU problems on the tunnel itself, you can set the MTU in both directions to 1280.
That does however not eliminate all possibilities of MTU problems. What you are avoiding is issues with the IPv4 MTU, and if you go as low as 1280, you at the same time guarantee, that the tunnel is going to be the IPv6 hop with the lowest MTU.
But regardless of which MTU you choose for the tunnel, you are likely going to be in a situation where the MTU of the tunnel is lower than the MTU of the first and last hop of your TCP connections. That means neither end of the TCP connection know in advance, that the PMTU is lower. And thus PMTU is required on IPv6.
So, if you have MTU issues on your IPv4 connection to the tunnel server, you can fix it by tweaking the MTU settings of the tunnel. But MTU issues on the IPv6 connection cannot be solved that way.
Tracking down the root cause of failing PMTU discovery and getting the people responsible for it to fix it, is not always feasible. There is however a workaround, which can eliminate them in case of TCP. Just tweak the MSS value in the TCP SYN packets such that TCP won't be sending too large packets in the first place.
On your own gateway, you can modify the MSS of every SYN packet going through it. If the value is larger than 1220, then it should be reduced to 1220. If the original value is less than 1220, then it is left unmodified. Such a feature exists in ip6tables, and in other software as well.
Quote from: lozzd on August 21, 2012, 08:29:19 AMI'm not sure if it's intermittently working because occasionally its going via v4 and sometimes via v6 or whether v6 is just being flaky.
Yeah, you can really only find out by forcing it to always go over IPv6.
I have experienced situations where I could play videos on devices, which were forced to use IPv6 whenever available. And at the same time I could not play videos on devices, which were configured for IPv4 only.
Hi guys -
Just to let you know I'm seeing the same issues (going via tserv5.lon1). I noticed it when my iPad suddenly stopped playing all embedded YouTube videos, and my laptop gave errors on about 50%.
Have tried reducing the MTU on the tunnel to 1280 as suggested, and my first impression is that it seems to have helped. Will confirm...
Quentin
You should update your flash player maybe it helps.
i have encountered the problem/a similar problem at least 2 times
(Youtube with "An error occured please try again later")
- Flash updating didnt help
- sometimes IP4 seemed to work (Firefox about:config -> network.dns.disableIPv6 set to true)
but at the end i switched to a different End Point
After a while i switched back to London and i observed the problem again
- I cleared my youtube+google cookies
- Restarted dnsmasq on my Router with OpenWRT (Flush DNS Caches)
now i think it works again
maybe YT cookies/content protection(unavailability) on video cache servers gets broken with different locations
Edit: Maybe there are some side effects with short IPv6 privacy extensions ?
my radvd got pref. lifetime 1800
I'm having the same problem but I go through tserv1.zrh1.he.net, and this has been happening in the past few weeks alone for me. My gateway is a Raspberry Pi configured via ip (not ifconfig) and nothing changed on my end.
The MTU on the he-ipv6 interface is 1480 (same as on the tunnel server side), but I'm not sure on how to find the MSS, especially not for IPv6. Or are we talking about the 6in4 tunnel? Either way, "route -ee" shows a MSS of 0 for me.
I'm quite confused. :) Thanks for any insight!
Quote from: jollino on September 30, 2012, 09:27:14 AMI'm not sure on how to find the MSS, especially not for IPv6. Or are we talking about the 6in4 tunnel? Either way, "route -ee" shows a MSS of 0 for me.
First of all, the IPv4 MSS values do not affect the tunnel. MSS affects only TCP. And since the protocol you are running directly on IPv4 isn't TCP, the MSS setting on the IPv4 routes does not affect your tunnel.
In Ubuntu 10.04 I see quite an inconsistency between the "route" command and the "ip route" command. If I run "route -ee", I see all my IPv4 routes, and the MSS field says 0 for all of them. I am guessing that zero means that the MSS is automatically computed from the MTU. If I run "route -n6ee" I see all my IPv6 routes, but it doesn't show me the MSS value.
It appears the "route" command can only show the MSS for IPv4 routes. On the "ip route" command it is the other way around. If I type "ip route" I see all my IPv4 routes. There is no information about the MSS. If I type "ip -6 route" I see an all my IPv6 routes including the MSS. It does not show me zeros for any of the MSS values. Rather it shows me the actual value regardless of whether it was computed from the MTU or explicitly specified.
However be aware, that you most likely don't care about the MSS settings on your gateway. The MSS settings on your gateway only affects the TCP connections where your gateway is one of the endpoints. When a host on your LAN is communicating through your gateway with another host on the net, the MSS setting on the gateway doesn't affect the communication.
The hack to make MTU problems go away is not a change of the MSS settings on the gateway, rather the trick is to have the gateway modify the MSS on packets going through the gateway. One of the tools which can do this is ip6tables. I haven't tested exactly how ip6tables behaves, so I don't know how elaborate the rules need to be. The documentation gives an example:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuObviously it should be ip6tables instead of iptables, in order to handle IPv6 packets. I don't know if any other changes are needed to the command line, because it isn't clear from the documentation if --clamp-mss-to-pmtu is intelligent enough to do the right thing, or if you need to compute the MSS yourself.
A different rule, which I think might work better would be:
ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN --mss 1221:65535 -j TCPMSS --set-mss 1220But I haven't tested it.
Thank you for the clarification. I played around with it but I'm at a loss— I admit I don't know the inner details of TCP so I'm going through trial and error.
The ip6tables man page on the Debian-derived distro I have on the Raspberry Pi actually states:
Quote
TCPMSS
This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus 40 for IPv4 or 60 for IPv6, respectively). Of course, it can only be used in conjunction with -p tcp.
This target is used to overcome criminally braindead ISPs or servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too Big" packets. The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:
1. Web browsers connect, then hang with no data received.
2. Small mail works fine, but large emails hang.
3. ssh works fine, but scp hangs after initial handshaking.
Workaround: activate this option and add a rule to your firewall configuration like:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
--set-mss value
Explicitly sets MSS option to specified value. If the MSS of the packet is already lower than value, it will not be increased (from Linux 2.6.25 onwards) to avoid more problems with hosts relying on a proper MSS.
--clamp-mss-to-pmtu
Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6). This may not function as desired where asymmetric routes with differing path MTU exist — the kernel uses the path MTU which it would use to send packets from itself to the source and destination IP addresses. Prior to Linux 2.6.25, only the path MTU to the destination IP address was considered by this option; subsequent kernels also consider the path MTU to the source IP address.
These options are mutually exclusive.
(Note that it actually says iptables, not ip6tables.)
I have tried both the rule suggested in the manpage with ip6tables, and it gives no error... however it also changes nothing. Forcing it to 1220 bytes via the --set-mss also doesn't seem to work. The rules are properly added, however:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp anywhere anywhere tcpflags: SYN,RST/SYN TCPMSS clamp to PMTU
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp anywhere anywhere tcpflags: SYN,RST/SYN TCPMSS set 1220
Also, ip -6 route doesn't show any MSS info for me:
pi@raspberrypi ~ $ sudo ip -6 route
::/96 via :: dev sit0 metric 256
2001:470:25:2ad::/64 via :: dev he-ipv6 proto kernel metric 256
2001:470:25:2ad::/64 dev eth0 metric 1024
2001:470:26:2ad::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 via :: dev he-ipv6 proto kernel metric 256
ff00::/8 dev eth0 metric 256
ff00::/8 dev he-ipv6 metric 256
default dev he-ipv6 metric 1024
I had even tried rejecting v6 routing to 2a00:1450:4001:c01::/64 (via "ip6tables -A OUTPUT -d 2a00:1450:4001:c01::/64 -j REJECT") just to skip the whole problem, and it seemed to be working... until now.
Quote from: jollino on October 01, 2012, 08:22:36 AMThe ip6tables man page on the Debian-derived distro I have on the Raspberry Pi actually states
Now that you quote it, I do recall having read that version of the man page before. So looks like you just need to have 2.6.25 or newer in order for the ip6tables rules doing the right thing.
Quote from: jollino on October 01, 2012, 08:22:36 AM(Note that it actually says iptables, not ip6tables.)
They are similar enough that the author may have felt one man page to cover both was sufficient.
Quote from: jollino on October 01, 2012, 08:22:36 AMI have tried both the rule suggested in the manpage with ip6tables, and it gives no error...
That's good. If the rules can be added without giving an error, then the mss module must exist for ip6tables.
Quote from: jollino on October 01, 2012, 08:22:36 AMhowever it also changes nothing.
What makes you think it changes nothing? In order to verify if it changes anything, you can run tcpdump on both physical interfaces to see if the MSS value is decreased on packets passing through the gateway. Notice that the default packet size limit in tcpdump is too small to see the MSS on tunnelled packets. You need to increase it with the -s flag for tcpdump to see anything.
Quote from: jollino on October 01, 2012, 08:22:36 AMThe rules are properly added, however
I think using ip6tables-save is a better way to see the rules. It is supposed to dump all details. The command you used may leave details out.
Quote from: jollino on October 01, 2012, 08:22:36 AMI had even tried rejecting v6 routing to 2a00:1450:4001:c01::/64 (via "ip6tables -A OUTPUT -d 2a00:1450:4001:c01::/64 -j REJECT")
The default settings for REJECT are not great. It rejects with an ICMP code, which may not be understood. For TCP packets using --reject-with tcp-reset is more likely to give good results.
Well, I tried running tcpdump and the mss on both the he-ipv6 tunnel interface and the eth0 physical interface is indeed clamped to 1220 for outgoing packets. It's 1440 bytes on eth0, and appears to be both 1410 or 1440 bytes on he-ipv6 depending on the source. This happens both when the videos play and when the error occurs. MTU is 1480 so it should be safe.
The question is: how likely is it that it's actually youtube having issues on its ipv6 servers, maybe even at a higher level than TCP?
Quote from: jollino on October 01, 2012, 11:35:00 AMWell, I tried running tcpdump and the mss on both the he-ipv6 tunnel interface and the eth0 physical interface is indeed clamped to 1220 for outgoing packets. It's 1440 bytes on eth0, and appears to be both 1410 or 1440 bytes on he-ipv6 depending on the source. This happens both when the videos play and when the error occurs. MTU is 1480 so it should be safe.
It is theoretically possible that some link on the path has a lower MTU than your tunnel. But if the problem persists even when the MSS is being clamped to 1220, then it isn't an MTU problem. After all the MTU issue was just a guess, because that is something that is recurring with tunnels.
I haven't seen any problems persistent enough for me to really find out what was going on. (Or rather, on the occasions where I have seen a persistent problem, it turned out to be the flash plugin that needed to be restarted.)
Quote from: jollino on October 01, 2012, 11:35:00 AMThe question is: how likely is it that it's actually youtube having issues on its ipv6 servers, maybe even at a higher level than TCP?
It is possible. I can't say what the probability of that is. But I mentioned this thread to a person I know, who actually works on YouTube, then we'll see what happens.
Thank you very much for your help and patience. :)
It's not the Flash plugin in my case, because this happens even when using things like ClickToFlash (which replaces YouTube's flash player with an html5 video element for the mp4 file), and it also happens on my father's iPad (using the 'mobile' version of the site.)
I thought that maybe there may be some actual issue on the web side of YouTube because I noticed earlier that Safari's developer console showed that the video file in question "could not be found on the server", though I couldn't manually try and open the video's direct address as it didn't carry the session over.
Unfortunately Safari 6's developer console is a big step backwards from previous versions, and there's no way to see all the files being downloaded as part of a page unless you open the console before loading the page, and even in that case it's fairly convoluted. The old activity window was perfect for this kind of debugging, even if you were not planning to do it before opening a page. Chrome isn't much better. Oh well, if I manage to catch it in the act I'll be sure I report here. :)
EDIT: Talk about perfect timing. Right after posting this, I had a video choke a couple of minutes in (I noticed that YT downloads 240p and 360p videos in chunks, getting the next only when the current one is halfway done or so.) I happened to have the console open, and it tried to GET four insanely long URLs and several of them report HTTP 403, while the others have no specific message in the console but show a red X.
I'm seeing a similar issue with the 403's.
If you use Chrome's developer tools on the "Network" tab you can watch it download chunks of the video.
The request is to http://o-o---preferred---sn-aigezn7y---v3---lscache6.c.youtube.com/videoplayback
and then a whole bunch of query parameters. Part of that parameter is the IP address... I can see my IPv6 address in there no problem.
What I think is happening is YouTube's security is throwing a wobbly, because Chrome is varying between requesting bits from IPv4 and IPv6. The reason for this is one I came up against recently on the customer portal of a DNS provider. Basically, whenever a request is made both an IPv4 and an IPv6 request are made for the same thing simultaneously and whoever sends the ACK back first, is the "fastest" so that connection is used. In the case of very well connected places (e.g. Youtube) the different between v4 and v6 is so negligable, a few milliseconds means one is faster, then the other. This means YouTube see some of the requests from v4, and some from v6, which triggers their protection.
Very annoying and AFAIK nothing you can do about it except not using IPv6.
I think you nailed, lozzd, especially your last sentence. I tried preventing my gateway from dropping v6 requests to youtube, as described on this thread, but I couldn't get it to work and I don't have enough time to fiddle around ip6tables, so I just ended up disabling ipv6 altogether for the time being, since other people in my network cannot disable ipv6 connectivity locally (iOS responds to router advertisements and abides). Quite frustrating.
I wonder if there's any way to get someone from the Youtube team to peek at this thread?
I'm experiencing the same youtube behaviour.
Setup is an Ubuntu router with an MacOS X client.
Changing the mss in ip6tables didn't solve the problem.
I tried both ways:
-A FORWARD --proto tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1420
-A FORWARD --proto tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Only solution for now is disabling ipv6 on the MacOS X client.
Quote from: SenH on November 01, 2012, 07:13:20 AMChanging the mss in ip6tables didn't solve the problem.
I tried both ways:
-A FORWARD --proto tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1420
-A FORWARD --proto tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
I think the hypothesis about MTU issues has been disproved by now. At least it is not the only source of problems.
From what I have seen myself since the start of this thread, I can say for sure that I experience two different problems. One of them is related to the flash plugin and when that triggers, the problem persists until I kill the flash plugin and let the browser restart it. Sometimes I have noticed that sound disappears a few minutes before the flash plugin completely stops working.
One person in this thread did have an MTU issue, but it is unclear if that affected youtube. Clamping the MSS to 1220 on in- and outgoing SYN packets is pretty much guaranteed to eliminate MTU issues on TCP connections. I have been clamping the MSS on my tunnel the entire time, so the other problem affecting me is not an MTU problem.
As I looked through this thread again, the only other hypothesis I saw mentioned was this one:
Quote from: lozzd on November 01, 2012, 06:38:31 AMWhat I think is happening is YouTube's security is throwing a wobbly, because Chrome is varying between requesting bits from IPv4 and IPv6.
That would explain why the problem goes away when running IPv4 only. If that theory holds, then it should be possible to avoid the problem by running IPv6 only. But when I have tried to access YouTube over IPv6 only connectivity, it wasn't working either. That seems to be a different problem though. Sometimes the AAAA records points to addresses that don't respond, and there is going to be a timeout.
One could log information about which hostnames are being accessed, which of those hostnames are dual stack, which of them are IPv4 only, and which of the IP addresses actually respond to HTTP requests. That might help identify why it sometimes works and why it sometimes doesn't.
If anybody want to run YouTube on IPv4 only, but still have dual stack connectivity for everything else. You either need to delete AAAA records from dual stack hostnames during DNS lookups, or block the TCP SYN packets. If you have a list of IPv6 addresses used by YouTube, you can use ip6tables to prevent outgoing SYN packets to those addresses by using --reject-with tcp-reset.
A few times I have seen YouTube play an ad first, then as soon as the video is supposed to start, it gives an error. If you reload the page it will play the ad again and fail again once the video is about to start.
Seems there is never any problem playing the ads. So whatever method YouTube is using to play the ads may be more reliable, and they should use the same method for playing the actual content.
Did anybody else see similar behaviour?
I have the same problem. The YouTube chunks don't get loaded - I get HTTP 403 forbidden (from for example r5---sn-2apm-f5f6.c.youtube.com). BUT this is only for videos who are blocked in my country. When I try to view them via IPv4, I get the regular "Video not available because of ..." message, if I use IPv6 it seems to load but it just says "An error occured" and I get a 403 on the video chunks. My guess is that google updated their country detection. But it must have blacklisted he.net in some way then, because when I disable IPv4 completely it can only see the tunnel IP. This needs more investigation.
Edit: As of now it magically works again.
I'd like to dust off this topic.
It's quite frustrating trying to access youtube over IPv6 with IPv4 turned off. I'm getting the usual "An error occured, please try again later"
My setup is a laptop running "Arch Linux" behind home router with tunnel on it. I am able to run wireshark on the laptop and tcpdump on the router.
When I turn on IPv4, youtube starts working with majority traffic 90%-95% over IPv6
Is this a problem with my setup or everybody else is still having the same problem?
Hey all of you!
I experienced the same. YouTube unable to playback any video. For me this was related to having disabled RC4 in my Browsers. Maybe for some of you it is the same.
Cheers, mweinelt