Floating rule for QoS and qACK?
-
Ah, okay. Well, none of this (AFAIK) is documented anywhere, and the default setup the wizard generates is broken, since it doesn't set that stuff up.
Which "stuff" does it not set up? Are you saying you needed to edit the rules for DNS and VoIP to get them using the qACK? I'm just trying to learn what I might need to do to get mine working better.
-
No, what I'm saying is that a vanilla wizard run create qACK, but never creates any rules that use it - as far as I can tell, anyway…
-
My wizard run with single-WAN/Multi-LAN created a rule or two that use qACK. At least it looks that way to me…. Am I missing something?
-
Are you saying that dns rule was created automatically, including setting the queue/ackqueue fields?
-
Yes. I did not create the rule. In the wizard, I did choose for DNS to have a "higher priority".
-
Okay, so you did have to do something though. My complaint was this: prioritizing ACKs is a fairly typical thing for shapers to do, although not required, but if you are not setting anything at all, why does it bother creating the ACK queue at all?
-
The wizard does assign traffic to the ACK queue. The only thing that changed from 1.2.3 to 2.x is that now you manually assign it instead of it being automagically grabbing every single ACK.
I actually prefer 2.0's method, as I don't like p2p ACKs to end up in the ACK queue, cause I don't care about p2p and definitely don't want it to flood the queue and prevent more important traffic. -
Maybe we are having a disconnect here. My point was that it does not assign said traffic by default. There is no comment or documentation or anything else that says this, so some poor stupe who does a vanilla walk-thru of the wizard will get an ACK queue that never has traffic go to it. There is also nothing I've been able to find that tells you how to make 'the right thing' happen. So, it looks broken to the average guy who is used to it working out of the box in 1.2.3. I guess we have a philosophical disagreement here - if you don't like the default behavior because you do P2P stuff, that's your call, and you can tweak the queues as you wish (IMO of course…)
-
So tell me, how DO you 'manually assign traffic to the ACK queue'? Keep in mind the ACKs most people care about are outbound ACKs which are in response to inbound TCP packets. Most of the time those will be inbound TCP flows which are not handled by the normal inbound port forwarding and etc, but rather, response packets to outbound http get commands or whatever. So, there is no inbound rule I can toggle the qACK on for, so… How does this work? Again, I've looked at the doc.pfsense.org site and the traffic shaping guide for 2.0 is completely devoid of any useful information in this regard, which is what my complaint was in the first place. I'm not a dummy, and it isn't obvious to me how this works...
-
It actually should have put in rules that had things such as "qACK / qHighPri" when you say, make HTTPS or something like that a higher priority.
Least it did when I used the wizards last.
-
might be more an "ermal" question cause I'm still not 100% sure about how the shaper works yet, and yes, the wiki and other docs I've seen are either abysmally devoid of anything, or they're so over my head that I can't quite get what they're writing about. Then again ermal is awesome, but tends to be over people's heads :P
I'm not sure why you'd need a rule to shape inbound traffic, unless you're shaping traffic goign to a webserver LAN-side. In which case, I'd think that the default HTTP/S rule would work, as I believe seeing it say soemthing like:
Direction: Any
Source: Any
Destination: Any
Port: HTTP(s)so that would work for both in and outbound traffic.
-
You're missing my point. By definition you don't need a rule for return traffic, and it's the ACKs for that return traffic I care about. I guess it's fortunate this isn't a show stopper for me. If I could get some kind of bridging VM appliance that sat between pfsense and the LAN, that was actually supported, I'd do so in a flash, but I don't, so I guess I deal with the lack of documentation or support.
-
Ahhhh
I think I found out the issue that you're describing. If you do not assign HTTP (or whatever) to a higher or lower priority queue, it is left to the default, which doesn't automagically assign ACKs, due to no rule being there.If you want that behavior though, the easiest way I've found is to create a rule on the floating tab, with something along these lines:
Action:queue
protocol: any
source: any
destination: any
queue: qACK/qDefaultThen, move this rule to the very top of the floating tab before all other rules. All traffic will then have access to the ACK queue by default, and it will allow other assignments to change the traffic to another queue is needed.
The bad news is that there will be an extra rule to process for each state. Under light use, this won't be a problem, but when you get to heavy business rates, it could choke the CPU.