Re: Squid 3.1 TPROXY bugs

Anton V.G. wrote:
> Extra feedback
>
> With the load of ~20 req/sec i'm getting the following in
> the syslog. Children processes crashing?

Looks that way.

Lets analyse these in order....

>
>
> May 19 22:57:08 cacheng squid[15133]: Squid Parent: child
> process 15401 exited due to signal 6 with status 0
> May 19 22:57:11 cacheng squid[15133]: Squid Parent: child
> process 31190 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.

>
>
> On Monday 19 May 2008 21:41, Anton wrote:
>> Dear Developers,
>>
>> Just installed Linux 2.6.24 with TPROXY support and fresh
>> squid 3.1 (bzr) - TPROXY works, but there are problems
>>
>> one of several requests endup with error binding to a
>> socket, with the folloing in the syslog Would like to add
>> that I do use squid on the latent link (satellite) and
>> that may matter, since netsoket lives longer, so less
>> test needed to achieve this error:
>>
>> May 19 21:02:50 cacheng squid[26551]:
>> IPInterception.cc(136) NetfilterInterception: NF
>> getsockopt(SO_ORIGINAL_DST) failed: (11) Resource
>> temporarily unava

Expected in a TPROXY setup (this is the REDIRECT target being tested). I
still have to work out a good solution to debugging the failovers.

>> May 19 21:02:50 cacheng squid[26551]:
>> 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.

>> May 19 21:02:57 cacheng squid[26551]: commBind:
>> Cannot bind socket FD 55 to 82.198.21.17:4008: (98)
>> Address already in use

Um....

>> May 19 21:02:57 cacheng
>> squid[26551]: comm.cc(993) commResetFD: bind: (98)
>> Address already in use

Failover handler kicked in after the initial bind and it failed as well.

>> May 19 21:02:57 cacheng
>> squid[26551]: commBind: Cannot bind socket FD 55 to
>> 82.198.21.17:5407: (98) Address already in use
>> May 19
>> 21:02:57 cacheng squid[26551]: comm.cc(993) commResetFD:
>> bind: (98) Address already in use

... and the connection was retried later. These are expected until the
configured timeout occurs and an error page is given to the client. As
seen below ...

>>
>> and the corresponding site in the browser has the
>> following (until you refresh)
>>
>> ERROR
>> The requested URL could not be retrieved
>> .(skipped)
>> The system returned:
>>
>> (99) Cannot assign requested address
>>
>> Your cache administrator is webmaster.
>> Generated Mon, 19 May 2008 16:13:46 GMT by
>> (squid/3.HEAD-BZR)
>

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.

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.

Amos

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