[squid-users] WARNING: Tos value ... adjusted

Nick Rogers ncrogers at gmail.com
Wed Apr 22 21:14:44 UTC 2015


After upgrading from 3.4.x to 3.5.x, I've noticed a new error message with
my squid configuration. Apparently squid 3.5 no longer allows setting the
two lower-most ECN bits of the ToS byte. I realize that this is to
encourage people to use the modernized definition of ToS being a 6 bit DSCP
field and a two bit ECN field, however enforcing this in the configuration
parser introduces a big problem for me. I use the ToS byte as a way to tag
outbound requests from squid based on ACLs, to then queue the traffic
differently via PF + ALTQ engine on FreeBSD. This is a way to queue upload
traffic from squid on a per-IP/ACL basis. Having 256 values (8 bit ToS) to
work with is a lot preferable than only 64 (6 bit DSCP field). I'm not sure
if I care if the ECN bits are set, as it is likely scrubbed away by my
upstream ISP, or I can normalize it with PF. The point is I really need to
be able to tag outgoing packets with the full 8 bits of the ToS byte, not
just 6. I've been doing this for nearly a decade since early squid 2.x.

So my question is, is the squid team willing to revert this change
entirely, and leave it up to the admin to decide what ToS values are
appropriate. Or are you guys now pretty adamant about never setting the ECN
field?

It looks like the change got snuck into this commit along with fixing some
other tcp outgoing tos bugs. It really caught me off-guard because there is
no mention of this new behavior in the changelog.

https://github.com/squid-cache/squid/commit/651ba437462fb5fde21f8d3b66d09afa1e069d5c

The enforcement happens in src/cache_cf.cc. Its 5 lines of code that seem
trivial to either remove or make configurable, however I am not sure how to
go about making it configurable. I am debating just patching my squid
builds to remove the check against the ToS field, but I would like to use
unmodified squid 3.5.x. I'm not sure if going from 256 to 64 possible
fields is possible for my deployments.

Thanks.

-Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150422/a3237827/attachment.html>


More information about the squid-users mailing list