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: http://pastebin.com/WWYpxceG 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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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
