|Summary:||net-proxy/squid-3.1.22 vs net-proxy/squidclamav-6.10 vs net-proxy/c-icap-0.2.4 problems|
|Product:||Gentoo Linux||Reporter:||Attila Tóth <atoth>|
|Component:||Current packages||Assignee:||Eray Aslan <eras>|
|Package list:||Runtime testing required:||---|
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.