Re: [squid-users] got some debugging logs

>> section 17 show abnormail thing:
>> (the outgoing address to the server is the client address and not one
>> of the server address)
>>
>> 2012/01/06 04:28:36.782| store_client::copy:
>> 7DEA6A0583B90AB461F576C6AEE4AA50, from 0, for length 4096, cb 1,
>> cbdata 0x882b5b8
>> 2012/01/06 04:28:36.783| storeClientCopy2:
>> 7DEA6A0583B90AB461F576C6AEE4AA50
>> 2012/01/06 04:28:36.784| store_client::doCopy: Waiting for more
>> 2012/01/06 04:28:36.785| FwdState::start() 'http://link
>> 2012/01/06 04:28:36.787| fwdStartComplete: http://link
>> 2012/01/06 04:28:36.789| fwdConnectStart: http://1link
>> 2012/01/06 04:28:36.791| fwdConnectStart: got outgoing addr
>> 192.168.102.100, tos 0
>
> "outgoing addr" is the address Squid assigns to its end of the
> squid->server connection. This appears to be correct for TPROXY.
>
>> 2012/01/06 04:28:36.791| fwdConnectStart: got TCP FD 13
>>
>>
>> so the main problem is that the request that comes from squid is not
>> using the right address in tproxy mode.
>>
>> Thanks
>> Eliezer
>>
>>
>>
>>
>> On 05/01/2012 17:20, Eliezer Croitoru wrote:
>>> i made a squid url_rewriter for cache purposes and it works on ubunut
>>> and on fedora 16(i686).
>
>>> also it works on fedora 15 with the 3.2.0.12 rpm from fedora 16 repo.
>>> the problem is that when the re_rewriter is replying with the address to
>>> squid the session that squid is creating is : from the client to the
>>> server instead from the squid machine to the web server.
>>> what is see using ss is:(tproxy is port 8081)
>>> SYN-SENT 0 1 192.168.102.100:38660 192.168.102.3:tproxy
>
> I'm unclear what this is and what you mean by "squid session". I assume
> that is the details Squid sent to the helper?
> If so that is a second strong sign of the loop mentioned below.
>
>>>
>>> but using the 3.2.0.12 and on other systems i see from
>>> 192.168.102.3:high_port_number 192.168.102.3:tproxy
>>> or
>>> 127.0.0.1:hight_port_number 127.0.0.1:tproxy
>>>
>>> and everything works fine.
>
> Er, this looks like the TPROXY looping traffic like so:
>
>
> Client --(TPROXY)> ... Internet
> . |
> \..... Squid --> Rewriter --(TPROXY)> ... Internet
> | \-------<<--------|
> |
> \---> Internet

well i do know how tproxy works and
the redirected address is 127.0.0.1 on ports other then the tproxy.
on the squid 3.2 branch it dosnt happens.
by the way the rewriter makes it without sending headers to the client
and it shouldnt bind 127.0.0.1 adress to access the localhost.
it's not a tproxy issue because it works on the 3.2 branch and also
there is no trace for the looping in the log.
the log shows two different requests just to show the concepts of the
problem.
as i mentioned tproxy works on http (port 80) and the tproxy target
mentioned in ss is port 8081 so this is not looping but something in
squid while getting the file from the server.

Thanks
Eliezer

>
>
> Because, the re-writer is not sending its background fetch requests out
> of a socket the kernel has marked as Squids for TPROXY. It needs Squid
> or the rewriter to bypass the rewriter fetch if the request was coming
> from the re-writer on a Squid IP (or, localhost). Or to byass TPROXY
> globally traffic generated internally by the Squid box.
>
>>>
>>> the rewritter has a log function build-in and only when it's redirecting
>>> and with tproxy squid is doing this thing.
>>> on regular forward proxy everything is working fine.
>>>
>>> my config is the basic one with the exception of tproxy and the
>>> rewritter
>>>
>>> #start lines added
>>> http_port 3129 tproxy
>>> url_rewrite_program /opt/nginx.cache.rb
>>> url_rewrite_host_header off
>
> If the domain is being changed in the URL Host: header re-writing ON is
> critical if the traffic is going back to a tproxy or intercept port.
> Given the above loop is likely, this could be the problem.
>
>>> #end lines added
>>>
>>> so : with the 3.2 branch it works but not on 3.1.(3.1.10-3.1.18)
>>>
>>> also i cant compile the 3.2 branch on fedora 15 cause always it ends up
>>> with some error.
>>> i need to know the list of dependencies for compilation.
>
> Your guess is as good as mine. It is specific to the features you are
> building. The official Fedora RPM or its documentation should be a good
> guideline for what Fedora packages are related or needed.
>
>>> i had some sasl problem and i installed the sasl dev libs but now its
>>> stuck on ftp error:
>>> g++: warning: switch ג-fhuge-objectsג is no longer supported
>>> ftp.cc: In function גvoid ftpReadEPSV(FtpStateData*)ג:
>>> ftp.cc:2371:9: error: variable גnג set but not used
>>> [-Werror=unused-but-set-variable]
>>> cc1plus: all warnings being treated as errors
>
> Aha. That was fixed as part of a later update. There was a missing
> condition in the if() statement around line 2440. The code there should
> contain the following, with line 2371 the definition of "int n;" moved
> down as shown:
>
> char h1, h2, h3, h4;
> unsigned short port;
> int n = sscanf(buf, "(%c%c%c%hu%c)", &h1, &h2, &h3, &port, &h4);
>
> if (n < 4 || h1 != h2 || h1 != h3 || h1 != h4) {
> debugs(9, DBG_IMPORTANT, "Invalid EPSV reply from " <<
>
>
> Amos
Received on Fri Jan 06 2012 - 05:46:07 MST