Project

General

Profile

Actions
Copy link

Regression #13178

closed

Incorrect usage of DSCP hex value

Added by Joshua Niles over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Viktor Gurov
Category:
Rules / NAT
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:

Description

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 af41 during rule creation:
  • 2.5.2: dscp 0x88
  • 2.6.0: tos 0x88
  • 2.6.0 (patched): 0x88
Relevant pfctl output, after selecting DSCP cs1 during rule creation:
  • 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.

Related to #12803 and #12846
Also: https://redmine.pfsense.org/issues/12040#note-1

Actions
Copy link
 #1

Updated by Viktor Gurov over 2 years 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.

fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/789

Actions
Copy link
 #2

Updated by Jim Pingle over 2 years ago

  • Status changed from New to Pull Request Review
Actions
Copy link
 #3

Updated by Viktor Gurov over 2 years ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #4

Updated by Joshua Niles over 2 years 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
  • 0x02
  • 0x04
Those are all used directly by pf as ToS hex values. I'm not sure that 0x01 is even a valid ToS option, and I'm guessing that those hex options are intended to refer to the DSCP hex where:
  • 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.

Actions
Copy link
 #5

Updated by Jim Pingle over 2 years ago

  • Status changed from Feedback to Resolved

This is OK as-is for now. We could consider the other change as a separate request for the next release if needed.

Actions
Copy link

Also available in: Atom PDF