The construction in the document you follow: If one of your users starts watching some streaming video, he will kill your phone. It is not the same approach for the incoming traffic. This will give you warranted bandwidth for the VoIP and also ability to borrow and tec. Yes this is the same approach like main for the incoming traffic. >trying to get all the pieces working has been challenging … >i'm not yet sure if that's similar, or somehow different than your approach … >content/uploads/2010/04/TrafficShapingUnde “-m limit” it is good only to drive crazy some user you don’t like. set-tos is reliable only if you have control on all routers on the route. “TOS -set-tos” and “-m limit” are two different things and are not queuing disciplines.īooth are very limited. Now it is really confusing as you are introducing third thing actually even forth. >QoS for 'cleanest' VoIP traffic - both inbound and outbound. >multiple servers and VoIP client devices on the lan (no asterisk inside … >my current goal is to craft QoS policy for: >'boot'? do you mean 'both'? i not, then i'm a bit confused. >I see from your rules that you are attempting to do boot. The script may looks slightly wired as this is firewall with two Wireless networks one bridged to the Ethernet adapter. I made a script for my home network – this is the map of itĪnd this is the schemes for income and outgoing traffic What, you should do is to shape incoming traffic too – do not say it is impossible before you read this: I guess you already found the FWbuilder documentation for set-class, but if not it is here Simple construction like next one should do the job:

I see from your rules that you are attempting to do boot. Set-class is better solution for traffic shaping – less kernel overload then u32. With set-mark you have to use u32 to direct the traffic. What is not mentioned there is that there are actually two methods of directing the traffic, set-mark and set-class. Is the 'fix' still 'tentative'? Is there still a need to 'test more'?įirst the quick answer is the instructions that you mention, in firewall builder is correct and it work. I can't manage to follow through FWB's output to figure out if FWB is working the way it's supposed to or not.

Since target CLASSIFY is only allowed in POSTROUTING, this may create conflict. The fix in this change is tentative as it creates branch in chains PREROUTING, POSTROUTING and OUTPUT. When branching rule points to a rule set that has rules with Tag and Classify options, branching should occur in mangle table even when checkbox 'create branch in mangle table' is not checked. 'Tag and classify actions dont work properly with branches'. $IPTABLES -t mangle -A PREROUTING -j CONNMARK -restore-mark None of which looks exactly like what i read further $IPTABLES -t mangle -A FORWARD -j QOSrules $IPTABLES -t mangle -A POSTROUTING -j QOSrules $IPTABLES -t mangle -A PREROUTING -j QOSrules $IPTABLES -t mangle -A QOSrules -j CLASSIFY -set-class 1:40 $IPTABLES -t mangle -A QOSrules -j CONNMARK -save-mark $IPTABLES -t mangle -A QOSrules -j MARK -set-mark qos140 Struggling mightily to get fwb to 'do' adequate VoIP traffic shaping, I've created a rule,Īny:Any:Any:Any:Both:Continue:Any:(options)

Firewall builder classify example