<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: Les Mikesell <les,AT,futuresource,DOT,com>, CIPE <cipe-l,AT,inka,DOT,de>
Subject: Re: Slow file sharing performance - summary
From: James Knott <james.knott,AT,rogers,DOT,com>
Date: Sun, 14 Sep 2003 16:31:34 -0400
In-reply-to: <016b01c37afb$f51240e0$0300a8c0@futuresource.com>
References: <3F636F2E.9010203@rogers.com> <016b01c37afb$f51240e0$0300a8c0@futuresource.com>

Les Mikesell wrote:
From: "James Knott" <james.knott,AT,rogers,DOT,com>
Then some members here mentioned the "interfaces" option for Samba, which specify the connections to be supported. Using this option corrected the problem for Samba file access.


The part that I still don't understand about all this is why you have
the port 138 traffic at all. I was trying to make sense out of your
tcpdump files by observing a connection of my own between a
win2k client and a samba server and could never catch any port
138 exchange that matched the one where you were getting the
icmp response because nothing was listening on the interface. In
fact there is a firewall between these machines that would block
a server-initiated port 138 packet and it has never been a problem.
I do have a WINS server configured on the client side but I don't
see why that would affect something sent by the server.

As I mentioned in another note, I don't know enough about Samba to answer some of these questions.


NFS still does not work over dial up.


This one is probably just the transmit window exceeding a
buffer in the dial-in router.

I plan to investigate the NFS issue shortly. Some one else mentioned some options to check. Again, my knowledge of NFS is a bit weak.


Gee... Isn't networking *FUN*! ;-)

At least with Samba working, the need for NFS isn't as critical, though I would prefer to use it.

tnx jk


<< | Thread Index | >> ]    [ << | Date Index | >> ]