Re: Squid 3.1 TPROXY bugs

Anton VG wrote:
> 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?

Sounds good for the trace. For cache.log at least:
   debug_option ALL,1 85,9

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

FWIW: COSS in 3.x is known to have bugs. But thats another issue.

I normally run with the gdb commands file containing:

"
set args -ND -f /src/test/squid.conf
file /usr/local/squid/sbin/squid
# handle all nostop print
handle SIGPIPE pass nostop noprint
handle SIGSEGV stop
handle SIGABRT stop
run
backtrace
"

the handle lines are important to tell gdb to ignore the signals squid
sends itself at times.

If you use this, you may need to add the break commands to stop it at
the desired places.

>
> 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
>>

-- 
Please use Squid 2.6.STABLE20 or 3.0.STABLE5