| Summary: | net-proxy/c-icap-0.2.1 communication problem with net-proxy/squid-3.1.19 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Attila Tóth <atoth> |
| Component: | Current packages | Assignee: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Attila Tóth
2012-07-09 23:32:42 UTC
Uhm interesting, in my testing setup all was fine, but it's not IPv6 capable one way or the other. I'll doublecheck. (In reply to comment #1) > Uhm interesting, in my testing setup all was fine, but it's not IPv6 capable > one way or the other. I'll doublecheck. Hi Flameeyes, I disabled ipv6 for 0.2.1 to rule out any issues related to ipv6. I'm using a Hardened setup, which has just become ipv6 enabled a couple of weeks ago. Although I have ipv6 support in the kernel, I use some sysctls to disable it during boot and block all ipv6 traffic using ip6tables. The previous version of c-icap (0.1.7-r1) had no problems with that at all. As you can see despite the absence of ipv6 addresses either on the localhost or on the primary bond0 interface it still tries to use ipv6. But it was working fine. When 0.2.1 stopped working, I thought it might be because of ipv6 so I disabled it. So the previous version works with ipv6 USE enabled and kernel ipv6 sysctl disabled. But the the newer version seems to have problems even with USE=-ipv6. If you have any ideas what I should test, please let me know. Dwokfur (In reply to comment #1) > Uhm interesting, in my testing setup all was fine, but it's not IPv6 capable > one way or the other. I'll doublecheck. Additionally clamav seems to work fine. I also use its milter interface for the MTA (which happens to be sendmail). My c-icap setup is plain simple. Uses local clamav. I saw only some comments changed in the config file while bumping from 0.1.7-r1 to 0.2.1. I haven't had time to look back into it yet (will probably do in the afternoon), but did you rebuild squidclamav? It might be an ABI problem in c-icap itself :/ (In reply to comment #4) > I haven't had time to look back into it yet (will probably do in the > afternoon), but did you rebuild squidclamav? It might be an ABI problem in > c-icap itself :/ Rebuilding squidclamav in combination with the new c-icap didn't help. (In reply to comment #4) > I haven't had time to look back into it yet (will probably do in the > afternoon), but did you rebuild squidclamav? It might be an ABI problem in > c-icap itself :/ Hi flameeyes, New version of squidclamav ebuild came out: thx. I gave another try to the new icap as well in combination with the new squidclamav. I'm experiencing the same symptoms. The communication is blocked after bumping from 0.1.7-r1 to 0.2.1. The older version works well with both the current and the previous squidclamav. The new version works with neither of those. The error message is the same: Normal activity with 0.1.7-r1: 25/Jul/2012:15:49:14 +0200, ::ffff:127.0.0.1 ::ffff:127.0.0.1 REQMOD clamav 204 25/Jul/2012:15:49:14 +0200, ::ffff:127.0.0.1 ::ffff:127.0.0.1 RESPMOD clamav 204 Blocked communication with 0.2.1: 25/Jul/2012:15:53:57 +0200, ::ffff:127.0.0.1 ::ffff:127.0.0.1 OPTIONS clamav 500 25/Jul/2012:15:56:57 +0200, ::ffff:127.0.0.1 ::ffff:127.0.0.1 OPTIONS clamav 500 I thought there might be some problems with my i-cap config blocking OPTION calls. But I have no i-cap ACLs active. I also tried to follow the ebuild adivce of the exact configuration. Please let me know precisely how your config file looks like. I'd like to test it further. Regards: Dw. Sigh! they just released a fix for squidclamav — and when I checked it turns out I was connecting to a different c-icap instance. Sorry for the delay, 6.8 should work fine. |
