Connection Timeout

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Connection Timeout

Tony Thompson
I am using jCIFS 1.2.7 running against Samba (YAST says
3.0.14a-0.4-suse) on a SuSE Linux server.  I am having an issue that
appears to be the same as was reported here:
http://lists.samba.org/archive/jcifs/2005-December/005786.html

I only notice it failing after the connection has been idle for a while
(like the Linux server decide my client was done and should go away).
If I retry the request after it fails, it works.  I did a packet trace
of the failed attempt and the server is responding to the SYN request
and even part of the conversation starts but then the server doesn't
appear to respond with an SMB Protocol Response packet.  I am attaching
the packet trace (hopefully it makes it).

I have never noticed this happening with a Windows server so, I am not
sure if it is a Samba or a jCIFS issue.

Tony


BTW, here is the stack trace I get from jCIFS:

jcifs.util.transport.TransportException: Connection timeout
        at jcifs.util.transport.Transport.connect(Transport.java:177)
        at jcifs.smb.SmbTransport.connect(SmbTransport.java:286)
        at jcifs.smb.SmbTree.treeConnect(SmbTree.java:129)
        at jcifs.smb.SmbFile.connect(SmbFile.java:792)
        at jcifs.smb.SmbFile.connect0(SmbFile.java:762)
        at jcifs.smb.SmbFile.send(SmbFile.java:660)
        at jcifs.smb.SmbFile.doFindFirstNext(SmbFile.java:1684)
        at jcifs.smb.SmbFile.list(SmbFile.java:1549)
        at jcifs.smb.SmbFile.list(SmbFile.java:1441)


