My Shaper Config File For All To See! Works great with VoIP!
-
psychosematic
In the example you cited above, any traffic that matches port 80 at the source OR destination headers will be given a certain priority. Only traffic (given that you haven't designated a different port than the default) that has anything to do with web browsing will have port 80 associated with it whether its the source or destination. The rules don't fight with each other because the first rule that a packet matches is used to prioritize it.
Billm can only incorporate this into the wizard in a very generic way that might not make much sense to someone new to traffic-shaping. Also, I use port 32172 for bittorrent and you use 49152. The only way to make it work is to adapt it to what you use.
The more I've learned about this by studying the the connection state table, I've even started to add additional rules that cover the default ports for bittorrent and emule. My bittorrent client makes about 40%-50% of its connections on port 32172 (source OR destination but not both for the same connection). About another 30% of its connections are in the range of 6870-6999 because clients on the other end are using that port, the default range for bittorrent. However, my client is not using 32172 for those connections, it's using something random. The rest of the connections just seem to be random at both the source and destination port (although I'm sure the majority are just the port other people have chosen).
The reason I have a total of four rules for each port or range of ports for a is because just figuring out traffic-shaping fries my brain and I don't have anything left over for figuring out if my browser is only using port 80 as the source for all outging traffic or such. So, this way, I make sure that all traffic that has to do with web browsing get treated the same, because it will have port 80 show up somewhere in the packet and it will receive the right priority whether it's coming or going. One other thing to keep in mind is bittorrent uses UDP also so I use 4 more rules for that. pfSense will have errors if the "any" setting for the protocol is used.
I also understand that maybe this approach might cause huge queues in DSL modems on the download side. My modem is set up as a bridge so I don't have this problem since it does no packet handling of any kind.
Even if some of my shaping rules are unnecesary (and I'm willing to admit that some may very well be), I have not noticed any speed drops. AFAIK performance only drops when the number of connections are more than the cpu can handle. But, Sullrich and hoba would know more about that.
-
psychosematic
In the example you cited above, any traffic that matches port 80 at the source OR destination headers will be given a certain priority. Only traffic (given that you haven't designated a different port than the default) that has anything to do with web browsing will have port 80 associated with it whether its the source or destination. The rules don't fight with each other because the first rule that a packet matches is used to prioritize it.
Billm can only incorporate this into the wizard in a very generic way that might not make much sense to someone new to traffic-shaping. Also, I use port 32172 for bittorrent and you use 49152. The only way to make it work is to adapt it to what you use.
The more I've learned about this by studying the the connection state table, I've even started to add additional rules that cover the default ports for bittorrent and emule. My bittorrent client makes about 40%-50% of its connections on port 32172 (source OR destination but not both for the same connection). About another 30% of its connections are in the range of 6870-6999 because clients on the other end are using that port, the default range for bittorrent. However, my client is not using 32172 for those connections, it's using something random. The rest of the connections just seem to be random at both the source and destination port (although I'm sure the majority are just the port other people have chosen).
The reason I have a total of four rules for each port or range of ports for a is because just figuring out traffic-shaping fries my brain and I don't have anything left over for figuring out if my browser is only using port 80 as the source for all outging traffic or such. So, this way, I make sure that all traffic that has to do with web browsing get treated the same, because it will have port 80 show up somewhere in the packet and it will receive the right priority whether it's coming or going. One other thing to keep in mind is bittorrent uses UDP also so I use 4 more rules for that. pfSense will have errors if the "any" setting for the protocol is used.
I also understand that maybe this approach might cause huge queues in DSL modems on the download side. My modem is set up as a bridge so I don't have this problem since it does no packet handling of any kind.
Even if some of my shaping rules are unnecesary (and I'm willing to admit that some may very well be), I have not noticed any speed drops. AFAIK performance only drops when the number of connections are more than the cpu can handle. But, Sullrich and hoba would know more about that.
Thank you for the extensive reply … do you know of any good sources for traffic shaping, so that I can read up more on it?
-
Sorry, I can't help you there except to try to google for it. Everything I know (which is little enough) is from getting my hands dirty.
-
when i use you config file once i reboot i am no longer able to browse websites.
but i can still access the pfsense box via browser.i get a notification scrolling along the top saying
"There were error(s) loading the rules:
/tmp/rules.debug:16: queue qWANRoot has no parent
/tmp/rules.debug:16: errors in queue definition
/tmp/rules.debug:17: queue qWANdef has no parent
/tmp/rules.debug:17: errors in queue definition
/tmp/rules.debug:18: queue qLANRoot has no parent
/tmp/rules.debug:18: errors in queue definition
/tmp/rules.debug:19: queue qLANdef has no parent
/tmp/rules.debug:19: errors in queue definition
/tmp/rules.debug:20: queue qLANacks has no parent
/tmp/rules.debug:20"they can also be found in system log
i have no idea what any of this means (first day using pfsense)
you config sense to work well until you reboot.second quick question
1000 Kb qWANRoot
1500 Kb qLANRoot
are those to the speed your your dsl line up/down?thanks
mentalinc -
when i use you config file once i reboot i am no longer able to browse websites.
but i can still access the pfsense box via browser.i get a notification scrolling along the top saying
"There were error(s) loading the rules:
/tmp/rules.debug:16: queue qWANRoot has no parent
/tmp/rules.debug:16: errors in queue definition
/tmp/rules.debug:17: queue qWANdef has no parent
/tmp/rules.debug:17: errors in queue definition
/tmp/rules.debug:18: queue qLANRoot has no parent
/tmp/rules.debug:18: errors in queue definition
/tmp/rules.debug:19: queue qLANdef has no parent
/tmp/rules.debug:19: errors in queue definition
/tmp/rules.debug:20: queue qLANacks has no parent
/tmp/rules.debug:20"they can also be found in system log
i have no idea what any of this means (first day using pfsense)
you config sense to work well until you reboot.second quick question
1000 Kb qWANRoot
1500 Kb qLANRoot
are those to the speed your your dsl line up/down?thanks
mentalincYou most likely need to rerun the traffic shaping wizard.
-
Thank you for your reply.
but if i run the wizard i will loss the current config (which i downloaded from this thread)
i am also experiencing from the system log
"pftpx[706]: #6 abnormal server error: 65" -
Thank you for your reply.
but if i run the wizard i will loss the current config (which i downloaded from this thread)
i am also experiencing from the system log
"pftpx[706]: #6 abnormal server error: 65"They are no longer compatible.
pftpx issues is cosmetic, will be fixed in beta3.
-
SO there has been a change to the shaper works from what is posted above and beta 2?
-
Yes of course.
-
Do not try to import my original config file into your system. It was only posted so as to help others understand a little bit better how the traffic shaper works and what was working for me at that time. If it is too confusing for you to decipher, then you probably need to learn more about TCP/IP, ports, and protocols.