illegal tos value after upgrade to 2.6.0
-
IPV4 traffic blocked after 2.6.0 upgrade had to remove TOS values or disable rules. Bug?
/rc.filter_configure_sync: New alert found: There were error(s) loading the rules: /tmp/rules.debug:276: illegal tos value 48 - The line in question reads [276]: match on { igb0 } inet proto udp from any to any port 10823 tos "48" ridentifier 1579401437 queue (qGames) label "USER_RULE: FS2019 - Server"rc.filter_configure_sync: New alert found: There were error(s) loading the rules: /tmp/rules.debug:261: illegal tos value 8 - The line in question reads [261]: match on { igb0 igb1 igb3 } inet from any to any tos "8" ridentifier 1555449354 queue (qOthersLow) label "USER_RULE: low - cs1"
-
I have a similar issue after upgrading to pfSense Plus 22.01. All of my IPV4 traffic was blocked. I was not able to ping from a device on my network to any remote server. DNS was resolving new domains but would not route any packets. I had to disable this rule to fix my issue.
There were error(s) loading the rules: /tmp/rules.debug:308: illegal tos value 40 - The line in question reads [308]: match inet proto { tcp udp } from 192.168.1.0/24 to any tos "40" ridentifier 1614379139 queue (qComm) label "USER_RULE: Discord Voice"This is a DSCP rule. What is strange is that I have other DSCP rules which work fine. The difference is that the DSCP values are lower and the queues are different. These rule have existed in many previous versions of pfSense Plus and older pfSense versions.
-
redmine issue:
https://redmine.pfsense.org/issues/12803 -
The fix for this has been merged.
You can install the System Patches package and then create an entry for
b7b78ea1b14555972efaf7e6c47e48709ad1c199to apply the fix. -
Just found another issue related to DSCP rules.
It seems that the rule will match TOS value instead of DSCP value.For example, I originally set CS1 (DSCP value 8, equal to TOS value 32) in the rule, right now I need to set to CS4 instead to match the packet with DSCP value 8 (TOS value 32)
