[squid-users] Feature request: tos based acl
Hi, all! I've searched the archives and not been able to find an answer so I thought I'd post. Apologies if it's been covered before. In the squid document, the directive tcp_outgoing_address says: # NOTE: The use of this directive using client dependent ACLs is # incompatible with the use of server side persistent connections. To # ensure correct results it is best to set server_persistent_connections # to off when using this directive in such configurations. Can any one explain what is the client dependent ACL may occur error there ? And how can we use the header base acl ?
Re: [squid-users] Squid3.3.10 tcp_outgoing_tos still does work with freeBSD ?
Hi, Andrew! Thanks for your reply! Here is what i saw in my cache.log 2013/12/26 15:20:27.896 kid1| forward.cc(1063) connectStart: fwdConnectStart: got outgoing addr 0.0.0.0, tos 64 2013/12/26 15:20:27.896 kid1| AsyncCall.cc(18) AsyncCall: The AsyncCall fwdConnectDoneWrapper constructed, this=0x8042778d0 [call478] 2013/12/26 15:20:27.896 kid1| peer_select.cc(96) peerSelectStateFree: http://n.baidu.com/v.gif?pid=107&url=http%3A%2F%2Fbaijia.baidu.com%2F&type=0&m=11&ct=1&a=1&c=top&pn=2&t=%E3%80%8A%E6%96%B0%E9%97%BB%E6%99%9A%E6%8A%A5%E3%80%8B%E5%85%B3%E5%BC%A0%EF%BC%9A%E8%AF%9E%E7%94%9F%E6%97%B6%E5%B0%B1%E6%9C%89%E8%87%B4%E5%91%BD%E7%BC%BA%E9%99%B7&ra=0.04313793289206358 2013/12/26 15:20:27.896 kid1| store.cc(570) unlock: StoreEntry::unlock: key '9774012C8A4E51137F545C2B8170CB31' count=2 2013/12/26 15:20:27.896 kid1| comm.cc(554) comm_openex: comm_openex: Attempt open socket for: 0.0.0.0 2013/12/26 15:20:27.896 kid1| comm.cc(595) comm_openex: comm_openex: Opened socket local=0.0.0.0 remote=[::] FD 18 flags=1 : family=2, type=1, protocol=6 2013/12/26 15:20:27.896 kid1| ip/Qos.cci(31) setSockTos: Ip::Qos::setSockTos: setsockopt(IPV6_TCLASS) on local=0.0.0.0 remote=[::] FD 18 flags=1: (22) Invalid argument On Sat, Dec 28, 2013 at 12:40 AM, Andrew Beverley wrote: > On Thu, 2013-12-26 at 15:59 +0800, Ge Jin wrote: >> Hi all! >> >> We want to use tcp_outgoing_tos with freeBSD 10.0-BETA2. > > [...] > >> So, it's the tcp_outgoing_tos still has bug in freeBSD or I have some >> mistake there ? > > Have you tried increasing the logging level? Set it to at least level 3 > and see if/what TOS errors/messages you get. There will be a lot of > messages, so look for the following strings: > > "fwdConnectStart: got outgoing addr" [will be followed by tos being set] > > "Ip::Qos::setSockTos: setsockopt(IP_TOS)" on [will be shown on error] > >
[squid-users] Re: Squid3.3.10 tcp_outgoing_tos still does work with freeBSD ?
And I tested with the same sutation on my Ubuntu server, it works correct :) On Thu, Dec 26, 2013 at 3:59 PM, Ge Jin wrote: > Hi all! > > We want to use tcp_outgoing_tos with freeBSD 10.0-BETA2. > > And our test cases is very simple. > Here is the related configure. > # Squid normally listens to port 3128 > acl normal_service_net src 192.168.1.1/32 > acl good_service_net src 192.168.2.1/32 > tcp_outgoing_tos 0x20 normal_service_net > tcp_outgoing_tos 0x00 bad_service_net > visible_hostname squid > > clients---> squid ---> router > > And the 192.168.175.9 is my outgoing address. > > root@Squid:~ # tcpdump -n -i eth1 -vv src 192.168.175.9 > > tcpdump: listening on vlan708, link-type EN10MB (Ethernet), capture > size 65535 bytes > > capability mode sandbox enabled > > 15:52:35.208420 IP (tos 0x20, ttl 64, id 497, offset 0, flags [DF], > proto TCP (6), length 533, bad cksum 0 (->8115)!) > > 192.168.175.9.10902 > 115.239.210.27.80: Flags [P.], cksum 0xb7c4 > (incorrect -> 0x7295), seq 2526677121:2526677614, ack 178086541, win > 17280, length 493 > > 15:52:35.236238 IP (tos 0x20, ttl 64, id 498, offset 0, flags [DF], > proto TCP (6), length 40, bad cksum 0 (->8301)!) > > 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 > (incorrect -> 0x7bdb), seq 493, ack 1860, win 15840, length 0 > > 15:52:35.236385 IP (tos 0x20, ttl 64, id 499, offset 0, flags [DF], > proto TCP (6), length 40, bad cksum 0 (->8300)!) > > 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 > (incorrect -> 0x7bdb), seq 493, ack 4740, win 12960, length 0 > > 15:52:35.236396 IP (tos 0x20, ttl 64, id 500, offset 0, flags [DF], > proto TCP (6), length 40, bad cksum 0 (->82ff)!) > > 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 > (incorrect -> 0x7bdb), seq 493, ack 7620, win 10080, length 0 > > 15:52:35.236546 IP (tos 0x20, ttl 64, id 501, offset 0, flags [DF], > proto TCP (6), length 40, bad cksum 0 (->82fe)!) > > 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 > (incorrect -> 0x7bdb), seq 493, ack 10500, win 7200, length 0 > > 15:52:35.236557 IP (tos 0x20, ttl 64, id 502, offset 0, flags [DF], > proto TCP (6), length 40, bad cksum 0 (->82fd)!) > > 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 > (incorrect -> 0x7bdb), seq 493, ack 13380, win 4320, length 0 > > 15:52:35.236571 IP (tos 0x20, ttl 64, id 503, offset 0, flags [DF], > proto TCP (6), length 40, bad cksum 0 (->82fc)!) > > 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 > (incorrect -> 0x7bdb), seq 493, ack 16124, win 1576, length 0 > > 15:52:35.237315 IP (tos 0x20, ttl 64, id 505, offset 0, flags [DF], > proto TCP (6), length 40, bad cksum 0 (->82fa)!) > > 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 > (incorrect -> 0x3e83), seq 493, ack 16124, win 17280, length 0 > > 15:52:35.358903 IP (tos 0x20, ttl 64, id 648, offset 0, flags [DF], > proto TCP (6), length 541, bad cksum 0 (->7f86)!) > > 192.168.175.9.10903 > 115.239.211.11.80: Flags [P.], cksum 0xb8bc > (incorrect -> 0xca99), seq 1454826059:1454826560, ack 1068107219, win > 17280, length 501 > > 15:52:35.362187 IP (tos 0x0, ttl 64, id 649, offset 0, flags [DF], > proto TCP (6), length 44, bad cksum 0 (->9029)!) > > 192.168.175.9.10905 > 180.149.131.210.80: Flags [S], cksum 0xa838 > (incorrect -> 0x5376), seq 239622, win 16384, options [mss 1460], > length 0 > > 15:52:35.386524 IP (tos 0x20, ttl 64, id 654, offset 0, flags [DF], > proto TCP (6), length 40, bad cksum 0 (->8175)!) > > 192.168.175.9.10903 > 115.239.211.11.80: Flags [.], cksum 0xb6c7 > (incorrect -> 0x0a4c), seq 501, ack 260, win 17021, length 0 > > 15:52:35.419373 IP (tos 0x0, ttl 64, id 657, offset 0, flags [DF], > proto TCP (6), length 40, bad cksum 0 (->9025)!) > > 192.168.175.9.10905 > 180.149.131.210.80: Flags [.], cksum 0xa834 > (incorrect -> 0x2fb1), seq 239623, ack 860488872, win 17280, > length 0 > > 15:52:35.422048 IP (tos 0x0, ttl 64, id 658, offset 0, flags [DF], > proto TCP (6), length 504, bad cksum 0 (->8e54)!) > > 192.168.175.9.10905 > 180.149.131.210.80: Flags [P.], cksum 0xaa04 > (incorrect -> 0xce68), seq 0:464, ack 1, win 17280, length 464 > > So, it's the tcp_outgoing_tos still has bug in freeBSD or I have some > mistake there ?
[squid-users] Squid3.3.10 tcp_outgoing_tos still does work with freeBSD ?
Hi all! We want to use tcp_outgoing_tos with freeBSD 10.0-BETA2. And our test cases is very simple. Here is the related configure. # Squid normally listens to port 3128 acl normal_service_net src 192.168.1.1/32 acl good_service_net src 192.168.2.1/32 tcp_outgoing_tos 0x20 normal_service_net tcp_outgoing_tos 0x00 bad_service_net visible_hostname squid clients---> squid ---> router And the 192.168.175.9 is my outgoing address. root@Squid:~ # tcpdump -n -i eth1 -vv src 192.168.175.9 tcpdump: listening on vlan708, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled 15:52:35.208420 IP (tos 0x20, ttl 64, id 497, offset 0, flags [DF], proto TCP (6), length 533, bad cksum 0 (->8115)!) 192.168.175.9.10902 > 115.239.210.27.80: Flags [P.], cksum 0xb7c4 (incorrect -> 0x7295), seq 2526677121:2526677614, ack 178086541, win 17280, length 493 15:52:35.236238 IP (tos 0x20, ttl 64, id 498, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->8301)!) 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect -> 0x7bdb), seq 493, ack 1860, win 15840, length 0 15:52:35.236385 IP (tos 0x20, ttl 64, id 499, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->8300)!) 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect -> 0x7bdb), seq 493, ack 4740, win 12960, length 0 15:52:35.236396 IP (tos 0x20, ttl 64, id 500, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->82ff)!) 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect -> 0x7bdb), seq 493, ack 7620, win 10080, length 0 15:52:35.236546 IP (tos 0x20, ttl 64, id 501, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->82fe)!) 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect -> 0x7bdb), seq 493, ack 10500, win 7200, length 0 15:52:35.236557 IP (tos 0x20, ttl 64, id 502, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->82fd)!) 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect -> 0x7bdb), seq 493, ack 13380, win 4320, length 0 15:52:35.236571 IP (tos 0x20, ttl 64, id 503, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->82fc)!) 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect -> 0x7bdb), seq 493, ack 16124, win 1576, length 0 15:52:35.237315 IP (tos 0x20, ttl 64, id 505, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->82fa)!) 192.168.175.9.10902 > 115.239.210.27.80: Flags [.], cksum 0xb5d7 (incorrect -> 0x3e83), seq 493, ack 16124, win 17280, length 0 15:52:35.358903 IP (tos 0x20, ttl 64, id 648, offset 0, flags [DF], proto TCP (6), length 541, bad cksum 0 (->7f86)!) 192.168.175.9.10903 > 115.239.211.11.80: Flags [P.], cksum 0xb8bc (incorrect -> 0xca99), seq 1454826059:1454826560, ack 1068107219, win 17280, length 501 15:52:35.362187 IP (tos 0x0, ttl 64, id 649, offset 0, flags [DF], proto TCP (6), length 44, bad cksum 0 (->9029)!) 192.168.175.9.10905 > 180.149.131.210.80: Flags [S], cksum 0xa838 (incorrect -> 0x5376), seq 239622, win 16384, options [mss 1460], length 0 15:52:35.386524 IP (tos 0x20, ttl 64, id 654, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->8175)!) 192.168.175.9.10903 > 115.239.211.11.80: Flags [.], cksum 0xb6c7 (incorrect -> 0x0a4c), seq 501, ack 260, win 17021, length 0 15:52:35.419373 IP (tos 0x0, ttl 64, id 657, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->9025)!) 192.168.175.9.10905 > 180.149.131.210.80: Flags [.], cksum 0xa834 (incorrect -> 0x2fb1), seq 239623, ack 860488872, win 17280, length 0 15:52:35.422048 IP (tos 0x0, ttl 64, id 658, offset 0, flags [DF], proto TCP (6), length 504, bad cksum 0 (->8e54)!) 192.168.175.9.10905 > 180.149.131.210.80: Flags [P.], cksum 0xaa04 (incorrect -> 0xce68), seq 0:464, ack 1, win 17280, length 464 So, it's the tcp_outgoing_tos still has bug in freeBSD or I have some mistake there ?
Re: [squid-users] Force squid use dns query result as the destination server in squid tproxy
Hi, Amos! Thanks for your reply! To make a long story short, our struct is like this. tproxy tproxy client -> haproxy -> squid cluster --> Router ---> internet We use haproxy for load balance, and squid for caching. And the most difficult part is the Router must see the clients source addresses. So we want to deliver the client address by tproxy. But haproxy just delivers the clients addresses and the squid address as the destination address. So I supposed there can be some workaround on squid for my purpose. On Wed, Dec 25, 2013 at 6:05 PM, Amos Jeffries wrote: > On 25/12/2013 9:12 p.m., Ge Jin wrote: >> Hi, all! >> >> We use squid with tproxy for caching. As our special construct, >> our client origin destination is useless for getting the right >> response. > > Why? what mangling are you doing to the TCP packet routing that would > cause the client browser to be connecting directly (as it sees it) to an > invalid IP address? > > >> So if there is any workaround, can we force squid use the >> Host header query result as the origin destination server address for >> fetch response. > > Dont. http://www.squid-cache.org/Advisories/SQUID-2011_1.txt > > Fix the above mentioned design problem with client traffic instead. > Ability to use the Host header flows naturally from that. > > >> Here is the log I get >> >> 1387958630.972 7142 192.168.1.13 TCP_MISS/503 3817 GET >> http://www.yahoo.com/ - HIER_DIRECT/192.168.134.32 text/html >> # >> "HIER_DIRECT/192.168.134.32" is the right destination server address. >> >> And I search this >> http://www.mail-archive.com/squid-users@squid-cache.org/msg92356.html >> and it's the revserse side of my situation, and I tried >> client_dst_passthru off and seems no help. > > "client_dst_passthru off" will only work in request cases where the > TCP-level destination IP and the HTTP-level Host: header can be > validated as pointing at the same service (not necessarily same server > IP) via an independent DNS lookup by Squid. > > NP: Cases where it is possible to use the Host header for destination > selection are the same cases where caching is permitted for the > response. So your brokenness of the client destination IP is also > breaking caching. > >> >> Does anyone here can help ? >> > > Before any help is given we come back to the initial question of "why?". > There is very probably a better way to do what you want. So please > explain the full usage for this proxy. > > Amos >
[squid-users] Force squid use dns query result as the destination server in squid tproxy
Hi, all! We use squid with tproxy for caching. As our special construct, our client origin destination is useless for getting the right response. So if there is any workaround, can we force squid use the Host header query result as the origin destination server address for fetch response. Here is the log I get 1387958630.972 7142 192.168.1.13 TCP_MISS/503 3817 GET http://www.yahoo.com/ - HIER_DIRECT/192.168.134.32 text/html # "HIER_DIRECT/192.168.134.32" is the right destination server address. And I search this http://www.mail-archive.com/squid-users@squid-cache.org/msg92356.html and it's the revserse side of my situation, and I tried client_dst_passthru off and seems no help. Does anyone here can help ?
