Print

[jollino]

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?

[SenH]

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:

Code: [Select]

-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.

[kasperd]

Changing the mss in ip6tables didn't solve the problem.
I tried both ways:

Code: [Select]

-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:

What 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.

[kasperd]

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?

[ocin]

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.

[hansk]

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?

[mweinelt]

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