1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

QoS Not Doing What I Thought It Did On My fap-montior.sh Script

Discussion in 'Tomato Firmware' started by DW_Duck, Feb 9, 2009.

  1. DW_Duck

    DW_Duck Addicted to LI Member

    Hi All,

    Usually I seem pretty smart, but apparently I either don't know what QoS settings are for or I don't know how to use them. I have put a LOT of work into this script that is supposed to choke the connection off before you exceed Hughes Net Fair Access Policy (FAP) Limits. I thought I could use QoS settings to choke down the internet connection to about 16 kbits/sec to prevent being FAPed (24 hours without service) and so that the user would know to lay off for awhile.

    Last weekend I finally got a chance to test it. The counting algorithm seems to work good. The problem is, when I approached the FAP limit and the script did
    nvram set qos_obw=3
    nvram set qos_ibw=13
    the connection didn't slow down at all. In fact, it was going really fast. Luckily I was watching it. I had to scramble to shut things down so I didn't get FAPed.

    Does QoS not throttle the connection like I thought it did? If so, it seems my only option is to shut down the connection to avoid being FAPed? I have enabled QoS using the web interface.

    Thanks for help,

    Attached Files:

  2. rhester72

    rhester72 Network Guru Member

    You did do a "service qos restart" after the nvram changes, yes?

  3. DW_Duck

    DW_Duck Addicted to LI Member

    No. Am I supposed to?

    Ok, you don't have to answer that yes/no question. Sounds like that's my mistake. Do you know of a documentation FAQ or something I should have read to get this information?

  4. DW_Duck

    DW_Duck Addicted to LI Member

    OMG - I'm So Dumb

    http://vonage.nmhoy.net/qos.html points out that you can't limit incoming traffic from your router - all you can do is drop incoming packets. Duh. This is going to take some re-thinking. You can limit outgoing ACKs apparently, but that doesn't affect UDP traffic. Maybe I can make use of restricting ACKs at the "Caution" level and then kill the connection completely when I hit the "Danger" level. I wonder what Hughes Net does about UDP traffic. You could play a dirty trick on someone and FAP them from afar by blasting UDP packets at them. Hughes Net must filter that somehow.
  5. rhester72

    rhester72 Network Guru Member

    Ah, yes, I apologize - if your objective is to block incoming traffic, short of using iptables rules to literally block the port, there isn't much that can be done.

  6. Toastman

    Toastman Super Moderator Staff Member Member

    What about dumping UDP into a separate class, and limit it severely, or just kill it off altogether at the right time? Working on the assumption that any incoming traffic to your router has been requested by your own software, then there is a way to limit it ...
  7. DW_Duck

    DW_Duck Addicted to LI Member

    Yes, I think you just have to assume that incoming UDP traffic was requested somehow by outgoing UDP traffic. I think it will work by severely limiting outgoing ACKs and outgoing UDP at the proper time. I haven't had a chance to work on it again since though. I have to wait for my wife to be gone so if I do get FAPed and kill our internet connection she doesn't kill me.

Share This Page