Good I see we have a minor error with overbooking... let's see where that comes from, it seems to be something related to the overhead calculation. let's change it like this
interface pppoe-wan wanin input rate 15500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
class group prio rate 14000kbit ceil 14000kbit
class video rate 70%
match dscp AF41
class other rate 30%
match dscp AF21
class group end
class default ceil 1000kbit
interface pppoe-wan wanout output rate 5500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
In order to prioritize league of legends you should use a firewall rule to set DSCP 48 for udp packets with ports 5000:5500 as detailed somewhere above. Also you need to set DSCP for other packets again in the firewall PREROUTING mangle table
Already in this config "default" has lowest priority, so that will be where your everyday web browsing outside FB and Google will be classified, so already that is taken into account.
If you like to you can set even a further lowest priority class in input for torrents
class torrents
match dport <your_torrent_client_port_goes_here>
put that below the "class default" in the input definition, leaving you with:
interface pppoe-wan wanin input rate 15500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
class group prio rate 14000kbit ceil 14000kbit
class video rate 70%
match dscp AF41
class other rate 30%
match dscp AF21
class group end
class default ceil 1000kbit
class torrent
match dports 6881:6889 ### note this is a default range, please insert the range used by your actual torrent client
interface pppoe-wan wanout output rate 5500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
Out of curiosity, where are you and which WISP is it that does all this prioritization? It seems like an odd thing to do to be willing to let people use a lot of bandwidth from google or facebook whereas not so much for everyday things outside those little isolated towers, unless of course they are getting paid by FB and Google. Or maybe FB and Google have given them a special unmetered connection to their networks.
i live in iraq there's 2 main isp "iq netwroks and scopesky" ,they provide sub isp's here
most of sub isp's prefer iq-net for there good ping and they provide free google traffic"ggc" unlike scopesky.
here they want money so from begging they provide youtube and facebook,iptv,local netwrok games to keep people away from downloading stuff's from Internet to keep there low end networks on low load,yes FB and Google have given them a special unmetered connection to their networks>they use fna for facebook and "ggc" for google and introduce a big caching servers,also the main isp's are not using a fiber connection all the way from turkey to south of iraq they mix with wireless microwave devices.so they call it the download an international and really cost us so much money now iam paying 30$ for 1 Mbps down and 6 Mbps or less for up,there's another sub isp's that provide more than those speed with same price,but you can't find there coverage every where.connections here are all unmetered.
Thanks for the explanation. I'm glad to be able to help.
So, tell me does it now run without any errors or complaints regarding overbooking etc? Your last result was almost perfect, except for the overbooking caused by the overhead calculation.
And, are you able to DSCP tag in the PREROUTING table so that your traffic is classified? Without doing the DSCP tagging you will get no effect. Do you understand what this means and how to accomplish it by altering firewall rules?
And, if all of that is in place, are you able to see some useful result? Do some tests I would like to hear if it works for you.
EDIT: yes I realize it is probably late there where you are, so I will look for your reply tomorrow.
I see what's going on now, there's a 'default' class in the class group that gets a little bandwidth, and it causes the overbooking. change:
interface pppoe-wan wanin input rate 15500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
class group prio rate 14000kbit ceil 14000kbit
match dscp AF41
match dscp AF21
class video rate 69%
match dscp AF41
class other rate 29%
match dscp AF21
class group end
class default ceil 1000kbit
class torrent
match dports 6881:6889 ### note this is a default range, please insert the range used by your actual torrent client
interface pppoe-wan wanout output rate 5500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
I think that should handle the error. As for marking with DSCP we can use firehol to do this without interfering with standard LEDE firewall. Let me look up some more info on that
Yes, marking DSCP packets using ipsets and the LEDE firewall is fine, but you need to know how to input those firewall rules to the LEDE firewall. I am less familiar with how to do that as I use firehol for my firewalls.
similarly to mark the google video ipset for inbound packets with DSCP class AF41 something like
iptables -t mangle -A PREROUTING -m set --match-set googlevideoset src -j DSCP --set-dscp-class AF41
hopefully those kinds of commands, together with a little googling could get you a functional setup that optimizes things in the appropriate way.
EDIT: note also that the fireqos config file accepts bash shell script commands (I believe), so you could just put those iptables commands at the top of the fireqos.conf file and have all your QoS config in one place.
Glad that your default is already improving your connection. this is exclusively due to the fq_codel on the default queue, unless by some chance the LoL packets are already DSCP tagged
it makes me think that the PREROUTING chain will not see the packet until after it's gone through the IFB... so it won't work for input to mark with DSCP as the DSCP mark won't be there until after the IFB processes the packet.
So, the solution to this is to do your traffic shaping on an intermediate virtual ethernet pair.
ip link add type veth
Then you create policy routes, traffic coming from your internal network gets routed via outqos policy table which sends default traffic to veth1... traffic coming from the internet gets routed via inqos table to veth0. Conceptually the diagram is like this
inbound:
INTERNET -----> pppoe-wan ----> veth0 -------> veth1 ------> LAN
outbound just looks the same with arrows going the other way.
then we do our qos on output of veth0 and veth1, output of veth0 handles our "inbound" traffic being sent from veth0 to veth1 towards our LAN, output of veth1 handles our "outbound" traffic sent from lan to internet.
Let me look into how to handle this. I think we can set it up in the fireqos.conf file via some ip commands.
ok, let's create a table 100 for routing stuff from the internet towards LAN. Let's suppose you're using 192.168.1.0/24 for your LAN.
I think it should be possible to add these commands to the top of fireqos.conf as that file accepts regular bash commands. So your fireqos.conf file can look like this: (please be prepared to use recovery mode if this breaks your routing and you can't talk to the router, I do not have a testing device to test it on) https://lede-project.org/docs/user-guide/failsafe_and_factory_reset
load that page on your computer for reference and read it to understand how to recover before trying this.
## set up a pair of veth devices to handle inbound and outbound traffic
ip link add type veth
ip link set veth0 up
ip link set veth1 up
ip link set veth1 master br-lan ## place the veth1 into br-lan bridge
ip table add 100
ip route add 192.168.1.0/24 via veth0 table 100 ## traffic to LAN goes by default to veth0 where it comes out veth1 into the br-lan bridge
ip rule add not from 192.168.1.0/24 table 100 ## traffic from the internet uses routing table 100
## set up some mangle tables... this is an example,
iptables -t mangle -A PREROUTING -i pppoe-wan -j DSCP --set-dscp 0
iptables -t mangle -A PREROUTING -p udp --source-ports 5000:5500 -j DSCP --set-dscp 48
iptables -t mangle -A PREROUTING -p udp --destination-ports 5000:5500 -j DSCP --set-dscp 48
iptables -t mangle -A PREROUTING -m set --match-set googlevideoset src -j DSCP --set-dscp-class AF41
## etc... you need to mark similarly for google or facebook non-video traffic etc
## we send inbound packets from the internet through veth0 towards the br-lan bridge so this
## handles our inbound bandwidth, as output on a virtual ethernet device
interface veth0 output rate 15500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
class group prio rate 14000kbit ceil 14000kbit
match dscp AF41
match dscp AF21
class video rate 69%
match dscp AF41
class other rate 29%
match dscp AF21
class group end
class default ceil 1000kbit
class torrent
match dports 6881:6889 ### note this is a default range, please insert the range used by your actual torrent client
## traffic from the LAN gets sent via pppoe-wan so this handles our outbound traffic
interface pppoe-wan wanout output rate 5500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
Now, the packet doesn't hit veth0 or veth1 until AFTER the mangle prerouting table has done its work of marking the dscp. Then the traffic is shaped over the virtual ethernet pair, and then sent out the wired or wifi portions of the bridge to your computers.
If you have trouble. go into recovery mode and disable fireqos by moving fireqos.conf to fireqos-test.conf and reboot.
EDIT: earlier version of script had some routing problems. I think this is simpler, easier, and correct.
hi, thanks i appreciate your help
but i think you made a little mistake here "interface veth0 output rate 15500kbit qdisc fq_codel overhead 8" it's should be input not output.
i don't have have any problem about recovery mode,i can use it when needed.
about dscp 48 you didn't added any code to the qos classes.
what is the use of dscp CS6.
i forget to say that "udp/5000:5500 tcp/8393:8400,2099,5223,5222,8088" are "LOL" ports. not onlt 5000:5500
Edit:
the new config is not working:
FireQOS 3.1.5
(C) 2013-2014 Costa Tsaousis, GPL
RTNETLINK answers: Not supported
Cannot find device "veth0"
Cannot find device "veth1"
Cannot find device "veth1"
Object "table" is unknown, try "ip help".
Error: inet address is expected rather than "veth0".
iptables v1.6.1: unknown option "--source-ports"
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.6.1: unknown option "--destination-ports"
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.6.1: Set googlevideoset doesn't exist.
Try `iptables -h' or 'iptables --help' for more information.
: interface veth0 output rate 15500kbit qdisc fq_codel overhead 8
ERROR: 22@/etc/firehol/fireqos.conf: interface:
Cannot understand what '15500kbit' means.
FAILED TO ACTIVATE TRAFFIC CONTROL.
Clearing failed interface: output (veth0 rate => veth0)...
veth0: cleared traffic control rate
No traffic control is operational by FireQOS.
bye...
"--source-ports" should be "-sports" and "--destination-ports" should be "-dports".
Actually it should be output. the output of veth0 goes over a "virtual" patch cable to veth1 where it enters the LAN bridge. This is an alternative way to shape the input which doesn't rely on the IFB method. Shaping only works on the output of devices, so we create a virtual device whose output we can control and then route the incoming packets through it.
dscp 48 is the numerical value for the CS6 class, so they are the same
you may not need to prioritize all of those LoL ports, the udp ones are the ones that actually send the time-sensitive in-game information. Nevertheless you can feel free to play with prioritizing more or less ...
You must install kmod-veth to get rid of the error "RTNETLINK answers: Not supported"
also delete the command "ip table add 100" that is not a real command. the table gets added automatically when you add rules to it, I guess.
To get rid of this error, you need to replace "googlevideoset" with the name of the ipset you are using for google video traffic. also you should add similar commands for the other ipsets you are using.
To fix this you need "interface veth0 lanin output ...."
fireqos wants a "descriptive name" for each interface after its kernel name...
my config :
.
## set up a pair of veth devices to handle inbound and outbound traffic
ip link add type veth
ip link set veth0 up
ip link set veth1 up
ip link set veth1 master br-lan ## place the veth1 into br-lan bridge
ip table add 100
ip route add 192.168.1.0/24 via veth0 table 100 ## traffic to LAN goes by default to veth0 where it comes out veth1 into the br-lan bridge
ip rule add not from 192.168.1.0/24 table 100 ## traffic from the internet uses routing table 100
## set up some mangle tables... this is an example,
iptables -t mangle -A PREROUTING -i pppoe-wan -j DSCP --set-dscp 0
iptables -t mangle -A PREROUTING -p udp --sport 5000:5500 -j DSCP --set-dscp 48
iptables -t mangle -A PREROUTING -p udp --dport 5000:5500 -j DSCP --set-dscp 48
iptables -t mangle -A PREROUTING -m set --match-set gvideostream4 src -j DSCP --set-dscp-class AF41
## etc... you need to mark similarly for google or facebook non-video traffic etc
## we send inbound packets from the internet through veth0 towards the br-lan bridge so this
## handles our inbound bandwidth, as output on a virtual ethernet device
interface veth0 lanin output rate 15500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
class group prio rate 14000kbit ceil 14000kbit
match dscp AF41
match dscp AF21
class video rate 69%
match dscp AF41
class other rate 29%
match dscp AF21
class group end
class default ceil 1000kbit
class torrent
match dports 6881:6889 ### note this is a default range, please insert the range used by your actual torrent client
## traffic from the LAN gets sent via pppoe-wan so this handles our outbound traffic
interface pppoe-wan wanout output rate 5500kbit qdisc fq_codel overhead 8
class highprio rate 300kbit ceil 500kbit
match dscp CS6
this is output error:
FireQOS 3.1.5
(C) 2013-2014 Costa Tsaousis, GPL
Object "table" is unknown, try "ip help".
Error: inet address is expected rather than "veth0".
: interface veth0 lanin output rate 15500kbit qdisc fq_codel overhead 8 (veth0, 15500kbit, mtu 1500, quantum 1500, minrate 155kbit)
: class highprio rate 300kbit ceil 500kbit (1:11, 300/500kbit, prio 0)
: class prio rate 14000kbit ceil 14000kbit (1:12, 14000/14000kbit, prio 1)
: class video rate 69% (1:13, 9660/14000kbit, prio 0)
: class other rate 29% (1:14, 4060/14000kbit, prio 1)
: class default (1:8001, 155/14000kbit, prio 2)
: committed rate 13875kbit (99%), the remaining 125kbit will be spare bandwidth.
: class default ceil 1000kbit (1:8000, 155/1000kbit, prio 2)
: class torrent (1:17, 155/15500kbit, prio 3)
: committed rate 14610kbit (94%), the remaining 890kbit will be spare bandwidth.
: interface pppoe-wan wanout output rate 5500kbit qdisc fq_codel overhead 8 (pppoe-wan, 5500kbit, mtu 1480, quantum 1480, minrate 55kbit)
: class highprio rate 300kbit ceil 500kbit (1:11, 300/500kbit, prio 0)
: class default (1:8000, 55/5500kbit, prio 1)
: committed rate 355kbit (6%), the remaining 5145kbit will be spare bandwidth.
Traffic is classified:
- on 2 interfaces
- to 10 classes
- by 8 FireQOS matches
34 TC commands executed
All Done! Enjoy...
bye...
when i run command "ip table add 100" i get this error "Object "table" is unknown, try "ip help" "
this rule have error "ip route add 192.168.1.0/24 via veth0 table 100" > "Error: inet address is expected rather than "veth0"" but second rule is ok.
Yes, just delete the line near the top " ip table add 100" that's not a real command, I was mistaken in including it, the routing table gets created automatically when you add rules to it.
However, it shouldn't change the fact that other than that one error everything seems to be working.... so is your router actually working with this config? traffic flows here and there without problems (I'm concerned that I may have done something wrong in the routing over the veth devices and cut off something with your connection )
Assuming it is working, note some tasks for you to do:
If you re-load this, it will create more and more and more veth interfaces. you could fix that by checking to see if veth0 and veth1 already exist before creating a new one.
You need to set up your ipsets for google video, google other stuff, facebook stuff, skype, and anything else you need. then add the appropriate iptables mangle rules near the ones already set up in this config to set DSCP values for each set.
Check to see that it actually classifies things via DSCP appropriately. I have trouble running "fireqos status lanin" on LEDE because something about the sleep command on LEDE doesn't work in the way fireqos wants. But it does give you some useful information, it just doesn't pause for 1 second between lines. But it will tell you if things are being classified. Also you can look in "tc -s qdisc show" to see the statistics about how much each queue has sent, this would show you that things are or are not going through the high priority queues you set up (but the output is .... not that easy to read)
Consider how you would like to shape your outgoing traffic on pppoe-wan. Perhaps you want to have other classes other than just "highprio" and the "default" that gets added automatically.
investigate whether you should change your overhead setting on output. Maybe your MTU being smaller means your overhead should be larger... 20 or 30 bytes or so?
Other than that, I hope you enjoy your new shaped traffic system. You can test it by doing things like downloading some large file from google drive while playing your LoL game or skyping or whatever.
thanks
i deleted that line.
for googlevideo ipsets it's ready i should add facebook and other stuff's.
this is google video list :
ipset list
Name: gvideostream4
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 220
References: 4
Members:
5.10.226.13
5.10.226.12
172.217.23.238
5.10.226.14
yeah my router is working and i can surf anything normally,except for veth:
i have a 13 veth start from veth0 to veth13
50% done.
3.when i run "iptables -L -v -n -t mangle" i see:
iptables -L -v -n -t mangle
Chain PREROUTING (policy ACCEPT 494K packets, 202M bytes)
pkts bytes target prot opt in out source destination
261K 183M DSCP all -- pppoe-wan * 0.0.0.0/0 0.0.0.0/0 DSCP set 0x00
106 43674 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set gvideostream4 src DSCP set 0x22
252K 178M DSCP all -- pppoe-wan * 0.0.0.0/0 0.0.0.0/0 DSCP set 0x00
106 43674 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set gvideostream4 src DSCP set 0x22
248K 176M DSCP all -- pppoe-wan * 0.0.0.0/0 0.0.0.0/0 DSCP set 0x00
106 43674 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set gvideostream4 src DSCP set 0x22
245K 174M DSCP all -- pppoe-wan * 0.0.0.0/0 0.0.0.0/0 DSCP set 0x00
97 9110 DSCP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:5000:5500 DSCP set 0x30
116 11383 DSCP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5000:5500 DSCP set 0x30
106 43674 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set gvideostream4 src DSCP set 0x22
Chain INPUT (policy ACCEPT 10536 packets, 1056K bytes)
pkts bytes target prot opt in out source destination
66412 7416K RRDIPT_INPUT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 483K packets, 201M bytes)
pkts bytes target prot opt in out source destination
3213K 1486M RRDIPT_FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 11558 packets, 2867K bytes)
pkts bytes target prot opt in out source destination
76679 18M RRDIPT_OUTPUT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 495K packets, 204M bytes)
pkts bytes target prot opt in out source destination
Chain RRDIPT_FORWARD (1 references)
pkts bytes target prot opt in out source destination
Chain RRDIPT_INPUT (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- eth0 * 0.0.0.0/0 0.0.0.0/0
578 75722 RETURN all -- eth0.4 * 0.0.0.0/0 0.0.0.0/0
Chain RRDIPT_OUTPUT (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all -- * eth0.4 0.0.0.0/0 0.0.0.0/0
4.can you suggest anything good.
5.my mtu is 1480 i think 18 or 28 overhead is good.
i will test and tell you,you deserve a very big thanks,for your great help,i will try to maintain things and let you know what i need more.
)