From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 9E9271381F3 for ; Sat, 24 Aug 2013 17:25:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 30DE3E0C17; Sat, 24 Aug 2013 17:25:35 +0000 (UTC) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 11385E0ABE for ; Sat, 24 Aug 2013 17:25:33 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id j13so2626019wgh.5 for ; Sat, 24 Aug 2013 10:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=i3ktfBOWtKC4UBbDLqP/L99nr+RkzjnX51Tzx7cr748=; b=0NapOWtV7bjUpoVf4grL4IfkvFPjhdrRJKBReIbIbCLUCYsQwRzCSZ9jA/6EI7/b3i 4dzsKg9OR7JbiBLL8CoHLigTT5H985maKu+ByqzC6f4Njlf36jkRtMIIh5fm0t9hp4A4 PTl0PhFy/20xqiTrwUl8xTyfz8C1+R4Ril1gLHnS3TZN0vO7euXi5FaK7lZ1t8VgZ6c9 GzjROn1omHxBkYj0XY4LUYvia3o+jjK9FfAPmuLEYrAgsBf4XF1GTSAvhBaZ5Vc8qDXg WIvfEV/wdmqcYAyLplEgHWt+VC+WJGT6/u46miZg/94bh4j7rAjukfWC0rVU6XUQWOJB LY3w== X-Received: by 10.194.175.133 with SMTP id ca5mr3945308wjc.19.1377365132698; Sat, 24 Aug 2013 10:25:32 -0700 (PDT) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPSA id i5sm5522615wiw.7.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 10:25:31 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Proxy server problem Date: Sat, 24 Aug 2013 18:25:00 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.7-gentoo; KDE/4.10.5; x86_64; ; ) References: <201308241122.25525.michaelkintzios@gmail.com> In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2541527.V9lm2XnUIu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201308241825.15336.michaelkintzios@gmail.com> X-Archives-Salt: d4329773-0608-4ce4-9781-ddecfb315e7f X-Archives-Hash: d1e53e7faeddd8dbcbd69af8f07bab78 --nextPart2541527.V9lm2XnUIu Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Saturday 24 Aug 2013 14:23:26 Grant wrote: > >> 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. > >>=20 > >> http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs-t= he > >> -en tire-system-td4660893.html > >>=20 > >> Can anyone here help me figure out what is wrong? I'm not sure where = to > >> start. > >>=20 > >> - Grant > >=20 > > 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. >=20 > 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? >=20 > - Grant Now that you mentioned using ssh, I don't think that you can improve this. = An=20 mtu at 1000 bytes is lower than I thought might have helped. The problem i= s=20 caused by stacking tcp packets (tcp within tcp) each of which is using its = own=20 timeout for failed fragments. 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= =20 know this might work in a real world use case. You can experiment with=20 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= =20 different tunnel method. A network layer VPN, like IPSec (you can use=20 StrongSwan which also offers IKEv2 and MOBIKE for your laptop, or ipsec-too= ls=20 with racoon for IKEv1 only) should work without such problems. You will be= =20 tunnelling tcp in udp packets. If you tunnel to your home router you will= =20 need to configure an IPSec tunnel mode connection, otherwise you would use = an=20 IPSec transport mode connection directly to your server after you allow IP= =20 protocol 50 packets through your router. HTH. =2D-=20 Regards, Mick --nextPart2541527.V9lm2XnUIu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAABAgAGBQJSGOx7AAoJELAdA+zwE4YeiUEIAIXu+S3LlB6brXtOl/w9B60x bZbq0OGCXWIoLY3laIzrdq5ZL4qawqFR+BlIed+qTBGm6MxuiKrnj7Qffxe+suI5 uREbc9bid6+C0jId/lEGejMfwDeqxsiwu8fDIgdQCTmOykkY2eykdVjor5HC61SC IJXAsJQJs+n5XVTBSrOX7HN0FC7kQaKDzVQL2Q0qg6cAsOH4zbIu4estwJgOMvMF 5mffGw/AhNajvcyrFz31hiXkfnLE3LJ7hGqKOaudrb+QslvIabdUCAMX3bBp5zXK 0X661d/D3kweSlKgnZcmfS4TPOje9df3qHVA+kstndajLRLkGPkz+JFj09MB/Ss= =R5wj -----END PGP SIGNATURE----- --nextPart2541527.V9lm2XnUIu--