Bug 450730 – net-proxy/squid-3.1.22 vs net-proxy/squidclamav-6.10 vs net-proxy/c-icap-0.2.4 problems

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Attila Tóth 2013-01-07 18:08:43 UTC]

net-proxy/squid-3.1.19 + net-proxy/squidclamav-6.10 + net-proxy/c-icap-0.2.4 combo works OK on my server for clamav.
I have constant problems while upgrading to net-proxy/squid-3.1.22.
It says: ICAP protocol error [No Error].
The c-icap logs are plain empty.
Squid says 500 and 407 in its logs.

In 3.1.19 helpers default to ipv4. I suspect based on the config file, that in 3.1.22 it tries ipv6 and falls back to ipv4. On my system I keep ipv6 disabled and the whole machine doesn't have an ipv6 address. I cannot make squid completely forget about ipv6 - no matter what I try. So far it worked fine, but recently I started blming ipv6 for the lack of communication with c-icap.
It gets even worth with squid versions above 3.2. It complains about my manager and localhost settings. Of course I have a localhost setting ipv4 only. If I remove the line to let the daemon use its builtin one, it start tampering with ipv6 for sure.
There is another chance by using squid+libecap+clamav-adapter. The clamav adapters and the whole ecap stuff overall are terribly under documented currently. (Not that icap with squidclamav would be well documented at all).

Anybody using squid 3.1.22+ or 3.2.x+ with c-icap+squidclamav or libecap+clamav-adapter on gentoo please let me know how to do it.

It's disappointing to see how thing gets worse instead of evolving.
At least there's a working combination of: net-proxy/squid-3.1.19 and net-proxy/squidclamav-6.10 and net-proxy/c-icap-0.2.4. Where should I go now?
Other alternatives are also very wellcome to replace the combo like I don't know for e.g dansguardian. However I already have content filtering using a chained net-proxy/privoxy instance. Apart from virus scanning it's fine. I like it.

Reproducible: Always

[Comment 1 Eray Aslan 2013-01-08 07:35:10 UTC]

Couple of notes: 

* Concentrate on squid-3.2 versions.  The network stack was more or less rewritten wrt ipv6 connectivity in squid-3.2.  In other words, if you find a solution for squid-3.1, it is not guaranteed that it will work for squid-3.2 as well.
* Squid auto detects ipv6 on startup and it works fine AFAIK (see if disabling ipv6 completely in your kernel helps)
* Try dns_v4_first on in your squid.conf
* Try tcp_outgoing_address 0.0.0.0 to force sockets to be ipv4-only
* Try decreasing forward_max_tries value to see if there is a timeout because of your DNS settings
* Try the following patch which prevents ipv6 results from being used for ipv6-disables hosts (for squid-3.2).  In general, make sure your DNS does not return any ipv6 responses.
http://treenet.co.nz/projects/squid/patches/Hanzlik_crash_s32_mk1.patch
* Try implementing rudimentary ipv6 (yeah, I know)
* Contact upstream

[Comment 2 Attila Tóth 2013-01-08 12:01:38 UTC]

(In reply to comment #1)
Thanks for spending time on your reply.

> * Concentrate on squid-3.2 versions.  The network stack was more or less
> rewritten wrt ipv6 connectivity in squid-3.2.  In other words, if you find a
> solution for squid-3.1, it is not guaranteed that it will work for squid-3.2
> as well.

I'm pretty sure it won't just work.

> * Squid auto detects ipv6 on startup and it works fine AFAIK (see if
> disabling ipv6 completely in your kernel helps)

Complete disable now causes other problems, so I just soft disable it.

> * Try dns_v4_first on in your squid.conf

I keep it on for a long time now.

> * Try tcp_outgoing_address 0.0.0.0 to force sockets to be ipv4-only

I dig into this.

> * Try decreasing forward_max_tries value to see if there is a timeout
> because of your DNS settings
> * Try the following patch which prevents ipv6 results from being used for
> ipv6-disables hosts (for squid-3.2).  In general, make sure your DNS does
> not return any ipv6 responses.
> http://treenet.co.nz/projects/squid/patches/Hanzlik_crash_s32_mk1.patch

The daemon is crashing, so I give the patch a try or also propagate it further.

> * Try implementing rudimentary ipv6 (yeah, I know)
> * Contact upstream

I've also found HAPV and give it a try. However the last update happened long ago.

Regards: Dw.

[Comment 3 Michał Górny 2018-12-04 17:07:30 UTC]

Removing wrt #556306.