YouTube loading issues? Possible solution?

Discussion in 'Tomato Firmware' started by binarystarz, May 3, 2013.

  1. binarystarz

    binarystarz Reformed Router Member

    Blocking certain IP ranges from YouTube to hit their "cached" servers seems to improve YouTube buffering performance (at least in my case with Time Warner isp), so i thought i would share this information, granted its seem to help my case with YouTube buffering.

    No this won't fix YouTube if you're isp can't get to the speed rates required to stream a YouTube. So please speed test or check for internal congestion before applying this workaround. Granted, i'm not alone, this fix seems to work for the Reddit community.

    Blocking these ip ranges seems to have helped:

    Here is the script for tomato to put in your Firewall script to try this fix(Administration\Scripts\firewall)

    # Block Youtube Cache Servers
    iptables -A INPUT -s -j REJECT
    iptables -A INPUT -s -j REJECT

    I am using a WRT54GL (i know, its old, but YouTube buffering standard def doesn't require ultra fast router) on Shibby K26 builds (108). I'm not certain, but I think the K24 builds should accept this script as well. If you have a better solution, please let me know, or if this is "snake oil", but it seems to be working for me for at least a couple of days. However, this might not work for NON-USA users or users of different ISPs. IF you have buffering issues, please let me know your thoughts/suggestions
  2. darkknight93

    darkknight93 Networkin' Nut Member

    Here in Germany - ISP: Kabel Deutschland this iptables roules just do the trick. Buffering is gone - even 1080p Videos stream immediately
  3. ladysman

    ladysman Network Guru Member

    This is interesting. i'll put it in my router when i get home.
  4. M0g13r

    M0g13r LI Guru Member

    @ darkknight93 wie bistn zufrieden mit kabel deutschland ?
  5. Toastman

    Toastman Super Moderator Staff Member Member

    Thanks for that rather interesting tip, I'm going to try it here in SE Asia!
  6. darkknight93

    darkknight93 Networkin' Nut Member

    @M0g13r: Sehr sehr sehr zufrieden. Zuest 3 Jahre 32/2 stabil, jetzt seit Feb 100/6 - fullspeed in beide Richtungen:

    Für den Packetloss war ich schuld. Bekomme leider nur noch eine öffentliche IPv4 nicht mehr 2... das SamKnows EU Kisterl hängt in ner DMZ - hatte vergessen beim Flashen die Box auszumachen...

    Download gerade beim Microsoft MSDN Server: 13,9MB/s down ^^

    Translation: German ISP "Kabel Deutschland" is a finee fine ISP! Gets fullspeed 100MBit/s down and 6 MBit/s up.
    I participate in the europe-wide SamKnows broadband test - so this is the result you get:
  7. koitsu

    koitsu Network Guru Member

    I'm still on hiatus, but I saw this thread and absolutely had to say something. I've debunked these "block inbound packet" claims already on a different forum:

    Multiple things here:

    1. Keep in mind that the rules listed in the above thread were for outbound packets, not inbound. The INPUT iptables chain -- which is what your rules are using -- are broken/bad. What happens is that you send out a TCP SYN, which the server responds to with TCP SYN+ACK, and the router ignores/drops. That's extremely rude and makes a big ugly mess on a) the server side, b) the client side, and c) the NAT layer. Don't do this. What you really wanted was to use the OUTPUT chain -- but keep reading before going off and changing your rules. And in some cases, you might actually want this stuff in the FORWARD chain (really).

    Point to take away: nobody seems to understand what the hell the rules actually do except for people who have familiarity with networking protocols. End-users "trying to fix Youtube slowdown" is akin to 90 year old grandmothers trying to write Linux kernel code because Regis Philbin told them to. Sound stupid? Exactly.

    2. If you read the above thread in full -- specifically my posts and those who responded -- you will see that I debunked the idiocy someone proposed on Reddit. I asked for hard evidence/proof, providing packet captures (because the supposed rules that were proposed would indicate that TWC was actually doing some kind of TCP payload manipulation -- I explain it in this post). Only one user stepped up to the plate (user ke4pym) -- and that user proceeded to say "this 'fix' did nothing for me". Yes, it did nothing -- because those people have no bloody idea how load balancing works (Youtube uses MULTIPLE KINDS).

    3. Did you even look at who owns those netblocks? Did you even verify the size (netmask/bitlength) was correct (i.e. matched what's advertised via BGP)? Nope. isn't advertised (go look at route views and see), it's instead part of However, there are other /24s which are advertised separately, but is not one of them. Secondly, the first netblock you list off is owned by XO Communications.

    4. I've already discussed the reason for "Youtube slowdown" on this forum as well:

    Read it in full -- do not skim it. You will see the complainer eventually comes to accept the reality of the situation (and what I have said above)

    Bottom line: unless you're familiar with network troubleshooting (and by familiar I mean doing it professionally for a good 10+ years), all of these ""solutions"" are snake oil. I have lots of educated guesses as to what the root cause is, but so far nobody has provided the hard evidence I've asked for, because what's been described on Reddit is borderline nonsense. Have I experienced "slow Youtube syndrome?" Absolutely -- have I taken the time to look at packet captures + do the analysis to find out why? Absolutely. And it's not something "magical firewall rules" can alleviate.

    I get the impression some idiot on Reddit came up with this "solution" without even understanding how Youtube does its load balancing, threw together some very broken/stupid firewall rules that do nothing, then (due to how Youtube does their load balancing) was like "OMG THIS WORKS". No, no it doesn't. Thankfully if you read some of the ball-deep-within-the-thread posts in reply to that Reddit topic, you'll see some very smart/clever people in there who point the W-T-F nature of what was proposed.

    I will not be responding to this thread past this point. Back to my hiatus...
  8. darkknight93

    darkknight93 Networkin' Nut Member

    Thanks for your Input Koitsu! in fact, killing the three way handshakes was not the Thing i meant to do and is not the way to solve Problems! I totally appreciate your Input.

    So whats wrong with some ISPs that "only" YouTube buffers slow? I'll read through the other threads and see if I can clarify that...
  9. Toastman

    Toastman Super Moderator Staff Member Member

    I'll add that I did try that script (as-is) and noticed absolutely no difference at all.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice