Using QOS - Tutorial and discussion

You have changed the default class to something quite high, and are now trying to classify Torrents with a port number? This is a very bad move and as you can see it doesn't work. You don't need a rule for torrents, that is the purpose of the default class, and why it is set to a low priority. Any traffic NOT explicitly covered by a rule will end up there, this is the only way to trap [almost] all P2P traffic. You should read through the QOS thread again if this isn't clear. You may find a small amount of P2P traffic "leaks" into another class - this usually isn't a big deal.

cannuck_bob - No idea, but clearly your QOS isn't working. If you need help then you must post your QOS setup and full details of your ISP connection, and measured up and down speeds.

Toink - the ppoe/httpd issue is fixed but waiting for Vic, who is fixing the RAF IP/MAC section. There's nothing special to upgrade for, so I'm in no hurry.

CB - Try the following:

a) Set Outbound Max Bandwidth Limit at 650 kbit/s - This is important.
b) Inbound Max Bandwidth 8000
c) To begin with, set your P2P class rate to 5% and limit to 10%
d) Next, set all incoming class limits to 50% except for Highest and HIGH, leave these at 100%.

You should now see some improvement and have somewhere to start with your adjustments.

I suspect that you may not have set a) correctly, or maybe your class limits, because most of the rules you have should be reasonably OK.

Now, I see you've made an extra rule for torrents using L7 filter. The L7 bittorrent filter doesn't work well, and it can actually make things worse by preventing connections entering the default class - or it may help. You must test this yourself. Normally, you would delete that rule and make sure your default class is D. Now, as you are probably aware, this means that ANYTHING not expressly covered by a rule will end up in the default class. This is the only way to address P2P in any meaningful way if you don't know the machine and/or port numbers in use. In your case, you do for at least one machine, hence your rule for uTorrent.

However, you will find that a P2P application like uTorrent CAN and WILL use ports that are covered by other rules. There will always be some of those and you just have to accept some "leakage". For example the skypeout L7 filter lets a lot of P2P though which will get the priority you intended for skype(out). It is better to prioritize skype by the IP or MAC of the machine in use. Minimizing the number of ports you prioritize in the rules will cut down the number that can be "poached" by P2P. I see at a quick glance that you are in fact prioritizing around 1000 ports, mostly in the high class. That is a recipe for disaster.

The next thing is to set proper rates and limit on outgoing stuff and also limit the incoming classes so that traffic congestion is unlikely to occur. You didn't post your settings though so I can't comment.

Best way to set things up is to find your ISP gateway IP and set up a continuous ping to it. (-t)
It's not much use to ping the gameserver since the path to it will continually change and the results won't be clear. The gateway IP is the closest to you and that is what you need.

Adjust the setting you wish to experiment with and then save it. Watch the ping time and see how it responds.

Since your ping time (to the gameserver?) is very long, traffic congestion is occurring. It's probably due to P2P. Firstly, make sure it isn't occurring on your outgoing data by setting limits below 650 on that class, then adjust the incoming class limit. To begin with, set limits low, say 50%. Once things begin to work, experiment with increasing them. Don't set any limit on the important classes, highest and high in your case.

For best latency for games and VOIP, it is important not to allow the incoming data stream to exceed about 66% of your incoming bandwidth, which is about 5Mbps in your case. You can check that with the realtime and 24 hour graphs. Yes, I know that means a lot of your bandwidth is not being used. That's why it is available for your VOIP when it needs it.

You might find it helps to move your steam and KF rules higher in the list (below DNS) so they don't have to traverse all the rules.

Note that Port 3478 is already covered in the 9th rule, so is going into MEDIUM class. 28852 is in rule 3.

Now it's down to you to make the adjustments for your particular setup. You can get help by reading through the QOS thread below.

Without seeing a complete post of your QOS setup, it's impossible to say, but I don't see any reason for that.

A lot of people want to try a kernel 24 build of IPV6 on their older MIPSR1 routers. ipv6 on K24 isn't really working and may never be fully implemented. Look on tomatoUSB.org for information and a test build, but be warned, it isn't really a great idea.

