[jcifs] Problem connecting with domain controller

[Ingo Rockel]

Hi,

we have a jcifs-sso-ntlm environment on a oracle application cluster. We 
have set up a new installation (new cluster) and problems connecting to 
the domain controller.

In particular the connect to the wins works just fine returning a list 
of available domain controllers (seven), jcifs tries to connect to the 
first (in a different network) and fails with the following message:

jcifs.smb.SmbException:
jcifs.util.transport.TransportException: Connection timeout
         at jcifs.util.transport.Transport.connect(Transport.java:164)
         at jcifs.smb.SmbTransport.connect(SmbTransport.java:262)
         at jcifs.smb.SmbSession.interrogate(SmbSession.java:74)
         at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:111)
         at 
com.pironet.pbng.principal.authentication.filter.NtlmAuthenticationFilter.doFilter(NtlmAuthenticationFilter.java:413)
         at 
com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:16)
         at 
com.pironet.pbng.cms.servletfilter.SessionFilter.doFilter(SessionFilter.java:61)
         at 
com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:20)
         at 
com.pironet.pbng.prj.cms.web.common.EncodingFilter.doFilter(EncodingFilter.java:95)
         at 
com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:600)
         at 
com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317)
         at 
com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:793)
         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:534)

it tries the same for the next two domain controllers failing with the 
same message. Sniffing with etherreal shows the following:

No.     Time        Source                Destination           Protocol 
Info
    1664 15.317358   10.21.22.41           10.243.49.100         TCP 
   31564 > 0 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=161395807 
TSER=0 WS=0

Frame 1664 (76 bytes on wire, 76 bytes captured)
Linux cooked capture
Internet Protocol, Src Addr: 10.21.22.41 (10.21.22.41), Dst Addr: 
10.243.49.100 (10.243.49.100)
Transmission Control Protocol, Src Port: 31564 (31564), Dst Port: 0 (0), 
Seq: 0, Ack: 0, Len: 0
     Source port: 31564 (31564)
     Destination port: 0 (0)
     Sequence number: 0    (relative sequence number)
     Header length: 40 bytes
     Flags: 0x0002 (SYN)
     Window size: 5840
     Checksum: 0xf6a5 (correct)
     Options: (20 bytes)
         Maximum segment size: 1460 bytes
         SACK permitted
         Time stamp: tsval 161395807, tsecr 0
         NOP
         Window scale: 0 (multiply by 1)

and this packet seems not to get any answer. It looks like a network 
problem to us but we don't have any idea what it might be in particular. 
Any Ideas or Hints welcome.

regards,

     Ingo

-- 
PIRONET NDH AG
Dipl. Inf. Ingo Rockel - Produktentwicklung
Maarweg 149-161, 50825 Koeln
Tel.: +49 (0)221-770-1788 / Fax: +49 (0)221-770-1005
mailto:irockel at pironet-ndh.com - http://www.pironet-ndh.com