Hello,
I was using the squid-reverse package based on squid 2.x up till last
week when i seen it was upgraded and now using the 3.x version of
squid. After upgrading it appeared my QOS ACLs were not marking
traffic which matched any longer. This was confirmed by viewing the
logs and using tcpdump. I was wondering if someone had any thoughts
on this or can confirm/deny it on their own systems.
thanks for your time,
greg
info::
squid.conf ACL section:
acl youtube url_regex -i youtube
tcp_outgoing_tos 0x28 youtube
Some ACL's are marking with 0x38 and 0x20
and at a rate which seems to be hundreds a second, in the cache.log file:
2012/03/26 13:51:37| comm_set_tos: setsockopt(IP_TOS) on FD 391: (22)
Invalid argument
2012/03/26 13:51:37| comm_set_tos: setsockopt(IP_TOS) on FD 466: (22)
Invalid argument
2012/03/26 13:51:37| comm_set_tos: setsockopt(IP_TOS) on FD 626: (22)
Invalid argument
2012/03/26 13:51:37| comm_set_tos: setsockopt(IP_TOS) on FD 133: (22)
Invalid argument
I loaded some pages I know will be an ACL match, confirmed the tos
bits were not being modified by squid:
16:43:50.107671 IP (tos 0x0, ttl 64, id 3501, offset 0, flags [DF],
proto TCP (6), length 52)
16:43:50.109958 IP (tos 0x0, ttl 60, id 20686, offset 0, flags [DF],
proto TCP (6), length 1492)
16:43:50.109981 IP (tos 0x0, ttl 64, id 58289, offset 0, flags [DF],
proto TCP (6), length 52)
--------------------------------------------------------------
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
