[Samba] Re: Unusable performance over WAN (part 2)

[James Lamanna]

On 10/7/07, Doug VanLeuven <roamdad at sonic.net> wrote:
>
>  James Lamanna wrote:
>  On 10/7/07, James Lamanna <jlamanna at gmail.com> wrote:
>
>
>  On 10/7/07, Volker Lendecke <Volker.Lendecke at sernet.de> wrote:
>
>
>  On Sun, Oct 07, 2007 at 09:31:23AM -0700, James Lamanna wrote:
>
>
>
>  Server sends 1500 byte packet
> Client sends 52 bye ACK
> Server sends 1500 byte packet
> Client sends 52 byte ACK
> etc..
>
> Can anyone think of a reason for this?
>
>  I did not find a link spontaneously, but Windows sometimes
> falls back to something that we call "rabbit pellet"
> mode. Maybe google shows up something for you.
>
> Volker
>
>
>
>  I actually see that behavior using smbclient from a linux machine, so
> its not necessarily Windows related.
>
> -- James
>
>
>  I've put some tcpdump logs from my macbook up at:
> http://emagiccards.com/james/tcpdump-vpn-logs.tar.bz2.
> It contains 2 files:
>
> vpn-wan.log - Transferring a file from my macbook over the WAN (logged
> in through VPN)
> vpn-nowan2.log - Transferring a file from my macbook not over the WAN
> (logging through VPN)
> (I have separate VPN servers on each size of the WAN).
>
> Here are the smbclient outputs:
>
> No WAN:
> getting file \Jun07.xls of size 2321920 as Jun07.xls (23.8 kb/s)
> (average 23.8 kb/s)
>
> Using WAN:
> getting file \Jun07.xls of size 2321920 as Jun07.xls Short read when
> getting file \Jun07.xls. Only got 1032192 bytes.
> Error Call timed out: server did not respond after 20000 milliseconds
> closing remote file
> (3.9 kb/s) (average 3.9 kb/s
>  I notice the WAN client is negotiating an MSS of 1316 for an MTU of 1356.
> That used to be an issue with FreeSwan, but I haven't used the IPSEC
> replacements recently.
>
>  I've switched to OpenVPN which in their FAQ document several issues
> surrounding MTU size and MSS.  Most VPN providers provide similar FAQ's with
> their products.
>
>  One of the previous posts recommended changing the MTU.  That might work,
> but without knowing what kind if VPN you're using and the topology, it's
> difficult to comment intelligently.
>
>  Regards, Doug
>
>

The VPN is Cisco (PIX).
However, the VPN does not cause the issue. It just so happens that I'm
not at the office today, so VPN is the only access I have right now.
Tomorrow I'll get tcpdump traces when I'm physically on either side of
the WAN, removing VPN from the equation.

-- James