jCIFS.cap (642 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Connection Timeout

Michael B Allen-4
On Wed, 25 Jan 2006 15:32:43 -0500
"Tony Thompson" <[hidden email]> wrote:

> I am using jCIFS 1.2.7 running against Samba (YAST says
> 3.0.14a-0.4-suse) on a SuSE Linux server.  I am having an issue that
> appears to be the same as was reported here:
> http://lists.samba.org/archive/jcifs/2005-December/005786.html
>
> I only notice it failing after the connection has been idle for a while
> (like the Linux server decide my client was done and should go away).
> If I retry the request after it fails, it works.  I did a packet trace
> of the failed attempt and the server is responding to the SYN request
> and even part of the conversation starts but then the server doesn't
> appear to respond with an SMB Protocol Response packet.  I am attaching
> the packet trace (hopefully it makes it).
>
> I have never noticed this happening with a Windows server so, I am not
> sure if it is a Samba or a jCIFS issue.

Interesting. The capture only has 5 frames in it but indeed it shows
a SYN, to which Samba responds, and then what looks like a legitimate
Negotiate from JCIFS, to which Samba does NOT respond. It wouldn't exactly
hold up in court but if it's true, I think it might be a Samba bug.

Can you temporarily increase the samba log level to see if anything
interesting is logged when Samba doesn't respond to the Negotiate?

Or if you don't feel like wearing your Sherlock Homes hat today you
might just try upgrading Samba to the latest. The Samba guys probably
won't look at the bug seriously unless you try a 3.0.20 version anyway.

Mike
Reply | Threaded
Open this post in threaded view
|

Re: Connection Timeout

Tony Thompson
In reply to this post by Tony Thompson
OK, I upgraded Samba to 3.0.20b-3.4-suse and I am still experiencing the
same issue so, I suspect this is something I need to report to the Samba
guys?  Something I have noticed is once Samba gets into this state, even
a Windows client takes a long time to get connected but, it does
connect.  Can something be done to jCIFS to make it more resilient it
this situation?

Tony

>>> Michael B Allen <[hidden email]> 01/25/06 08:19PM >>>
On Wed, 25 Jan 2006 15:32:43 -0500
"Tony Thompson" <[hidden email]> wrote:

> I am using jCIFS 1.2.7 running against Samba (YAST says
> 3.0.14a-0.4-suse) on a SuSE Linux server.  I am having an issue that
> appears to be the same as was reported here:
> http://lists.samba.org/archive/jcifs/2005-December/005786.html 
>
> I only notice it failing after the connection has been idle for a
while
> (like the Linux server decide my client was done and should go away).

> If I retry the request after it fails, it works.  I did a packet
trace
> of the failed attempt and the server is responding to the SYN
request
> and even part of the conversation starts but then the server doesn't
> appear to respond with an SMB Protocol Response packet.  I am
attaching
> the packet trace (hopefully it makes it).
>
> I have never noticed this happening with a Windows server so, I am
not
> sure if it is a Samba or a jCIFS issue.

Interesting. The capture only has 5 frames in it but indeed it shows
a SYN, to which Samba responds, and then what looks like a legitimate
Negotiate from JCIFS, to which Samba does NOT respond. It wouldn't
exactly
hold up in court but if it's true, I think it might be a Samba bug.

Can you temporarily increase the samba log level to see if anything
interesting is logged when Samba doesn't respond to the Negotiate?

Or if you don't feel like wearing your Sherlock Homes hat today you
might just try upgrading Samba to the latest. The Samba guys probably
won't look at the bug seriously unless you try a 3.0.20 version
anyway.

Mike
Reply | Threaded
Open this post in threaded view
|

Re: Connection Timeout

Michael B Allen-4
In reply to this post by Tony Thompson
On Mon, 30 Jan 2006 09:10:20 -0500
"Tony Thompson" <[hidden email]> wrote:

> OK, I upgraded Samba to 3.0.20b-3.4-suse and I am still experiencing the
> same issue so, I suspect this is something I need to report to the Samba
> guys?  Something I have noticed is once Samba gets into this state, even
> a Windows client takes a long time to get connected but, it does
> connect.  Can something be done to jCIFS to make it more resilient it
> this situation?

Mmm, this looks like a bug in Samba but it's strange that it hasn't come
up before. Are you using anything out of the ordinary like a netware
authentication backend or something?

Also, if Windows eventually connects try increasing
jcifs.smb.client.responseTimeout=300000 (5 minutes) and see if it works.

Otherwise if you can trigger the problem on demand after a fresh restart
of Samba, try to set the Samba log level to 10 and take a capture at the
same time. See if anything interesting happends at the point of failure.

Mike
Reply | Threaded
Open this post in threaded view
|

Re: Connection Timeout

Michael B Allen-4
In reply to this post by Tony Thompson
On Tue, 31 Jan 2006 08:34:05 -0500
"Tony Thompson" <[hidden email]> wrote:

> Apparently, this is just because I am testing with a slow Samba server.
> Whatever state Samba is in at that point it just seems to take longer to
> respond and jCIFS just gave up too early.  I set
> jcifs.smb.client.responseTimeout and jcifs.smb.client.soTimeout and
> everything seemed to work fine.  After I tried the 5 minute timeout you
> suggested, I backed it down to like 30 seconds and that worked as well.

Mmm, 10 seconds to respond to a negotiate request is a LONG time. But ok.

Maybe I'll bump bug the defaults for responseTimeout and soTimeout a little.

Thanks,
Mike
Reply | Threaded
Open this post in threaded view
|

Re: Connection Timeout

Michael B Allen-4
In 1.2.8 to be released RSN, the default jcifs.smb.client.responseTimeout
and jcifs.smb.client.soTimeout values have been increased from 10000
and 15000 to 30000 and 35000 respectively.

On Tue, 31 Jan 2006 15:55:48 -0500
Michael B Allen <[hidden email]> wrote:

> On Tue, 31 Jan 2006 08:34:05 -0500
> "Tony Thompson" <[hidden email]> wrote:
>
> > Apparently, this is just because I am testing with a slow Samba server.
> > Whatever state Samba is in at that point it just seems to take longer to
> > respond and jCIFS just gave up too early.  I set
> > jcifs.smb.client.responseTimeout and jcifs.smb.client.soTimeout and
> > everything seemed to work fine.  After I tried the 5 minute timeout you
> > suggested, I backed it down to like 30 seconds and that worked as well.
>
> Mmm, 10 seconds to respond to a negotiate request is a LONG time. But ok.
>
> Maybe I'll bump bug the defaults for responseTimeout and soTimeout a little.
>
> Thanks,
> Mike
>