[jcifs] Re: 1.2.4 NameQueryRequest fails in OC4J on AIX (1.1.11 works)

[Oliver Schoett]

I now have tcpdump on the test machine and solved the WINS problem: the 
domain which I have created for testing is not contained in our 
production WINS servers.  Directly using the test domain server als WINS 
server works, and I can now use jCIFS 1.1.11 successfully (where 
previously, I was stuck with 0.8.3).  I will test 1.1.11 at the client 
site, where the WINS servers produce domain server lists with bad 
entries (IP numbers of the form 10.x.y.z for which no host exists at all).

However, despite putting local network addresses into the config, jCIFS 
1.2.4 still fails.  The config is

    <filter>
        <filter-name>NTLM HTTP Authentication Filter</filter-name>
        <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
        <init-param>
            <param-name>jcifs.smb.client.domain</param-name>
            <param-value>KVMADS</param-value>
        </init-param>
        <init-param>
            <param-name>jcifs.netbios.wins</param-name>
            <param-value>183.112.182.2</param-value>
        </init-param>
        <init-param>
            <param-name>jcifs.netbios.baddr</param-name>
            <param-value>183.112.183.255</param-value>
        </init-param>
        <init-param>
            <param-name>jcifs.netbios.laddr</param-name>
            <param-value>183.112.180.65</param-value>
        </init-param>
        <init-param>
            <param-name>jcifs.smb.client.laddr</param-name>
            <param-value>183.112.180.65</param-value>
        </init-param>
    </filter>

and the exception is the same as I reported before:

    NameQueryRequest[nameTrnId=1,isResponse=false,opCode=QUERY,isAuthAnswer=false,isTruncated=false,isRecurAvailable=false,isRecurDesired=true,isBroadcast=false,resultCode=0,questionCount=1,answerCount=0,authorityCount=0,additionalCount=0,questionName=KVMADS<1C>,questionType=0x0020,questionClass=IN,recordName=null,recordType=0x0000,recordClass=0x0000,ttl=0,rDataLength=0]
    00000: 00 01 01 00 00 01 00 00 00 00 00 00 20 45 43 46  |............ ECF|
    00010: 47 45 4C 45 42 45 45 46 44 43 41 43 41 43 41 43  |GELEBEEFDCACACAC|
    00020: 41 43 41 43 41 43 41 43 41 43 41 42 4D 00 00 20  |ACACACACACABM.. |
    00030: 00 01                                            |..              |

    NetBIOS: new data read from socket
    NameQueryResponse[nameTrnId=1,isResponse=true,opCode=QUERY,isAuthAnswer=true,isTruncated=false,isRecurAvailable=false,isRecurDesired=true,isBroadcast=false,resultCode=0,questionCount=0,answerCount=1,authorityCount=0,additionalCount=0,questionName=null,questionType=0x0000,questionClass=IN,recordName=KVMADS<1C>,recordType=0x0020,recordClass=IN,ttl=300000,rDataLength=6,addrEntry=[Ljcifs.netbios.NbtAddress;@298bf137]
    00000: 00 01 85 00 00 00 00 01 00 00 00 00 20 45 43 46  |............ ECF|
    00010: 47 45 4C 45 42 45 45 46 44 43 41 43 41 43 41 43  |GELEBEEFDCACACAC|
    00020: 41 43 41 43 41 43 41 43 41 43 41 42 4D 00 00 20  |ACACACACACABM.. |
    00030: 00 01 00 04 93 E0 00 06 80 00 C1 66 B6 02        |.....à....Áf¶.  |

    Failed validate DC: KVMADS<1C>/183.112.182.2
    jcifs.smb.SmbException: 
    jcifs.util.transport.TransportException
    java.net.NoRouteToHostException: The socket name is not available on this system.
	    at java.net.PlainSocketImpl.socketConnect(Native Method)
	    at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:329)
	    at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:194)
	    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:181)
	    at java.net.Socket.connect(Socket.java:459)
	    at java.net.Socket.connect(Socket.java:409)
	    at java.net.Socket.<init>(Socket.java:315)
	    at java.net.Socket.<init>(Socket.java:197)
	    at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:235)
	    at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:274)
	    at jcifs.util.transport.Transport.run(Transport.java:213)
	    at java.lang.Thread.run(Thread.java:568)
	    at jcifs.util.transport.Transport.run(Transport.java:229)
	    at java.lang.Thread.run(Thread.java:568)
	    at jcifs.smb.SmbTransport.connect(SmbTransport.java:264)
	    at jcifs.smb.SmbSession.interrogate(SmbSession.java:74)
	    at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:111)
	    at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150)
	    at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
	    at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:604)
	    at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317)
	    at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
	    at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:208)
	    at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:125)
	    at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
	    at java.lang.Thread.run(Thread.java:568)
    java.net.SocketTimeoutException: Receive timed out
	    at java.net.PlainDatagramSocketImpl.receive(Native Method)
	    at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:129)
	    at java.net.DatagramSocket.receive(DatagramSocket.java:701)
	    at jcifs.netbios.NameServiceClient.run(NameServiceClient.java:184)
	    at java.lang.Thread.run(Thread.java:568)

(to be precise, due to the now specified local address, the failure line 
in SmbTransport.negotiate now is 235, where previously it was 233).  The 
tcp dump shows that there is no packet sent after the successful 
NameQueryRequest and -Response and before the error message returned to 
the browser.

 From reading the code (guided by the line numbers in the exception 
stack above), it appears to me that the SmbTransport is created in 
SmbSession.java, line 72 (just before the call to connect in line 74) 
with destination port 0, and the local port is also 0 by default.  Hence 
I think that the Socket constructor is called with both port numbers 0, 
and I find it justified for the IBM JDK 1.4.1 to throw an exception in 
this case, as these port numbers do not appear to be good for connecting 
from or to.

How is this code supposed to work? Should not the destination port 
number be 139?

Regards,

Oliver Schoett