Bug 2857 - ConnectException handled instead of SocketException
ConnectException handled instead of SocketException
Status: RESOLVED FIXED
Product: jCIFS
Classification: Unclassified
Component: core
1.2
x86 Windows 2000
: P3 normal
: ---
Assigned To: Michael B. Allen
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-07 00:57 UTC by Erik Bongers
Modified: 2005-11-14 09:43 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Bongers 2005-07-07 00:57:20 UTC
Hi,

This is a post about the jcifs-1.2.1 library. If the post is for the wrong 
product/version, I'm sorry. I couldn't find the correct classification for this 
(possible) bug.

In short : the jcifs-1.2.1 NTLM filter works on Tomcat but fails on Weblogic.
In detail :
I believe that at startup, the jcifs-1.2.1 NTLM filter tries to connect to 3 
possible ports on the domain controller server: 0, 139 and 445.
A ConnectException is 'catch-ed' for each attempt.

With tomcat4.1/jre 1.4.2, a ConnectException is indeed thrown and handled, but 
BEA Weblogic 7.0 throws a SocketException ! (see stack trace below)

I replaced the ConnectException with SocketException in the code 
(jcifs.smb.SmbTransport.java, method doConnect, line 274) and all works fine 
now.

I also reviewed sun's doc on the Socket constructor and it can throw an 
IOException, so even my change won't cover all possible Exceptions.

I'm going to continue to work with my own fix, but if it's wrong, I would 
appreciate if you could let me know. Otherwise I assume that this will get 
fixed in a next release and will use my own patch until then.

Thank you !

Erik Bongers
mailto:ebongers@gcobe.jnj.com

ps. here's the stack trace, and furhter down is the change I made.

jcifs.smb.SmbException: 
jcifs.util.transport.TransportException
java.net.SocketException: errno: 227, error: Can't assign requested address for 
fd: 94
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.PlainSocketImpl.doConnect(Unknown Source)
	at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
	at java.net.PlainSocketImpl.connect(Unknown Source)
	at java.net.Socket.<init>(Unknown Source)
	at java.net.Socket.<init>(Unknown Source)
	at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:234)
	at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:273)
	at jcifs.util.transport.Transport.run(Transport.java:204)
	at java.lang.Thread.run(Unknown Source)

	at jcifs.util.transport.Transport.run(Transport.java:220)
	at java.lang.Thread.run(Unknown Source)

	at jcifs.smb.SmbTransport.connect(SmbTransport.java:263)
	at jcifs.smb.SmbSession.getChallenge(SmbSession.java:136)
	at jcifs.smb.SmbSession.getChallenge(SmbSession.java:130)
	at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:157)
	at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
	at weblogic.servlet.internal.FilterChainImpl.doFilter
(FilterChainImpl.java:27)
	at 
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run
(WebAppServletContext.java:5451)
	at weblogic.security.service.SecurityServiceManager.runAs
(SecurityServiceManager.java:780)
	at weblogic.servlet.internal.WebAppServletContext.invokeServlet
(WebAppServletContext.java:3105)
	at weblogic.servlet.internal.ServletRequestImpl.execute
(ServletRequestImpl.java:2588)
	at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
	at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)

**************************************************************
Changed in SmbTransport.java at line 274 :

        try {
            negotiate( port, resp );
        } catch( SocketException ce ) { // changed from ConnectException !
            port = port == 445 ? 139 : 445;
            negotiate( port, resp );
        }
Comment 1 Gerald (Jerry) Carter 2005-07-07 05:09:05 UTC
the ntlm_auth component is for Samba's ntlm_auth command 
line tool.  I'm checkin with Mike Allen about how he wants to
handle jCIFS bug reports.
Comment 2 Gerald (Jerry) Carter 2005-07-08 06:07:08 UTC
reassigning to Mike.
Comment 3 Michael B. Allen 2005-07-08 11:07:48 UTC
Thanks Gerald.

This is indeed a bug. I'll take a look.

Mike
Comment 4 Michael B. Allen 2005-07-18 12:29:36 UTC
It looks like this occurs because new Socket is being called with a localAddr of
InetAddress.getLocalAddress() and there are some versions of Java and/or Linux
that are not happy with this.

A workaround is to set jcifs.smb.client.laddr to the IP address of the network
interface.

The solution is to fix the broken Java and/or Linux that does not like 127.0.0.1
for the localAddr parameter w/ the Socket constructor.

An internal solution would be to add a clause to SmbTransport.java:178 and 228
that does not use the 4 parameter constructor if localAddr ==
InetAddress.getLocalHost().
Comment 5 Michael B. Allen 2005-08-19 13:23:21 UTC
(In reply to comment #4)
> It looks like this occurs because new Socket is being called with a localAddr of
> InetAddress.getLocalAddress() and there are some versions of Java and/or Linux
> that are not happy with this.

This is fixed in 1.2.2.

Actually this is not really a bug in the OS or Java implementation.
InetAddress.getLocalAddress is returning what the local DNS implementation is
providing. No matter, 1.2.2 does not query getLocalAddress at all - it uses the
two parameter Socket constructor if jcifs.smb.client.laddr was not specified.