>> >> I set up squid on a remote system so I can browse the internet from >> >> that IP address. It works but it stalls frequently. I had similar >> >> results with ziproxy. I went over this with the squid list but we got >> >> nowhere as it seems to be some kind of a system or network problem. >> >> >> >> http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs-the >> >> -en tire-system-td4660893.html >> >> >> >> Can anyone here help me figure out what is wrong? I'm not sure where to >> >> start. >> >> >> >> - Grant >> > >> > Just a quick pointer in case it applies to you: if you tunnel into the >> > proxy machine (using ssh, VPN, proxychains and what not) you would >> > suffer from packet fragmentation, which could quickly snowball. In this >> > case try reducing your mtu to lower values, than the default ethernet >> > 1500 byte packets, to cater for the overhead of the larger tunnelling >> > headers. >> >> I've tried disconnecting from my SSH tunnel and changing the mtu on my >> laptop and on the remote proxy server via ifconfig and there is some >> kind of an improvement but I can't narrow it down. I've tried mtu >> down to 1000 on both systems but the proxy server still stalls >> sometimes. Any tips for narrowing this down further? >> >> - Grant > > Now that you mentioned using ssh, I don't think that you can improve this. An > mtu at 1000 bytes is lower than I thought might have helped. The problem is > caused by stacking tcp packets (tcp within tcp) each of which is using its own > timeout for failed fragments.
I think I may have misunderstood you. I do SSH into the machine running squid, but I don't tunnel through that connection in order to use the proxy. I connect to the remote squid instance directly via my browser and I also happen to SSH into the same machine to run commands. Do any of your recommendations apply in this scenario? - Grant > The problem is explained here (tcp meltdown): > > http://sites.inka.de/~W1011/devel/tcp-tcp.html > > and here (useful relevant references to other works are also made): > > http://publications.lib.chalmers.se/records/fulltext/123799.pdf > > > There are some suggested solutions like increasing buffer size, but I don't > know this might work in a real world use case. You can experiment with > different buffer sizes as suggested here and see if it makes a difference: > > http://www.cyberciti.biz/faq/linux-tcp-tuning/ > > > If the interruptions are not acceptable to you, you could consider using a > different tunnel method. A network layer VPN, like IPSec (you can use > StrongSwan which also offers IKEv2 and MOBIKE for your laptop, or ipsec-tools > with racoon for IKEv1 only) should work without such problems. You will be > tunnelling tcp in udp packets. If you tunnel to your home router you will > need to configure an IPSec tunnel mode connection, otherwise you would use an > IPSec transport mode connection directly to your server after you allow IP > protocol 50 packets through your router.
