Bug #2998
closed
Diffserv Code Point options misleading
0%
Description
In pfsense 2.1 beta1, on the Firewall -> Rules -> Edit page there's an option for "Diffserv Code Point". This is a drop down with a set of DSCP values listed. However, my testing shows that internally pf only honors TOS Precedence, not Diffserv. As an example, the dropdown has the following values:
af11
af12
af13
These are different from a diffserv perspective. However, from a TOS perspective they are all the same, TOS 1. As a result, if I create a pass or block rule that targets just af11, it also applies to af12 and af13. That's all fine and good, I suppose, but it makes the GUI slightly misleading because pf isn't operating on DSCP, its operating on TOS.
There's corresponding DSCP values for TOS 2 (af21, af22, af23), TOS 3 (af31, af32, af33), TOS 4 (af41, af42, af43). Interestingly, all the CSx DSCP values are missing. Then, there's EF specified. This should correspond to TOS 5, however, pf throws an error when I try to apply a rule with DSCP EF saying that EF is an invalid value. This means that there's no way to set TOS 5 currently.
I did some further testing via the command line. It seems the "dscp" parameter of filter rules is not as robust as the "tos" parameter, despite being able to do the same sort of thing. For example:
"dscp ef" is rejected outright as an invalid DSCP value. The same applies to the class selectors like cs3 and cs5.
"tos 184" is accepted though, which is identical in meaning to "dscp ef".
As such, it seems like a beneficial change would be to adjust this as such:
1. rename this to TOS, because that's what pf is actually honoring.
2. Change the drop down to a text field that accepts manually entered TOS values.
Thoughts on this?
Updated by Klaus Stock almost 11 years ago
As the TOS field has an "unstable history" (RFC 3168), a most flexible approach should be imperative. That means that the user needs to be able to choose if he want to honor bits 6 & 7 as ECN or not - the latter case for devices or software which insist on putting 0x02 (aka lowcost or mincost) into the TOS field.
The other point are the limitations of ipfw. DSCP support in ipfw appears not to be stable.
Proposed solution: a simple text input field to allow a sequence of comma-sepaartaed TOS values (in hex or decimal notation). Of vital importance would be a table (next to the input field), which gives the user an overview over the most popular values:
DF = 0x00 (0)
EF = 0xB8 (184)
...
AF11 = 0x28 (40)
AF12 = 0x2C (48)
AF13 = 0x38 (56)
...
CS4 = 0x80 (128)
CS5 = 0xA0 (160)
The table will also help to clarify how the bits are aligned.
Drawback: when ECN is present in the traffic, the ECN bits will add some value in the range of 1..3 to the listed values. Oh well, I wouldn't mind if I had to enter "40,41,42,43" for AF11 in an ECN-enabled network.
Updated by Klaus Stock almost 11 years ago
Forget my bullshit about ipfw above - Goole managed to sneak some ipfw results into my "pf" search, I just a bit confused and even typed ipfw myself...
pf as of FreeBSD doesn't support DSCP, its source is patched to add this feature in pfSense. Unfortunately, there are a few issues with this patch. Please see my post in the forum (which also suggests some possible fix): http://forum.pfsense.org/index.php/topic,63580.msg345511.html#msg345511
Updated by Klaus Stock almost 11 years ago
I decided to go for the "minimally invasive" approach:
1. I added the CSx itens to the drop-down box.
2. I fixed the kernel patch, where a bug prevented DSCP values > 16.
3. I also added a missing bit-shift operation (the dscp parameter didn't take DSCP values in the range 11.63; instead, it expeczed TOS values).
4. I also checked the rest of the dscp kernel patch code. Found no other bugs, so DSCP should work on pfSense once my fix is accepted.
I supplied my fixes in form of four separate pull requests on Github (sorry for four separate forks, was the first time I worled with Guthub...). My Guthub ID is Klaws--.
Updated by