New version 7441 for MIPS R2 (RT-N16 etc) built from latest code as of 26 January 2011 except for NVRAM Size detect function. NB - The IPV6 may have broken IP/MAC Limiter, this will (hopefully) be fixed in 7442!

ADDITION:

READ THIS PLEASE

From Wes - who did many of these mods

WES has now posted a small K26 build that should keep you happy! http://ifile.it/91nerpt/tomato-K26-1.28.9054dMIPSR2-beta-RT-ipv6-Std.trx

There have been a few people here and on tomatousb.org who have been experimenting with hurricane electric. But you'll just have to go search! This is a good place to start: http://tomatousb.org/forum/t-285632/ipv6-features

Updated build 7444 posted with all latest additions from git repository. Feedback welcome!

Perhaps people would find it useful if you would post your setup details here - several people wrote to me and said they'd like to try it too. If you have time, of course!

Yes, something is wrong, but I don't get the same as you. It starts and runs ok, but here the upload limit isn't working - the download is OK. In 7440, (which is a K26 build) the reference to qoslimit.c ipt_IMQ was changed to xt_IMQ - I thought this had fixed things.

Thanks for the feedback on CTF !

Hi shibby! Yes, I see no IMQ now.

That means you cannot use this in conjunction with QOS. Since this is one of the primary reasons people tell me that they want it, I'm not going down that path. Maybe if you could set upa new chain and limit inside it, then you could get it to work without IMQ and still in conjunction with QOS. Remember, most people use Tomato because of the QOS and they do expect everything to work, without having to trawl through forums to find out under what conditions it may or may not work...

I have not posted a new version yet until Victek has released his own mod and code.

Thanks nordberg !

There will be a new issue 7448 shortly, I am just finishing it off now. Sorry your download was slow, I was testing the new Limiter code, which as you can see worked.

You will see some changes in the "About" page. So what is this about?

Vic and Shibby have recently changed the RAF code, now called IP/Range Limiter, which had a bug following code changes due to the ipv6 support in the TomatoUSB base. At the same time, but independently, Deon Thomas "PrinceAMD" had been working on a fix using a different approach, and this is what I decided to put in this build. So there's now a choice available - see which one you like best. Both sets of code are now in the git repository if anyone wants to experiment.

Deon's code uses 2 imq devices, one for upload and one for download, they can be seen in the realtime and 24 hour graphs which allow monitoring. It is in fact a QOS system in itself, with a priority system, and is similar to Victek's old system. Also, this version does allow the limiter to work together with standard QOS, there should be no conflicts because the rules operate in different chains to the QOS system.

Here are three ways to use this limiter:

a) It can be used independently of QOS in which case it can be used as a "mini-QOS" in its own right, with priorities assigned to each rule - together with bandwidth limits and restrictions on UDP and TCP connections as before.

b) It can be used in conjunction with QOS - in which case whatever is the lower of the two limits will be the ultimate bandwidth limit. This could be useful as an emergency measure to limit a client who is taking more than his fair share of bandwidth, and normal QOS means and threats of knocking his teeth out have proved ineffective.

c) By entering an IP or MAC and setting no limit (set figures at the maximum speed of your connection) you can use this to monitor a particular user's bandwidth useage on the graphs.

d) You can use it to do nothing more than set an incoming overall maximum bandwidth limit, which is the thing that is missing from standard QOS. That can be used to prevent the incoming link from becoming saturated.

It appears to be necessary to erase NVRAM and reconfigure for this issue, or the limiter doesn't work properly. Try it first if you like, but be warned!

Feedback welcomed, let us know how it works for you!

I just put the scripts there as an example, disabled by default I hope. Also enabled UPnP and NAT-PMP because experienced users will turn it off if they don't want it, inexperienced users will not turn it on and get no ports opening.

The FTP - don't know what is wrong there. Explain what is wrong exactly, FTP from the router? If so, mine is running fine here, I see many many people downloading from the server, so it's strange. I'll look at changes to 7440 and see if I can spot anything, but may have to wait until the next Teddy Bear release.

Ah, thinking - maybe you need to change the NAT Loopback setting in Advanced - firewall to ALL, check if it's set to Forwarded Only. This has changed since some of the ipv6 support was added. Probably not that though.

I also find that I need to set a port forward to the ftp server on port 21 to the router's LAN IP address. Others say it isn't necessary, but I find it so.

Just a few cosmetics, nothing to get excited about - but since I compiled it for myself, it's there. There's also a newer version 7450 since Fedor has made some new upgrades to the source code. I stress that there's no particular need to keep reflashing, if anything particularly juicy comes out, I'll point it out. The best way to see what has changed is to look at the commits at http://repo.or.cz/w/tomato.git/shortlog/refs/heads/tomato-1.28-Toastman-RT

A few people have asked if I am going to drop the feature to change clock frequency from the GUI. No, I will keep it, those that want to use it can, and those that don't needn't. The choice is up to the user :smile:

I'm sorry, that was completely my fault! I seem to have accidentally upgraded the router with latest STD version - no USB/FTP support

The web server has also been offline because I'm using the PC in Linux a lot, messing around with Tomato.

It is now possible to enter two names in the box separated by a space. Hence the space can't be part of a hostname.

I don't consider these releases to be worthy of inclusion in the wikis, there's very little originality here, it's just a release of what I find useful, what people request, and with some carefully chosen names for the QOS classes. I don't have time to be updating it, but if anyone wants to include it, feel free.... a mention and a link is sufficient :biggrin:

The big problem with wikis is that they are never kept up to date and are full of glaring inaccuracies. We don't have the time to keep visiting and updating stuff which we never put there in the first place, often don't know about, and in the end the wiki does a lot of harm rather than fulfill it's original purpose. The tomato wikis are mostly long out of date and full of rather misleading information.

EDIT: I am posting builds using various code by several developers., we are working together on bandwidth limiters and QOS ingress (and having great fun and learning a lot!) - at first these developments may only be in my releases but hopefully others will also adopt them later.

Password save seemed to work for me now, I changed it and saved (I think I did, anyway - I don't use BT). Problems due to different web browsers has been fixed - and new build posted v7453.

I won't be including BT in future versions. It makes the router slow and unstable, as a torrent client it's too slow and as far as my usage is concerned, almost completely useless. My opinion is that it doesn't belong on a router which doesn't have enough resources to do it justice.

NB - Files with OCN in the version=Original Class Names, and BT = Bit Torrent.

RT-N16 may get second SSID one day but it isn't a priority, one day it will just appear, like everything else, LOL!

Curious!

I am moving the ftp server to another site, please be patient!

Okay, done it. DDNS seems to be working more reliably now :halo:

I screwed up the "about" page in last compile, not too bothered about fixing it though, press on to the next one!

Just a note to people about the IP-Range limiter. It is what it says. All IP's entered into the range box will share the assigned bandwidth. If you want to give an individual IP a fixed amount, he must be entered as a single IP or MAC.

bkmo and others, don't despair if you keep changing from one firmware to another just to try, and the prospect of entering all of your config from scratch seems daunting. The method described here is very easy:

http://www.linksysinfo.org/forums/sh...&postcount=221

I just use the Tools/System command box to list the contents of NVRAM in this special format, and cut and paste it either directly into another router's system box or into a text file. You can copy your QOS rules etc. in seconds like this! After you've cherry picked the important bits out, don't forget to "nvram commit".

**** VERY IMPORTANT***

Many people will find they can regain a lot of NVRAM space by doing this occasionally to flush their NVRAM of dross.
.

bkmo - I expect Shibby has read this, thanks for the feedback.

New version coming up, 7454, most bugs with IP Range Limit have been fixed.

Kcolyhs, Look at the tomatoUSB and RT threads, and on the tomatoUSB site for information on the WRT160n V3. This version is based on that one.

Thanks for the feedback on 7454. Not sure what that is due to, hopefully it will be resolved later.

Soon - a new version 7455 with an improvement to the Static ARP binding based on the idea from Victek's RAF and coded by Phykris.

Static ARP binding is implemented on most enterprise-level routers as a security feature, and is generally considered to be an essential and standard feature of such routers. In a condominium it should cure the problems we often experience caused by a resident allocating himself various IP's (including those already issued to someone else) in order to gain access to the network (such as genuine users being locked out). In a small business environment, these problems become even more serious.

What is Static ARP or ARP Binding, and how is it used?

STATIC ARP BINDING

by "Phykris"

On Ethernet (either wired or wireless) all communication between devices goes via physical layer data packets that contain the physical address of the source of the message and the physical address of the destination of the packet. We call this physical address MAC address.

Besides MAC addresses devices also have IP addresses. These are higher level addresses. The source and destination IP address off data sent on the network in put the header IP packets. The IP packets of the devices on a LAN are encapsulated in the physical layer packets.

When the router wants to send data to a client with a certain IP-address (either obtained via DHCP or set manually as a static IP address) the router needs to know what the MAC address of that client is. Therefore the router send an ARP request on the LAN, which is a broadcast. The ARP request basically asks all devices that are on the network "if you're the one with IP address 'X', could you tell you tell me what your MAC address is?". One client should reply: "Yes I have IP address 'X' and my MAC address is 'Y', please send your data to this MAC address".

Now the router knows how to fill in header of the physical layer packet and it can start sending data to the client.

ARP spoofing.

Suppose there's somebody with bad intention on the network that want to intercept data of client with MAC address X and IP address Y. This malicious client could give himself the same static IP address Y, his MAC address is Z. When the router would ask "Are you the one with IP address Y", this malicious client would reply : "yes, I am the one, please send your data to MAC address Z". So, data that was meant to go to MAC address X will go to the wrong client with MAC address Z.

Static ARP binding.

Static ARP binding is a way to ignore ARP spoofing attempts. On the router static DHCP page you can enable Static ARP binding. When enabled the router will ignore all ARP replies. The router will instead look in the static DHCP tables for finding out the MAC address that belongs to a certain IP address. Because this table is filled in by the administrator it is assumed to be correct and data will always be sent to the listed MAC address.

Limiting unlisted devices.

Clients that that have assigned themselves a static IP address which in not in the DHCP table normally can get Internet access if they fill in the router IP address for the gateway and router IP address for the DNS-server (when their MAC address is not restricted from entering the network).

When they try to get Internet access they will send an ARP request to the gateway and the router will reply "yes, I have this gateway IP address, my MAC address is Q". The data can now be sent to the router (with MAC address Q) and when receiving the data the router manages to fill in the ARP table by inspecting the data. So, the router will know the clients MAC address and IP address and it can sent messages back to the client. In other words: the client will have full Internet access.

But in some networks we want to avoid that unlisted clients can get Internet access. We can do this with static ARP binding. All clients within the same subnet that are not listed will get assigned to MAC address 00:00:00:00:00:00, which is an invalid MAC address. So, all other IP addresses besides those listed will not be able to receive any data. Moreover, the IP that are listed will not be vulnerable to ARP spoofing.

Is this useful?

This might be useful for distributing Internet services in a network where you can not trust every client, for instance if you offer Internet access in a condominium.

When using checking "limit unlisted machines" option all unknown IP addresses will be banned from the network and it will not be possible for a malicious client to hijack the IP address of another (paying) user.

Also, there's no need anymore to fill in MAC addresses in the access restriction page. All administration for the network/condominium can be done in a single page.

How should I use this?

This new feature which will be added to some versions of Tomato needs a little explanation.

1) The DHCP service with a dynamic range tends to overwrite the static ARP entries in the table. Therefore you should set the DHCP range to issue only one static IP addresses in the static DHCP table (preferably the administrators IP address). e.g. 192.168.1.100-100

2) You MUST enter your (admin) IP address and MAC in the table, or you may be locked out of the router.

2) Static ARP only supports one MAC address per IP address.

3) If you have access points connected to the LAN ports of your router and you use "limit unlisted machines", you should add their IP and MAC address to the static DHCP table.

4) All listed machines will now show as "active" in the WOL page, because they are in the ARP table.

|

I'm using this now, and it seems to work well. So I am posting 7455 today - remember it's very much a beta test!

Kcolyhs, thank you for the feedback. I can't imagine why you had a problem with 7454 but I'm glad it's now OK.

The new code to detect the CPU frequency may not be working for the WRT160nV3 I guess. I've mentioned it to Victek. He asks, can you post the output of "cat/proc/cpuinfo" ? Thanks!

Some questions about ARP Binding and how it's done are addressed here:

http://www.linksysinfo.org/forums/showthread.php?t=66529

It's a long time since I did that build, but it worked OK here on my GL's. Did you erase your NVRAM? Can't think of anything else.

Sorry, I have nothing to suggest. Like your first router, all my installations are simple PPPOE ADSL. Maybe someone else has an explanation?

richardtaur - no, I am leaving the BT area to Shibby's branch. That way, it is easier for him to support it. If you want to use his BT branch with Toastman QOS you can use this easy method to add it:

http://www.linksysinfo.org/forums/showpost.php?p=362345&postcount=221

K24 is much more trouble free and faster running on a WRT54GL.

K24 MIPSR1 Toastman Build 7619 + ipv6

Guys,

I just had a crack at a new K24 build 7619 K24 MIPSR1 for older router owners. Sizes down to 3.1MB. The rates display works here on my WRT54GL.

I did a quick test to see how it looks, seems OK but I am not going to worry too much about K24 nowadays. It's a bit difficult to list what is in each version, best to flash them until you find what you need.

Try if you wish, no guarantees given though.

[IPv6 has been withdrawn for K24 builds - it doesn't work - because it was never intended for the smaller K24 builds].

I'm uploading it to this url:

http://www.4shared.com/dir/v1BuINP3/Toastman_Builds.html

Destination port 53 is used for DNS lookups. These connections are very fast and don't take long or pass much information. Therefore you can discriminate against torrents by making the DNS rule only apply to connections with less than say 10k transferred. Anything above that will again drop into class E. You can experiment with that 10k figure if you wish to see if you can find a better setting.

A class is a class. Everything in that class is treated the same. If you were designing your own QOS system you could create sub-classes, but that's a different issue and in any case 10 classes is sufficient.

You will always get *some* P2P bleed into another class, don't worry too much about it, it usually won't ruin the effectiveness of the system taken as a whole. For this reason you will see connections in the wrong class for a short time before they drop into the default class. New connections are continually opening with P2P applications, so most rogue connections last a short time only. When P2P is finished with a section of download it often does not close connections, and also the servers at the other end may continue to try to open connnections to your own uTorrent to try to download parts of your files. However, those ports may have been close by uTorrent, so incoming connections often STOP at the ROUTER and show up as unclassified.

No, that's quite wrong. You are still thinking those labels mean what they say. They don't. Internally, they are 0 to 9 - in that order.

The priorities are "hard coded" in Tomato. HIGHEST is what it says, E has the lowest priority. So all things being equal, those in class "HIGHEST" will be dealt with FIRST. That is the whole point of a QOS system. Since you are using only 6 out of the 10, the ones you aren't using are irrelevant, but the priority still exists in the same order HIGHEST to E (i.e. top to bottom, if your classes have different names).

The NAMES don't mean anything. They are just labels. You can call the classes Pooh Bear down to to Eyore if you like.

The amount of BANDWIDTH you assign to each class is a different issue.

I am playing around with QOS rules, nothing much different except I split them up into more rules. Reason - since we now have a means of identifying what rule was responsible for a classification (see the QOS-Details page), it makes it much easier for people to see what is happening and to tailor rules.

If anyone wants to try this, just cut and paste this into your tools/system command execution box, if you like it, don't forget to save or commit.

nvram set qos_orules="0<<-1<d<53<0<<0:10<0<DNS>0<<-1<d<37<0<<0:10<0<Time>0<<-1<d<123<0<<0:10<0<Network Time (NTP)>0<<-1<d<3455<0<<0:10<0<RSVP>0<<-1<x<9<0<<<0<SCTP, Discard>0<<-1<x<135,2101,2103,2105<0<<<0<RPC (Microsoft)>0<<6<x<23,992<0<<<0<Telnet>0<<-1<d<22<0<<<3<SSH>0<<17<x<3544<0<<<3<Teredo port>0<<6<s<80,8080<0<<<3<Remote Router Access>0<<6<x<3389<0<<<3<Remote Assistance>0<<-1<a<<0<flash<<2<Flash Video,(Youtube)>0<<-1<a<<0<httpvideo<<2<HTTP Video,(Youtube)>0<<-1<a<<0<shoutcast<<2<Shoutcast>0<<-1<s<6970:7170,8554<0<<<2<Quicktime/RealAudio>0<<-1<d<1220,7070<0<<<2<Quicktime/RealAudio>0<<6<x<6005<0<<<2<Camfrog>0<<-1<d<1220,1234,5100,6005,6970<0<<<-1<VLC>0<<-1<x<554,5004,5005<0<<<2<RTP/RTSP>0<<-1<x<1755<0<<<2<MMS (Microsoft)>0<<-1<x<1935<0<<<2<RTMP>0<<-1<d<3478,3479,5060:5063,5070<0<<<1<SIP, Sipgate Stun Services>0<<-1<d<1718:1720<0<<<1<H323>0<<-1<a<<0<skypetoskype<<1<Skype>0<<-1<a<<0<skypeout<<1<Skypeout>0<<-1<d<80<0<<0:512<4<HTTP>0<<-1<d<443<0<<0:512<4<HTTPS>0<<6<d<8080<0<<0:512<4< HTTP Proxy / Alternate>0<<-1<d<25,587,465<0<<<5<SMTP, Submission>0<<-1<d<110,995<0<<<5<POP3 Mail>0<<-1<d<119,563<0<<<5<NNTP>0<<-1<d<143,220,585,993<0<<<5<IMAP Mail>0<<-1<a<<0<irc<<6<IRC>0<<-1<d<1493,1502:1503,1542,1863,1963,3389,5061,5190:5193,7001<0<<<6<Windows Live>0<<-1<d<1071:1074,1455,1638,1644,5000:5010,5050,5100,5101,5150,8000:8002<0<<<6<Yahoo Messenger>0<<-1<d<194,1720,1730:1732,6660:6669,22555<0<<<6<MSG R 2 - Chat Services>0<<-1<d<5000:5010,5050,5220:5223,5298,8000:8002<0<<<6<MSGR3 - Chat Services>0<<6<d<20,21,989,990<0<<<7<FTP>0<<-1<x<6571,6891:6901<0<<<7<WLM File/Webcam>0<<6<d<80,443,8080<0<<512:<7<HTTP,SSL File Transfers>0<<17<x<1:65535<0<<<-1<P2P (uTP, UDP)"

nvram set qos_orates="5-20,5-20,5-25,5-70,20-100,20-80,10-80,20-80,10-50,0-0"

nvram set qos_irates="10,20,40,70,0,70,70,70,60,1"

Last changed 6/5/2011

This is just a first attempt at tidying up the rules, it isn't quite finished and no doubt some of them will be amended in due course.

VOIP users may find an extra L7 filter for SIP will make their lives better!

These rules are the same as the old ones, more or less, but expanded into more rules. When you've done this, change to the QOS configuration page and you'll see the rules. If you are happy with them, click SAVE.

Backup your old settings first in the usual way, for safety, and then try the method outlined above and here:

http://www.linksysinfo.org/forums/showpost.php?p=362345&postcount=221

The system command box is very useful. Instead of messing about, it's much easier to just cut and paste from this box. For example, to clean up a router's config, open a browser and list all settings with export command. Then open another browser to the router, erase NVRAM, then cut and paste the appropriate lines from the other window.