Re: Squid 3.1 TPROXY bugs

Will try it now... already compiling.

btw, just looking at the debugging options - i'm going to compile
squid with the following options:

./configure --prefix=/usr/local/squid31trunk --enable-snmp
--enable-storeio=coss,ufs,aufs --enable-coss-aio-ops --with
-coss-membuf-size=10485760 --with-large-files --with-maxfd=65535
--enable-linux-netfilter --disable-optimizations --di
sable-inline --enable-debug-cbdata

would this be ok to compile enough debug info, or you would suggest
something else?

I'm going to attach to a process by gdb and see when it dies,

Any suggestions?

2008/5/20 Amos Jeffries <squid3_at_treenet.co.nz>:
> Anton VG wrote:
>>
>> Dear Amos,
>>
>> Thank you for reply!
>>
>> 2008/5/20 Amos Jeffries <squid3_at_treenet.co.nz>:
>>>
>>> Anton V.G. wrote:
>>>>
>>>> Extra feedback
>>>>
>>>> started
>>>
>>> This one does appear to be a fatal condition occuring. If you can track
>>> it
>>> in gdb or such debugger and get a stack trace of where its happening that
>>> would be a great help.
>>
>> Can we force it to generate a core? If not, I'll try to debug it.
>>
>>>>> IPInterception.cc(169) NetfilterTransparent: NF
>>>>> getsockopt(IP_TRANSPARENT) failed: (92) Protocol not
>>>>> available
>>>
>>> This is bad. It means the TPROXY target is not working in your kernel.
>>> That said squid should at least be handling it well.
>>
>> It working, but partially, it gives this notice once in ~20 requests,
>> seems normal requests is in the access.log
>>
>
> Thats normal 'failure' behaviour. Squid has a semi-quiet counter to suppress
> a most of those transparency errors so the log does not fill up too quickly.
> If its happening that often its safe to assume its always failing.
>
>>> The only unexpected behaviour there is that the first bind failed with
>>> the
>>> error it gave.
>>>
>>> Only you are in a position to say if 82.198.21.17:4008 was the squid
>>> IP:random-port or if it somehow got the client IP and failed when using
>>> that.
>>
>> It means it really tries to occupy the same port as the user connection?
>
> It should be using another random out port I think. Which gives me an idea
> of whats going on.
>
> Does the bind issue disappear if you make this change:
>
> === modified file 'src/IPInterception.cc'
> --- src/IPInterception.cc 2008-04-11 03:33:42 +0000
> +++ src/IPInterception.cc 2008-05-20 15:47:17 +0000
> @@ -176,6 +176,9 @@
>
> dst.FreeAddrInfo(lookup);
>
> + /* ignore the port returned in dst. We won't be re-using that exact
> one. */
> + dst.SetPort(0);
> +
> if(me != dst) {
> debugs(89, 5, HERE << "address: " << dst);
> return 0;
>
>>
>>> We first need to determine if 82.198.21.17:4008 was valid, and why its
>>> being
>>> used.
>>>
>>> If you are up for some code delving we can work this out.
>>
>> I'll happily do what required! Just need to be guided a little.
>> If more rapid communication is needed I'm available at google jabber
>> (the same email) or ICQ 38119392
>>
>
>
> Amos
> --
> Please use Squid 2.6.STABLE20 or 3.0.STABLE5
>
Received on Tue May 20 2008 - 16:03:18 MDT