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 ); }
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.
reassigning to Mike.
Thanks Gerald. This is indeed a bug. I'll take a look. Mike
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().
(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.