• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Diffserv Code Point - advanced option

Scheduled Pinned Locked Moved Firewalling
6 Posts 2 Posters 1.9k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A
    Adam2104
    last edited by May 15, 2013, 11:13 PM

    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 (there's a 0x10 listed, which might be CS2? It's unclear what hex value this is). 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.

    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. reduce the values in the drop down from the large list to the associate TOS values, 1, 2, 3, 4, 5, 6, 7.

    Thoughts on this?

    1 Reply Last reply Reply Quote 0
    • A
      Adam2104
      last edited by May 16, 2013, 2:12 AM

      I did some further testing by modifying /usr/local/www/guiconfig.inc. 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.

      "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".

      1 Reply Last reply Reply Quote 0
      • D
        dhatz
        last edited by May 19, 2013, 8:52 PM

        Which version of pfSense are you testing ?

        1 Reply Last reply Reply Quote 0
        • A
          Adam2104
          last edited by May 19, 2013, 9:54 PM

          This was on pfsense 2.1 beta1. Last snapshot.

          1 Reply Last reply Reply Quote 0
          • D
            dhatz
            last edited by May 19, 2013, 10:24 PM

            @Adam2104:

            This was on pfsense 2.1 beta1. Last snapshot.

            In that case, the issue will probably receive more attention if you post in the 2.1 sub-forum
            http://forum.pfsense.org/index.php/board,53.0.html

            1 Reply Last reply Reply Quote 0
            • A
              Adam2104
              last edited by May 20, 2013, 1:03 AM

              I could certainly do that, however, I'm not sure the issue is 2.1 specific. The same thing happens on version 2.0(3) as well. I played around on the command line and found that pf accepts just about any TOS value you can specify, so its odd that the DSCP list in the GUI is so truncated.

              1 Reply Last reply Reply Quote 0
              2 out of 6
              • First post
                2/6
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                This community forum collects and processes your personal information.
                consent.not_received