[squid-users] Squid-3.5.2 and FreeBSD 10.1

Amos Jeffries squid3 at treenet.co.nz
Fri Feb 20 12:05:18 UTC 2015 

On 21/02/2015 12:35 a.m., Odhiambo Washington wrote:
> On 20 February 2015 at 13:57, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> 
>> On 20/02/2015 10:09 p.m., Odhiambo Washington wrote:
>>> On 20 February 2015 at 04:15, Amos Jeffries <squid3 at treenet.co.nz>
>> wrote:
>>>
>>>> On 20/02/2015 5:15 a.m., Odhiambo Washington wrote:
>>>>> On 19 February 2015 at 15:12, Odhiambo Washington <odhiambo at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Amos,
>>>>>>
>>>>>> I did see that thread. However, the discussion was still continuing
>>>> then.
>>>>>>
>>>>>>
>>>>>> I will apply it to my server and see.
>>>>>>
>>>>>> Reporting back today!
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 19 February 2015 at 14:07, Amos Jeffries <squid3 at treenet.co.nz>
>>>> wrote:
>>>>>>
>>>>>>> On 19/02/2015 10:49 p.m., Odhiambo Washington wrote:
>>>>>>>> I have been hoping that 3.5.2 would possibly help address my
>> problems
>>>>>>> with
>>>>>>>> ACLs, but alas!
>>>>>>>
>>>>>>> Ah, I thought you saw this announcement made just after your last
>>>>>>> message in Jan:
>>>>>>>
>>>>>>> <
>>>>>>>
>>>>
>> http://lists.squid-cache.org/pipermail/squid-users/2015-January/001745.html
>>>>>>>>
>>>>>>>
>>>>>>> Its sounds very much like what your last few threads have been
>>>>>>> describing as happening. Signal handling issues will affect all the
>>>>>>> squid -k operations.
>>>>>>>
>>>>>>> Amos
>>>>>>>
>>>>>>
>>>>>
>>>>> I have compiled a custom kernel after applying this patch mentioned in
>>>> that
>>>>> thread.
>>>>
>>>> Er. There were two patches mentioned as being applied in the FreeBSD
>>>> mail and bug reports.
>>>>
>>>>>
>>>>> wash at mail:~$ uname -a
>>>>> FreeBSD mail.ili.or.ug 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #4: Thu
>>>> Feb
>>>>> 19 16:55:56 EAT 2015     root at mail.ili.or.ug:/usr/obj/usr/src/sys
>>>>> /BEASTIE-10.x  amd64
>>>>>
>>>>>
>>>>> However, my issues still persist.
>>>>>
>>>>> root at mail:/opt # /opt/squid-3.5.2/sbin/squid -k reconfigure
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>> 2015/02/19 19:10:53.639| Acl.cc(380) ~ACL: freeing ACL
>>>>>
>>>>>
>>>>> Would this then suggest there is a problem with my squid.conf
>>>>> <http://pastebin.com/wwwcnHnF> ?
>>>>>
>>>>> Or the FreeBSD problem isn't quite solved?
>>>>>
>>>>
>>>> Could you re-state what the problem is?
>>>>
>>>> Now your pastebin is expired all we have on record about this problems
>>>> is the sentence: "it's crashing with errors as seen from <DEAD URL>"
>>>>
>>>
>>>
>>> Generally, Squid seems to partially ignore my time-based ACLS as seen in
>>> the squid.conf
>>>
>>
>> Oh. I thought you were talking about crashes still since you keep
>> posting that -k reconfigure output (its odd, but only in that it should
>> not be that visible).
>>
>>
>>
>>> It would block one site but allow the others. I expect a standard
>> blocking
>>> within the specied time.
>>>
>>> I have not been able to figure out why.
>>>
>>> For instance, my ACL for TIMEWASTAGESITED contains .facebook.com, .
>> gmail.com
>>> and .youtube.com as dstdomains.
>>>
>>> I find that youtube.com is blocked while facebook.com is not blocked.
>> Both
>>> should be blocked at this time (11:58)
>>>
>>> root at mail:/opt/squid-3.5.2/etc # tail -f
>> /usr/local/squid/logs/access.log |
>>> grep DENIED
>>> 1424422669.545    456 192.168.2.2 TCP_DENIED/403 4345 GET
>>> http://youtube.com/ - HIER_NONE/- text/html
>>> 1424422671.910      1 192.168.2.2 TCP_DENIED/403 4291 GET
>>> http://youtube.com/favicon.ico - HIER_NONE/- text/html
>>>
>>> root at mail:/opt/squid-3.5.2/etc # tail -f
>> /usr/local/squid/logs/access.log |
>>> grep 192.168.2.2
>>> 1424422669.545    456 192.168.2.2 TCP_DENIED/403 4345 GET
>>> http://youtube.com/ - HIER_NONE/- text/html
>>> 1424422671.910      1 192.168.2.2 TCP_DENIED/403 4291 GET
>>> http://youtube.com/favicon.ico - HIER_NONE/- text/html
>>> 1424422710.537    863 192.168.2.2 TCP_MISS/400 372 POST
>>> http://bench.utorrent.com/e?i=36 - ORIGINAL_DST/54.221.228.66 text/html
>>> 1424422710.578    903 192.168.2.2 TCP_MISS/400 372 POST
>>> http://bench.utorrent.com/e?i=36 - ORIGINAL_DST/54.197.243.221 text/html
>>> 1424422755.202   1239 192.168.2.2 TCP_MISS/200 280 POST
>>> http://bench.utorrent.com/e?i=20 - ORIGINAL_DST/54.243.183.178 text/html
>>> 1424422756.602    846 192.168.2.2 TCP_MISS/200 1016 GET
>>> http://cdn.ap.bittorrent.com/control/feature/tags/ut.json -
>> ORIGINAL_DST/
>>> 54.230.128.
>>> 193 application/json
>>> 1424422895.279    593 192.168.2.2 TCP_MISS/404 1792 GET
>>> http://www.gstatic.com/chrome/profile_avatars/NothingToDownload -
>>> ORIGINAL_DST/196.0
>>> .3.114 text/html
>>>
>>>
>>> The odd part:
>>>
>>> While facebook.com and gmail.com are accessible, nothing appears at all
>> in
>>> the access.log and cache.log (debug mode) about them yet this is an
>>> intercept proxy. The sites just load. No log enties:(
>>
>> The browser is maybe ...
>> - not using the proxy for them at all (QUIC or WebSockets protocol), or
>>
> 
> I am using Google Chrome on Windows. Pretty vanilla Chrome so that's not
> possible.

QUIC is Googles' latest experimental protocol trying to replace HTTP. So
it more possible with Chrome visiting Google sites than on any other
traffic.


> 
>> - using a CONNECT tunnel which will only appear when its closed (HTTPS
>> SPDY, HTTP/2), or
>> - using a domain you dont have listed ("Google" services are actually
>> *.1e100.net and "Facebook" is actually *.fbcdn.net).
>>
> 
>  I see none of such entries in the logs
> 
> 
>> NP: If they are using SPDY or HTTP/2 within a CONNECT tunnel it may be
>> used for a day or so without anything appearing in the log.
>>
>>
> There I am lost completey.
> 
> 
> 
>> Check your cachemgr active_requests report to see if there is CONNECT to
>> facebook or gmail active. They may have been opened before your block
>> period and stay open into it.
>>
>>
> root at mail:/opt/squid-3.5.2/etc # /opt/squid-3.5.2/bin/squidclient -h
> localhost -p 13128 cache_object://localhost/ mgr:active_requests
> HTTP/1.1 200 OK
> Server: squid
> Mime-Version: 1.0
> Date: Fri, 20 Feb 2015 11:35:17 GMT
> Content-Type: text/plain;charset=utf-8
> Expires: Fri, 20 Feb 2015 11:35:17 GMT
> Last-Modified: Fri, 20 Feb 2015 11:35:17 GMT
> X-Cache: MISS from aardvark
> X-Cache-Lookup: MISS from aardvark:13127
> Via: 1.1 aardvark (squid)
> Connection: close
> 
> Connection: 0x809319418
>         FD 13, read 137, wrote 0
>         FD desc: Reading next request
>         in: buf 0x809c9c600, used 137, free 374
>         remote: 127.0.0.1:29252
>         local: 127.0.0.1:13128
>         nrequests: 1
> uri cache_object://localhost/active_requests
> logType TCP_MISS
> out.offset 0, out.size 0
> req_sz 137
> entry 0x80a2c3c80/7C63DF06F8D015F656D5D9CA81CF8BDE
> start 1424432117.586294 (0.000978 seconds ago)
> username -
> delay_pool 0
> 
> That's all I see....
> 

Okay. The only answer left is that the browser is NOT using the proxy.

Amos

More information about the squid-users mailing list