Hi, I applied the patch but it doesn’t seem to be working. I did a bit of other testing. I read the bug report and saw that the regression was in 3.1.12, so I tried 3.1.11 and also saw poor results (it actually seemed as if the occasional packet would have tos set, but not most). For testing I was telling squid to tag all packets so I could be pretty certain nothing was misconfigured.
I then compiled 3.0 stable 26, and it has worked flawlessly all day, tagging client packets that matched a dstdom_regex acl. Thanks, Brian On Mar 22, 2012, at 11:45 PM, Amos Jeffries wrote: > On 21/03/2012 10:19 a.m., Brian Landy wrote: >> On Mar 20, 2012, at 10:20 AM, Amos Jeffries wrote: >> >>> On 21/03/2012 2:26 a.m., Brian Landy wrote: >>>> Hi, I was hoping to use traffic shaping to reserve bandwidth for http >>>> streaming video, and use squid to tag the video traffic separately from >>>> other content. I am running OpenBSD 5.0 with squid 2.7, using squid as a >>>> transparent non-caching proxy. I am attempting to get squid to set the TOS >>>> on the packets from server to client so pf can assign them to an >>>> appropriate queue (outbound on the internal interface). >>>> So I tried something like this: >>>> >>>> acl webvideo rep_mime_type -i ^video/MP2T$ >>>> acl webvideo rep_mime_type -i ^video/mp4$ >>>> tcp_outgoing_tos 0x15 webvideo >>>> >>>> However, as best I can tell squid is not setting the tos on any of these >>>> packets. Have I overlooked something? (the 0x15 was picked at random) I >>>> verified I have the rep_mime_types defined properly by setting >>>> “http_reply_access deny webvideo” and the content was blocked. >>> You overlooked that outgoing TOS is on the request from Squid to the >>> server. Squid does not have any reply yet. >>> >>> You need to find some request-based way to predict what type of reply will >>> come back. I would think a few false positives would be fine so you can >>> probably base it on the domain name or a URL file-extension pattern. Squid >>> ACLs have full access to any header content though, there may be something >>> better buried in there. >>>> Also, to validate that squid was able to set TOS at all, I tried this: >>>> >>>> acl all src all >>>> tcp_outgoing_tos 0x15 all >>>> >>>> In this case I see the tos set on the packets to the server, but not set >>>> on the packets back to the client (which I believe I need set in order to >>>> assign the streaming content to the appropriate queue on the inside >>>> interface). >>> There is a clientside_tos in Squid-3 series for the packets going from >>> Squid to client. >>> >>>> Any advice on what I am doing wrong, or whether squid is even the correct >>>> approach for this, is greatly appreciated. Thanks! >>> You need to upgrade to squid-3. Preferrably the current supported release >>> (3.1.19 as of this writing). >>> >>> >>> Amos >> Thanks, I’ve installed 3.1.19 and have been giving it a try. It seems like >> clientside_tos is exactly what I want. >> >> However, I have been unable to get it to work on some simple examples: >> >> acl myhost 192.168.0.1 >> http_access allow myhost >> clientside_tos 0x15 myhost >> >> or >> >> acl d_any all >> http_access allow d_any >> clientside_tos 0x15 any >> >> or >> >> clientside_tos 0x15 all >> >> When I inspect the packets returned from the proxy to the client, tos is not >> set. Any thoughts? >> >> And to clarify, matching rep_mime_type won’t work for this, in conjunction >> with clientside_tos, even though it inspects the reply? > > Sorry, mea culpa, this is http://bugs.squid-cache.org/show_bug.cgi?id=3504 > > You can find the patch at > http://master.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-10444.patch > > If there are any problems with it please let me know asap. > > Amos
