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

Michael B Allen mba2000 at ioplex.com
Fri Sep 23 18:47:40 GMT 2005


On Fri, 23 Sep 2005 19:56:16 +0200
Oliver Schoett <os at sdm.de> wrote:

> Michael B Allen wrote:
> 
> >Another difference is that the resultCode=3 which means FMT_ERR (format
> >error).
> >
> >Unfortunately the 1.2.x debugging info doesn't show the "datagram packet
> >sent to" message so I can't see that the packet isn't being sent to WINS
> >as opposed to broadcasting. If it's sent to WINS then isBroadcast *should*
> >be false.
> >  
> >
> I do not have tcpdump on the OC4J server yet, but from my PC I can see 
> that 0.8.3 did broadcast, whereas 1.2.4 did not (so presumably it sent 
> the packet directly to the WINS server).

Actually I think 0.8.3 doesn't support multiple comma separated WINS entries. It only takes one. That might be why it's ignoring them and choosing to broadcast.

> The config is genuine (except for the changed IP addresses).  As you 
> suggested, I took out the broadcast address and got the same error as 
> before.  By the way, the browser error message is
> 
> java.net.UnknownHostException: KVMADS
> 	at jcifs.netbios.NameServiceClient.getAllByName(NameServiceClient.java:292)
> 	at jcifs.netbios.NbtAddress.getAllByName(NbtAddress.java:454)

So you have a WINS issue but you got lucky with broadcasting lookups.

> Conversely, I took out the jcifs.netbios.wins address, forcing 1.2.4 to 
> broadcast, which worked but resulted in another error:
> 
> Browser message:
> 
> java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for KVMADS
> 	at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:126)
> 	at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150)

... and your luck ran out. Actually if you swap the working 0.8 jar file with 1.2 jar file without changing anything else then it should probably work but that DC lookup code is a little different so YMMV.

> 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)

No route to host? That seems like a different issue. Do you have multiple network interfaces? Perhaps you need to set the laddr property.

> The domain server IP address ...182.2 is correct and I can ping and 
> traceroute from the AIX server to it; the domain server is a Windows 
> 2003 Active Directory with SMB signing turned off.  This error also 
> leaves me stumped.

If you have multiple network interfaces Java may not guess the right onw to create sockets on. There's not much jCIFS can do about this other than allow you to specify which interface to use with the jcifs.smb.client.laddr property.

> Recall that 0.8.3 works fine on this machine; the only problem we have 
> with it is that at the client site the domain server lists from WINS 
> contain bad entries which the admins cannot get rid of, and 0.8.3 fails 
> in this case.  You mentioned that this bug has long been fixed; but both 
> 1.1.2 and now 1.2.4 did not work at all for us.

It depends on how the entries are "bad". If they are machines that are alive and jCIFS can negotiate with them then jCIFS will assume they are valid domain controllers.

What happends when you use the jcifs.http.domainController property instead?

I don't think I can help you much with this. There are just too many variables. I should be pretty clear that you need detailed packet captures. Once you get those it should be pretty easy to at least see what the problem is.

Mike


More information about the jcifs mailing list