Incorrect usage of DSCP hex value
In the firewall UI, certain DSCP selections cause the rule to be created using a DSCP hex, rather than the ToS hex.
Here are two examples, comparing the output of pfctl when used in 2.5.2, 2.6.0, and 2.6.0 with the b7b78ea1b14555972efaf7e6c47e48709ad1c199 patch applied.Relevant pfctl output, after selecting DSCP during rule creation:
- 2.5.2: dscp 0x88
- 2.6.0: tos 0x88
- 2.6.0 (patched): 0x88
- 2.5.2: dscp 0x20
- 2.6.0: ERROR: "illegal tos value 8"
- 2.6.0 (patched): tos 0x08
DSCP AF41 was matched correctly in each case, using the ToS hex. DSCP CS1, however, is not.
0x08 is the DSCP hex value for CS1, but pf is matching based on ToS values. For pf to match CS1 traffic, the rule should be using tos 0x20
This is probably a duplicate of #12803. Technically that was fixed since the ruleset will load but clearly there's still a problem. Apologies if this would have been more appropriate as a comment rather than a new issue.
Updated by Viktor Gurov about 1 month ago
- Assignee set to Viktor Gurov
- Target version set to 2.7.0
- Plus Target Version set to 22.05
It possible to use the "tos cs1" format, instead of the hex value.
Updated by Joshua Niles about 1 month ago
The fix works, thank you.
It's worth noting that for the System_Patches package on 2.6.0 b7b78ea1b14555972efaf7e6c47e48709ad1c199 must be applied before 726c2c891d56132a57fc6ba33a9d62a37223743d and that their order is important for auto apply.
Would be nice to have this in the next 2.6.x release.By the way the rule creation UI has 3 hex options in the DSCP drop-down:
- 0x01 DSCP = 0x04 ToS
- 0x02 DSCP = 0x08 ToS
- 0x04 DSCP = 0x10 ToS
If I'm wrong I think it'd make sense to add "ToS" to those options, since it is a drop-down for DSCP.
Neither of these patches affected the behavior when choosing those 3 hex options, maybe it was a bug introduced in 2.6.0, or I am just confused. I don't have a 2.5.2 system to test with.