@sullrich: Not at this time.  Patches accepted. Patches accepted (although I know exactly what needs to be done, I backed out the code for this back in June due to other issues) - but be warned the shaper is under heavy development, you will want to coordinate any work you do with me. Or again, donations are accepted - at this point a quiet machine with Intel FXPs would be appreciated.  I can no longer do shaper development on my (silent) Soekris as there's an OS level bug that affects the NICs on this machine. –Bill

cant wait any longer :) so i get the testing snapshot 2-19-06 iso and do clean install. then trying traffic shaping again. still… same error. tnx&rgds, rex

Here is another thing I observed today.. This rule: pass out on  dc0 from any to 192.168.1.7  keep state tagged unshaped tag qHighDownL            (subset of rules posted earlier) dc0 - LAN interface Does not work for traffic originating from the firewall itself. Squid and ssh traffic to 192.168.1.7 for example would fall into the default queue instead of qHighDownL, so does all traffic to any ip whos traffic originated at the firewall. It only works for traffic comming through WAN. Squid is boud to lo 127.0.0.1 while ssh is bound to the any address *. Is there any reason why this rule don't work for such traffic? I though about it and still can figure out why. EDIT: tried iperf from firewall to lan pc with ip address 192.168.1.7 -> the traffic found its way into the correct queue. however the others stated above still don't get queued properly. Could it have have something to do with the direction in which the connections were establish?

Sure, that's what this forum is meant for  ;D

Wow, I don't think you'll be able to do this very easily. That would require a lot of rules…

@Leoandru: Well Its killing my upload shaping see thread: http://forum.pfsense.org/index.php?topic=630.0 I understand that when the packet is nat'd u no longer know where its from.. But doesn't the filter policy sort that out, I mean once the packet comes in on lan its tagged and the filter policy will take care of the queuing. so the any -> any rule wouldn't be needed. when I get time I gonna manually modify /tmp/rules.debug and test that theory. I really need to get upload shaping working by ip addresses. Actually, you may be on to something, I'll have to think about it a little more.  We might not need the "pass out" rules at all as tags are sticky.  Looks like a case of overthinking.  I'll ponder removing that and if it makes sense (and works) this might see an MFC to 1.0. –Bill

Sorry about that :-/  I'm working on something to make this situation a little better and introduce a little more visibility into bandwidth reservations. –Bill

Until all the bugs and issues are resolved in the current code I'm not making any other changes, it's too difficult to troubleshoot.  And no-one has convinced me that the last changes I made have fixed the issues (nor have I been convinced that they haven't). –Bill

The one rule has to be set to source any, destination IP of LAN-Client, the other rule has to be source IP of LAN-CLient, destination any. just like the VOIP-Rule is.

One major bug that was just discovered was the shaper no longer subtracted 20% from the upload and download values.  If anyone is having trouble with the shaper please re-run the wizard again and subtract 20% from the upload and download values.

Search.  There are atleast 10+ discussions about this.

No, shaping on IPSEC is not supported at this time.

Thanx!! ???

@billm: Correct.  NAT occurs before filter policy (which is what classifies traffic).  There are alternatives, but we're not geared up to use them (and using them isn't terribly scalable at this time). –Bill OK.. policy filtering works fine. just wanted to be sure that if NAT was enabled that the packets were translated before (NAT always sees the packet first right?). I wouldnt worry about alternatives to something that aint broken, and its not limiting in any way as far as I can see.

@Leoandru: been doing some reading on altq and came upon this: http://www.benzedrine.cx/ackpri.html Finally, the rules passing the relevant connections (statefully) are extended to specify what queues to assign the matching packets to. The first queue specified in the parentheses is used for all packets by default, while the second (and optional) queue is used for packets with ToS (type of service) 'lowdelay' (for instance interactive ssh sessions) and TCP ACKs without payload. not sure if it has the same binings to the gui in pfSense. but my guess is that its related. We invisibly create the ACK queue.  ALTQ only shapes outbound on an interface, we create rules for BOTH interfaces and that's what the queues relate to.  An inbound (on the internal interface) and an outbound (on the external interface). –Bill

conf.default/config.xml shoulhave some in it

@sullrich: Bill is working on the issues.  Everyone stay calm. Wait for B2 - I just fixed another old bug and have had some reports of better performance already.  There's more coming, but I'm trying to keep those changes out of 1.0. –Bill

Reinstall from 0.99. This is being manually set in our shaper wizard so this should not be happening.

If you are still having problems, make sure your specifying one protocol per rule.  For example, if you are shaping both TCP and UDP traffic for a specific port, use a rule for each protocol.