[linux-cifs-client] Re: [samba@cleanh2o.com: [Samba] cifs problems with multiple linux boxes hitting W2K shares, cifs-1.20c-2.4, linux 2.4.27 kernel]

[Joe]

I brought up a new server behind the firewall and cifs mounted the
windows shares on port 445. The machine is independent of our lvs.
Windows does see both machines as the same IP address. The shares
are cifs mounted as the same user.

When I copied files across the cifs the cifs mount complained and
the other machine with cifs mounts also complained. I've sent a
file of tcpdump -s256 taken during some of the copy, on the machine
that was copying, to Steve French + Jeremy Allison in a separate email
(don't want to clutter the list with it).
If it would help to do the tcpdump on the firewall I could do that too.

There were intermittent errors thrown like:
cp: reading `/mnt/.../test/image/64b-286a.JPG': Resource temporarily unavailable
 CIFS VFS: Send error in read = -11
 CIFS VFS: No response buffer
 CIFS VFS: No response buffer
 CIFS VFS: Send error in SessSetup = -11
on the machine that I did the tcpdump on.

and on the other - which ran fine before and after this exercise:
 CIFS VFS: Send error in read = -11
 CIFS VFS: No response buffer
 CIFS VFS: Error -104 sending data on socket to server.
 CIFS VFS: Send error in read = -104
 CIFS VFS: Error -32 sending data on socket to server.
 CIFS VFS: Send error in Close = -32

I then mounted cifs on port 139, using no netbiosname, on two machines
behind the firewall and did the same test copy a few times (>200MB of
images.) No problem. dmesg was clean. It looks like port 139 does act
differently than 445. I'm tempted to speculate why but I'll leave that
to you for now.

Thanks, Joe


On 20 Oct 2004, Steve French wrote:
> Some fixpacks (?) of Windows servers had a bug/feature in which they
> would close existing tcp sessions from clients that appeared to be
> coming from the same source ip address (which would be the case if both
> client machines were behind a Network Address Translator for example)
> this could cause frequent reconnections.  There may be other more
> obvious explanations (an ethereal trace or binary tcpdump trace (tcpdump
> -w savefilename -s256) of the session reconnection storm would be more
> helpful)
>
> I don't remember off hand whether the 1.20c version of the code handled
> the mount parm (after -o) of "netbiosname=SOMEMCNENAME" e.g (I don't
> have any systems easily bootable to 2.4 kernel at the moment - they all
> run 2.6 around here most of the time) and the netbiosname does not
> really matter if you are using the default port (445) as that does not
> use it but certainly more recent versions of the code allow you to
> override the port (on mount after -o) with port=139.
>