Dear Amos,
I was working with Eliezer with the debug_options in Squid, and with a
ALL,9 option, captured the relevant log for a request from Incognito
Chrome on client:
I am trying to understand the flow within Squid:
Line_1-7 shows that the packet was recieved
Line_8-14 "httpAccept" needs to be constructed / called
Line_16-17 confirms that httpAccept was called
Line_22-24 shows that httpAccept ended with "accept failure"
I went to the relevant lines in client_side.cc (3406-3410), and it says:
if (params.flag != COMM_OK) {
// Its possible the call was still queued when the client disconnected
debugs(33, 2, "httpAccept: " << s->listenConn << ": accept failure: "
<< xstrerr(params.xerrno));
return;
}
Does that help in anyway, or am I barking up the wrong tree?
Regards
HASSAN
On Sun, Jul 6, 2014 at 4:44 PM, Nyamul Hassan <nyamul_at_gmail.com> wrote:
> Dear Amos,
>
> Thank you for your suggestion!
>
> The browser on the client is Chrome. Interestingly, when I try to
> open any link in Chrome, it tries 3 times. But, when we try from an
> "Incognito Mode" window, it makes only one request.
>
> Morever, there are "two" routers:
> one for Host -> Rtr1 -> Squid
> another for Squid -> Rtr2 -> Internet
>
> This was done as per your advice so that we can detect loops in the
> router with rules.
>
> Please check this pastebin (all data from Rtr1):
> http://pastebin.com/fdZpHvjn
>
> * The first line is just the logging rule that we use, which is the
> same (for logic) as the routing-mark rule.
> * The number of packets that are logged by the router between
> Incognito vs Non-Incognito mode of Chrome, are different. 5 (five)
> for Incognito Mode, and 13 (thirteen) for Non-Incognito mode.
> * There are 3 (three) different source ports on client IP for
> Non-Incognito Mode, but only 1 (one) for Incognito Mode.
> * All the MAC addresses are the same.
>
> Also, the router only has "policy - routing" rules which are not
> touched between Squid TProxy, Squid Intercept, and the
> "tproxy-example" software as mentioned in an earlier email.
>
> Thank you once again for looking into this Amos!
>
> Regards
> HASSAN
>
> On Sun, Jul 6, 2014 at 4:09 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> On 2014-07-06 20:18, Nyamul Hassan wrote:
>>>
>>> Thanks for the video, Eliezer! The Mikrotik configuration part was
>>> quite interesting!
>>>
>>> New Basic Data:
>>> http://pastebin.com/ULT2d4Ej
>>>
>>> Debug (All,1 89,9 17,3)
>>> http://pastebin.com/0Ycgtea2
>>>
>>> Just one request from the client browser was made. The destination is
>>> also a server under our control. http://130.94.72.133. It is just a
>>> simple HTML file with the words "It works!"
>>
>>
>>
>> Hmm. Three TCP connections arrived at Squid.
>>
>> 2014/07/06 14:13:23.147 ... BEGIN: me/client= 130.94.72.133:80,
>> destination/me= 116.193.170.10:4246
>> 2014/07/06 14:13:23.149 ... BEGIN: me/client= 130.94.72.133:80,
>> destination/me= 116.193.170.10:4247
>> 2014/07/06 14:13:23.890 ... BEGIN: me/client= 130.94.72.133:80,
>> destination/me= 116.193.170.10:4248
>>
>> Assuming that the TPROXY was configured at the time these lines were logged
>> it appears you have a forwarding loop, probably in the router.
>>
>> One of the key things with TPROXY is that IP address based rules in the
>> router do not work. Outgoing packets from Squid appear to be coming from the
>> client, so only rules checking the interface or MAC address work properly
>> work on separate routers like the Mikrotik.
>>
>> Amos
Received on Sun Jul 06 2014 - 11:10:56 MDT
This archive was generated by hypermail 2.2.0 : Sun Jul 06 2014 - 12:00:05 MDT