Project

General

Profile

Actions

Bug #2998

closed

Diffserv Code Point options misleading

Added by Adam Gensler almost 11 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Rules / NAT
Target version:
-
Start date:
05/19/2013
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:

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?

Actions

Also available in: Atom PDF