pfSense » pfSense Packages

Ok some more information. Step by step of my diagnostics.

1 - Run the wizard and choose the first option, keep as 1 LAN interface and 1 WAN interface. Enter speeds in the boxes (I put 97% of my download speed and 93% of my upload speed), I left the queues default but with intention to change to fairq after. I selected dns, msn, vnc and teamspeak as high priority, steam downloads and battlenet downloads as low priority. Everything else on the priority screens I left in an off state.
2 - After the wizard was completed I noticed results were not quite as expected.
3 - I checked the status -> queues screen, all traffic was only in default queues.
4 - If I enabled logging for the match rules, the log would confirm the rules were been matched.
5 - I also added my own rule to match ack packets, I kept to the same template as used by the other rules, so was added in floating, match rule, wan interface, both directions. This also didnt do anything, but when I enabled the logging option, I could see in log the rule was been matched.
6 - I could also tell the rules were matching packets in the rules screen as that shows hit counters. But 0 packets/bytes in the non default altq queues.
7 - I noticed all examples of traffic shaping for pf queues online are using pass rules so I changed rules to pass and then the packets were been put into the other queues when matching, I did make another bug report about this which got rejected. But this test proves the rules were defenitly matching the traffic but when set to match instead of pass the rules do not push the traffic onto the configured shaper queue.

May I suggest using https://forum.pfsense.org/index.php?board=26.0 until you have a real bug? 'cos this one ain't any better than the previous. Sigh.

I see match mentioned on this page https://home.nuug.no/~peter/pf/en/altqintro.html

But FreeBSD never updated PF to the openbsd 4.6 code base, they stuck to the 4.5 code base.

https://www.freebsd.org/doc/handbook/firewalls-pf.html -> quote "Warning: When reading the PF FAQ, keep in mind that FreeBSD uses the same version of PF as OpenBSD 4.5."

Kill Bill wrote:

May I suggest using https://forum.pfsense.org/index.php?board=26.0 until you have a real bug? 'cos this one ain't any better than the previous. Sigh.

What kind of comment is this, is this a place to file bug reports or a place to be hostile to try and keep bug counts down?

Are you trying to say that when the wizard rules dont serve their purpose its not a bug, if its not a bug then what is it? If you believe it to be operator error, then backup the statement. :)

I gave a step by step even on how to get to where I diagnosed, what exactly do you expect from a bug report? FreeBSD developers fix things with "far" less information. They dont moan they just get on with it.

Yeah exactly, this is to file bug reports. Not "ooops something somehow won't work for me, definitely must be a bug" stuff. So, this is from the wizard-created match rules.

So pardon me, but "all traffic was only in default queues" is just load of bollocks.

Jim Pingle wrote:

The forum is the best place to discuss this until a real bug is identified. It is not about keeping ticket counts down, it's that this is not a support system, it's a place for bug reports.

What you seem to have is a misunderstanding of what the shaper rules do and how they work in your environment, or in general. It's compounded by a lack of understanding of how pfSense traffic shaping works if you're comparing it to the links you're posting.

Please start a forum thread and fully describe your environment and rules, and since you are focused on DNS, describe how your firewall is configured for DNS, where the clients query for DNS, and so on.

you are calling it a misunderstanding but never explained how they should work.

It is one of 2 ways really.

Either

1 - The rules are supposed to classify traffic and push to the appropriate queues, indeed pfSense official documentation even says this.
2 - They are supposed to do nothing (which is what they do now) and its all just for show.

and we have kill bill actually now claiming I am lieing? and its all bollocks, but sorry it is a "fact", if I run the wizard, answer its questions, it does not route traffic to anything outside of the default queue.

Something not working = a bug even if its only for one person.

You guys really are not very friendly.

The forum is a place to discuss issues like "how do I do this" or "how does this work", the responses I read here is a lack of respect to me as both of you have made the assumption that this is operator error.

So questions are.

1 - What is a bug?
2 - Why do you think its operator error.

A unacceptable answer is "well it works for me so that must mean its not a bug because if it works for me it must work for everyone".

I did not explain how they work because this is not a support system, nor is it a discussion platform. All of this belongs on the forum.

Jim if you want to test these new findings up to you but here is an update.

I have discovered the match rules created by the wizard do match and pass on a very small amount of traffic to the qACK queue but nothing to the other queues. This is because it is only matching the initial setup packets of the connection and ignoring the rest.

When changed to a pass rule everything matches up correctly.

I diagnosed this by watching the packet counter for the rule, when set to 'match' it increases a small amount on a new http connection (start of download) but then doesnt increase further, when its a 'pass' rule it keeps increasing and also rapidly during a download.

This test was carried out with http configured to low priority since http is very easy to test with.

I tried but cannot replicate what pfSense says should be the correct behaviour which is match rules classifying all the traffic correctly.

Appending UDP test results blow this line.

Ok here is the results using the dnsbench GRC application which I used to flood my router with outbound dns connections, the results were not the same as TCP tests.

1 - With the default rules created by the wizard it doesnt work but in addition unlike the other match rules there is 0 matches tallied on the rule.
2 - changing to pass whilst still a floating rule is the same result as #1.
3 - Having it as a pass rule on the outbound LAN interface (not floating) it correctly matches the packets and I see dns traffic in qOthersHigh queue.