Floating rule with DiffServ code point af43 doesn't load
-
After upgrade to 2.1-RC0, I received the following notice:
[ There were error(s) loading the rules: /tmp/rules.debug:161: illegal dscp value af43 - The line in question reads [161]: match on { em0 } proto { tcp udp } from any to any dscp af43 queue (qP2P) label USER_RULE: DiffServ af43] -
The issue is still present with the "Sat Jun 22 14:54:39 EDT 2013" build.
Concerning DiffServ, there's another issue, which is not strictly a 2.1 problem, as it was also present in 2.0. But maybe it can be fixed along with the "af43 issue" with little additional effort.
According to RFC 4594, there should also be CS* DSCP values available for the DiffServ field. Very obviously, they are missing from the drop-down box.Okay, I agree that we might rant about "modern times" and "obsolete standards" and whatever, but fact is that there's a lot of VoIP hardware which adheres to the RFC 4594 recommendations.
I do not know if the missing DSCP values are caused by limitation of the underlying software or if it's just a pfSense WebGUI issue.
Anyhow, another issue I have are some of the values which are currently available. Notably the 1-64 and 0x04-0xfc entries. The DiffServ field is 6 bits wide. So the range is 0-63 (decimal) or 0x00-0x3f (hex). Clearly, the mentioned values make no sense in this context.
BTW, when testing by enabling and disabling the "af43 rule", the WebGUI because inaccessible after clicking "Apply Change" after disabling the rule. Had to use Putty to reboot the bix via the command line/SSH.
-
Aw, me again.
Just stumbled accross the entry for bug #2998: http://redmine.pfsense.org/issues/2998
Yes, I'd prefer a simple input field for a TOS/DifServ value, too. Especially since it seems to be the favourite pastime of ever IETF contributor to redefine and rename (and rant about) DSCP values whenever possible.
–---
Interesting, seems that DSCP support doesn't even exist: http://forums.freebsd.org/showthread.php?t=38212
But why did it work in 2.0.x? Or did it just fail silently with less side effects?
-
Interesting, seems that DSCP support doesn't even exist: http://forums.freebsd.org/showthread.php?t=38212
That FreeBSD forum thread is about ipfw, not pf.
-
Thanks. Dumb me, assumed that Google wouldn't present ipfw results for a pf search…
-
According to the official documentation, pf does not offer a DSCP option…so...has anybody an idea where I could find futher information?
"Use the Source, Luke".
Hmpf. Doesn't work, my name is not "Luke".
Anyhow, I decided to stop playing around with my light saber ;-) and had a look into the source. FreeBSD 8.3 pf does indeed not know the dscp option, but there is that patch:
https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_8_3/dscp.RELENG_8.diff
Yup, and it contains an extremly obvious bug: the dscp values are defined to match the corresponding values in the TOS byte. For example, AF11 is defined as 0x28 (40). This is correct, as the values are not shifted around before they get compared to the TOS byte (which is (correctly) bitmasked with 0xfc). What is wrong is the following range check ($$ > 64). Clearly, it shoudl be $$ > 255.
Another issue is in the lines above:
+ else if ($2[0] == '0' && $2[1] == 'x') + $$ = strtoul($2, NULL, 16); + else + $$ = strtoul($2, NULL, 10);Obviously, value ranges like 1-64 or 0x04-0xfc will never work - the code takes just the first number of the range and that's it.
Furthermore, as the user expects a DSCP value (instead of a raw TOS byte value), these values should be multiplied by 4.
I suggest that we get rid of the ranges 1-64 and 0x04-0xfc on the drop down box alltogether. Supporting ranges in pf would require extensive patching, which is simply not worth it, IMHO. As this has never ever worked, and noone seems to have complained about this, I guess that noone will miss range support either.
When this code gets corrected, classes CS1..CS7 should also be added to the list. I suspect that this does not need to be addressed in the patch, but could be done in pfSense's PHP code (providing the values as numeric arguments for pfctl). Of oucrse, one needs to be aware about the multiplication by 4, depending on if it gets implemeneted (as proposed by me) or left out.
Class CS0 (or DSCP DF, or 0x00) should not be in the list, as it won't work, as far as I can see.
-
Okay, four pull requests waiting. Yup, four - first time I worked with Github.
Edit: Ah, well, I should probably mention that my ID on Github is Klaws–. I would have liked Klaws++, but Github doesn't allow the plus character in user names, so I settled for the humble Klaws--.
-
Kernel and GUI patches made it into the latest build. Everything working fine as far as I can see so far, except that code point VA went missing from the drop-down-box. Sorry, my fault. Will add it when time permits during the next few days.