If you give me an instructions how to run Squid in a debugger and what kind of a results you expect,
i could do it on the next Saturday or Sunday.
Also, could you answer for the next question:
Client delay pools is the tool to limit what client sends to internet (upload bandwidth)?
I'm looking for a way to limit the per-client upload stream.
If The Client delay pools serves another purpose, i just forget about it feature.
02.04.2013 13:52, Amos Jeffries пишет:
On 2/04/2013 11:26 p.m., Pavel Bychykhin wrote:
Hi All!
My system is FreeBSD 9.0
My SQUID ver. is 3.2.9.
Recently i tried to define some rules for the client delay pools.
Here part from my config:
acl to_rfc1579 dst 192.168.0.0/16
acl to_rfc1579 dst 10.0.0.0/8
acl to_rfc1579 dst 172.16.0.0/12
client_delay_pools 1
client_delay_parameters 1 16384 16384
client_delay_access 1 allow all !to_rfc1579
After that Squid died, and i see in log:
2013/04/02 10:48:56 kid1| ACL::checklistMatches WARNING: 'to_rfc1579' ACL is used but there is no HTTP request -- not matching
2013/04/02 10:48:56 kid1| assertion failed: cbdata.cc:463: "c->locks > 0"
If you are able to run Squid in a debugger I'm very interested in seeing a stack trace from that assertion.
Is it a bug, or i just don't understand something about an access lists.
Both. Assert is always a bug and the client_delay_pool operates right after the TCP SYN is accept()'ed.
client_delay_access is tested as soon as the TCP SYN packet has been accepted. All Squid has for ACLs to work with at that point is the IP:port of
each end of the client TCP connection.
client_delay_access can be used with: src, arp, localip / myip, localport / myport.
"myportname" ACL should in theory work as well, but looking at the code I see the required details are not yet passed to the ACL code properly so
that is broken.
The dst ACL is for testing the destination IP address an HTTP request might be going to. It requires an HTTP request URL to locate a domain name then
DNS to locate the IP addresses.
Amos
--
Best regards,
Pavel
