Apple OS X SMB issues across VPN
dan at orourke.ca
Thu Oct 20 20:14:20 GMT 2005
On Oct 20, 2005, at 12:39 PM, Christopher R. Hertel wrote:
>> I'll plead ignorance here. I have no idea what the difference is or
>> how to find out.
I had this explanation given to me:
> it's basically whether the filesystem request packets are wrapped
> in the old NetBIOS
> headers. NBT transport is on port 139 while the naked CIFS is on
> 445. Sadly
> Windows will often try *both* and use whichever socket connects
> first. You
> can check how things are connected on OS-X with:
> netstat -an |grep 139 ; netstat -an |grep 445
xserve:~ admin$ netstat -an |grep 139 ; netstat -an |grep 445
tcp4 0 0 192.168.0.2.139 192.168.0.158.3183
tcp4 0 0 192.168.0.2.139 192.168.2.178.1381
tcp4 0 0 192.168.0.2.139 192.168.0.131.1029
tcp4 0 0 *.139 *.*
tcp4 0 0 192.168.0.2.445 192.168.0.190.1061
tcp4 0 0 *.445 *.*
192.168.0.2 is my Xserve running Samba.
> If the traffic is untouched, that's good (and the configuration you
> describe should still provide data protection).
> I assume that the firewall systems are routing traffic between them
> all appears transparent to the machines on the local networks
> Do all of the clients point to the Xserve as their WINS server?
> Actually, that shouldn't be the source of the problem since you are
> getting access to the shares. As I recall, the problem was incredible
> slowness once connected. File transfers (reads and writes) were
> okay, but
> directory listing was very slow. Is that right?
Yes that is the problem exactly. The local LAN 192.168.0.* is fine
but the VPN LAN 192.168.2.* is awful. They can see the shares but
directory listings / transfers are unusable.
>>> - Can you capture a trace for us?
>> I did this once before... I can't recall the procedure on unix.
> There should be a MacOSX port of Ethereal or tcpdump...
tcpdump is standard on OS X but I'm at a loss as to which CLI options
I need to add to get the data you are looking for.
More information about the samba-technical