[jcifs] java.io.IOException: Failed to establish session

[M. D.]

Hello Adam, Mike, Everyone

Have you had any luck discovering the root cause for this issue?

I posted a few months ago on the mailing list. One of our customers suffers from exactly the same issue but we're currently not able to reproduce it on our side.
https://lists.samba.org/archive/jcifs/2014-October/010188.html
The same issue reported a long time ago by other users:
http://samba.2283325.n4.nabble.com/Failed-to-establish-session-td2512348.html#a2512349
http://samba.2283325.n4.nabble.com/IOException-at-ssn139-access-print-server-td4643959.html

I just dug up this thread and I see that you suffered from the same thing and you were able to debug it locally.
I know it was a long time ago but do you by any chance remember what was the OS of the server machine? Did you use NetBIOS with alternative names + Windows Server 2003 for the server? If that's the case then it might be related to:
http://support.microsoft.com/kb/940684

Also, do you remember any details about your environment in general? Any tips on how to reproduce that will be appreciated!

Best regards,
M.D.

[Shon Vella]

I have a customer that is seeing this exact problem. In his case it appears
that CALLED_NOT_PRESENT is a result of not being able to properly resolve
the ip address to the netbios name so we're working on making sure that the
right name is available.

With regards to M.D.'s proposed solution, it isn't quite right. ssn139()
loops through the available names for the address, so resetting the port to
445 on the first CALLED_NOT_PRESENT or NOT_LISTENING_CALLED would be
premature. It need to wait at least until the loop exit, which only happens
after all the names have been tried, though I'm not sure even there is the
right place. I think if it were me I would put the error code in a variable
outside the loop, and then if I even completed the loop, rather than throw
IOError, I would throw NbtException using that error code rather than
throwing IOError. I would than add a catch of NbtException doConnect and
handle it similarly to ConnectException and NoRouteToHostException when the
code is CALLED_NOT_PRESENT or NOT_LISTENING_CALLED. It also seems that an
invalid or incomplete nbt response (e.g. the EOF case) might be also be a
good excuse to try 445 again.

-Shon



--
View this message in context: http://samba.2283325.n4.nabble.com/java-io-IOException-Failed-to-establish-session-tp4682548p4687202.html
Sent from the Samba - jcifs mailing list archive at Nabble.com.

[Michael B Allen]

Post by Shon Vella
I have a customer that is seeing this exact problem. In his case it appears
that CALLED_NOT_PRESENT is a result of not being able to properly resolve
the ip address to the netbios name so we're working on making sure that the
right name is available.
With regards to M.D.'s proposed solution, it isn't quite right. ssn139()
loops through the available names for the address, so resetting the port to
445 on the first CALLED_NOT_PRESENT or NOT_LISTENING_CALLED would be
premature. It need to wait at least until the loop exit, which only happens
after all the names have been tried, though I'm not sure even there is the
right place. I think if it were me I would put the error code in a variable
outside the loop, and then if I even completed the loop, rather than throw
IOError, I would throw NbtException using that error code rather than
throwing IOError. I would than add a catch of NbtException doConnect and
handle it similarly to ConnectException and NoRouteToHostException when the
code is CALLED_NOT_PRESENT or NOT_LISTENING_CALLED. It also seems that an
invalid or incomplete nbt response (e.g. the EOF case) might be also be a
good excuse to try 445 again.

I think the best solution would be to just add a
jcifs.smb.client.port139.enabled property which defaults to false and
causes the connection op to throw an exception instead of trying to
failover to 139.

I don't think there any any legit servers using port 139 anymore. It
was relevant 15 years ago when some old networks had not quite opened
up port 445. I don't want to mess with trying to account for the
various race conditions surrounding the port 139 failover logic.

Mike