see http://forum.pfsense.org/index.php/topic,1686.msg9789.html#msg9789 for a list of
network interfaces  that support altq

Try the default low priority flag first. If this doesn't work set some provider like "asterisk". This will setup rules based on ports. After the wizard went through edit the voip rules it created and alter the ports to what your phones/voipserver uses.

We fixed a condition with 1.0-RELEASE where under certain circumstances rules were not applied after hitting apply. You should upgrade to the release version.

@ssjoco:

I have the same problem. I used the Traffic Shaping wizard. (WEB, P2P….). However the ACK, Default and the P2P queues are working, but the oters don't. I made some modification, but the result is same.
I have 2 interface, WLAN, and LAN. WLAN bridged with LAN.

I have the same problem. My queue for outgoing ftp packets don't work.
RC3, 1WAN, 1LAN, 2 OPT

@sullrich:

FAQ.

Shaping does not work with bridging currently.

That I knew but I thought that only implied on shaping between interfaces in the bridge. NVM thanks for clear answer and hope u will get it working cos this is really some nice piece of software. :D

Run the Shaperwizard and see what rules it creates to understand how it works. It has lots of options that might make custom rule creation unnecessary.

The rulesfile that includes altq is regenerated on every rule change in the webgui or on IP-change at wan or at bootup or…unless you want to implement this in a clean way (meaning adding this functionality to the webgui which means quite some work) it's not possible atm.

google for making freebsd kernel

This seems to be working but you have to do a lot of the config tweaking (ie manually adding queues and rules) yourself, I'll post a trip report after I get my 2nd pfSense box up at home…

I haven't actually tested shaping on WAN-LAN on the current box, only WAN-OPT1 (which had me confused for a minute, surely I should be getting better speedtests than 3mbit when I had a 100mbit connection all the way from the ppp client, through pfSense- which was shaping just like it should be, to the internet)

Put a max bandwidth on the p2p queues so your roomates can't max out the line.  That'll leave extra room for you to play your games.  Also, put a realtime bandwidth on the gaming queue, that should help give you a little more guarantee.

The acks queues are used by the rule generation system automagically.

–Bill

You shouldn't use sourceports at the clientside, they are most likely random.

That is my understanding, yes.

Thanks sullrich, I did read that and I'm not getting drops on my queues.

Appologies for not responding sooner, I was locked out of the forum for a while because it was rejecting connections from behind proxies.

Does around 20-30pps for acks seem reasonable? That's with an 11kB upload speed, getting about 280kB down. 7kB/sec worth of acks. Seems about right, on an MTU of 1500. It never seems to get above 50pps, with an unlimited upload.

PS. I think this could be something to do with NTL, but I'm not sure what.

NTL gives you a 512kb upload, which I can max out uploading to NTL web space or Flickr. However, anything over 11kB seriously kills download speeds. That simply shouldn't happen. Does anyone have any ideas what could cause it? It's via a cable modem, so the overhead should be quite low compared with, say, ppoe. Yet, the exact same software on the same routers and PCs allowed me to upload at 40kB/sec on 480kb up ADSL without loss of download performance.

@jan:

my pfsense is acting a little strange, so i downloaded and installed a new pfsense iso, then i went on to configure traffic shaping but after finishing the wizard i could no longer surf, the traffic shaping does not need any rebooting, right? good thing i have a config back up w/o traffic shaping and restored it, and after a reboot, i can surf the internet again. there is definitely something wrong with my box, right?

Yep, sounds like you've got a broken clock.  Not much we can do about that I think.

–Bill

Hi sullrich and hoba,

Thanks  for your replies :)
I finally figured out what was happening.
First of all, I did a factory default, and then proceeded to run the Shaping Wizard once again.
After that, I noticed exactly the same problem, and I decided to do a tcpdump -vvv host MyTargetHost to get more info, and there I saw the problem!
My downstream was ToS=0x18 and my upstream was ToS=0x10  :o
However, I believe there's a bug in the matching rules, because look what happens below.

For example, this works fine:

lowdelay    yes    no      don't care
throughput yes    no    don't care
reliability   yes    no    don't care
congestion yes    no    don't care

But this, or any other combination that includes more than one tos value, will  bomb:

lowdelay    yes    no    don't care
throughput yes    no    don't care
reliability   yes    no    don't care
congestion yes    no    don't care

PF will complain as to the syntax and skip the rule of the offending line when trying to add tos=lowdelay,throughput, etc., on the same line.

So I just fixed the ToS on my Asterisk box to tos=0x18, selected lowdelay yes - on the "IP Type of Service (TOS)", and bingo!, upstream/downstream are now showing a nice red line while any phone is in use ;)

BUT, the question still is, shouldn't 0x10 match? Because it doesn't!  ???
Isn't 0x10 = lowdelay? or do I have it all wrong?

Thanks,
-Karl

Make sure RDP shows up in the qotherXXh queues. Then give that queue a higher percentage as well just like you did for the ack queues.

@hshh:

I am about to set SYN packet high priority,detail is in TCP Flags, SYN set, ACK cleared, others don't care.
After apply settings, I found the rules added by webui is,
pass in on rl0 proto tcp all flags S/FSRPAU keep state tag qLANacks tagged unshaped
pass out on vr0 proto tcp all flags S/FSRPAU keep state tag qWANacks tagged qLANacks

S/FSRPAU, why not S/SA ? Is it a bug?

flags <a>/ | / This rule only applies to TCP packets that have the flags</a> ****<a>set
          out of set **.  Flags not specified in **are ignored.  The flags
          are: (F)IN, (S)YN, (R)ST, (P)USH, (A)CK, (U)RG, (E)CE, and C(W)R.

flags S/S  Flag SYN is set.  The other flags are ignored.

flags S/SA  Out of SYN and ACK, exactly SYN may be set.  SYN,
                      SYN+PSH and SYN+RST match, but SYN+ACK, ACK and ACK+RST
                      do not.  This is more restrictive than the previous ex-
                      ample.

flags /SFRA
                      If the first set is not specified, it defaults to none.
                      All of SYN, FIN, RST and ACK must be unset.</a>

<a>–Bill</a>

Multiple Interface trafficshaping is not supported out of the box atm. Also a per user bandwidth sharing or a fairly sharing per active user is not yet possible in pfSense (and won't be for 1.0). Nobody can say if this will be possible in future versions at the current state.

BTW, priority doesn't really mean much in the shaper anyway.

–Bill