On 10/7/07, Doug VanLeuven <[EMAIL PROTECTED]> wrote: > > James Lamanna wrote: > On 10/7/07, James Lamanna <[EMAIL PROTECTED]> wrote: > > > On 10/7/07, Volker Lendecke <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
