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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
