[jcifs] Question about configuring resolve order
Allen, Michael B (RSCH)
Michael_B_Allen at ml.com
Thu Mar 14 13:19:26 EST 2002
> -----Original Message-----
> From: mike [SMTP:mike at opennms.org]
>
> Hello,
>
> I'm attempting to use NbtAddress.getByName() to resolve IP
> addresses to their corresponding NetBIOS name. Provided that the
> IP address resides on the same subnet this appears to
> work. However when the box resides on a different
> subnet I get an UnknownHostException.
>
That's strange. I think you're talking about doing reverse lookups in which case jCIFS would
sent a NodeStatusRequest directly to the host. This is an unreliable method of determining a
hostname but it should not be subnet dependent.
> The 'jcifs.netbios.wins' and 'jcifs.resolveOrder' properties
> appear to be set correctly.
>
NbtAddress does not use the resolveOrder property in any way. Only UniAddress uses that.
And if you're doing reverse lookups (IP --> name) then these properties are not used regarless of
wheather or not UniAddress or NbtAddress is used.
> I turned on debugging and here's what I'm seeing:
>
> ---------------------------------------------------------------------------
> ...
> jcifs.resolveOrder=WINS,BCAST
> jcifs.properties=./jcifs.properties
> jcifs.smb.client.password=
> jcifs.smb.client.domain=
> jcifs.smb.client.laddr=
> jcifs.smb.client.username=guest
> jcifs.util.log=ALL
> jcifs.netbios.retryTimeout=2000
> jcifs.netbios.cachePolicy=30
> jcifs.netbios.baddr=255.255.255.255
> jcifs.netbios.retryCount=2
> jcifs.netbios.wins=192.168.0.38
> jcifs.netbios..hostname=OpenNMS_DP
> path.separator=:
>
> Mar 13 18:05:38.304 - name service address cache
> 0.0.0.0<00> 0.0.0.0<00>/0.0.0.0
> JCIFS0_198_CC<20> JCIFS0_198_CC<20>/192.168.0.198
>
> Mar 13 18:05:38.331 - nbt name service packet sent
> NodeStatusRequest[nameTrnId=1,isResponse=false,opCode=QUERY,isAuthAnswer=false,isTruncated=false,isRecurAvailable=false,isRecurDesired=true,isBroadcast=true,resultCode=0,questionCount=1,answerCount=
> 0,authorityCount=0,additionalCount=0,questionName=*<00>,questionType=0x0021,questionClass=IN,recordName=null,recordType=0x0000,recordClass=0x0000,ttl=0,rDataLength=0]
> Mar 13 18:05:38.332 - datagram packet sent to: 192.168.3.2
> 00000: 00 01 01 10 00 01 00 00 00 00 00 00 20 43 4B 41 |............ CKA|
> 00010: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
> 00020: 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 |AAAAAAAAAAAAA..!|
> 00030: 00 01 |.. |
>
> Mar 13 18:05:42.349 - nbt name service packet sent
> NodeStatusRequest[nameTrnId=3,isResponse=false,opCode=QUERY,isAuthAnswer=false,isTruncated=false,isRecurAvailable=false,isRecurDesired=true,isBroadcast=true,resultCode=0,questionCount=1,answerCount=
> 0,authorityCount=0,additionalCount=0,questionName=*<00>,questionType=0x0021,questionClass=IN,recordName=null,recordType=0x0000,recordClass=0x0000,ttl=0,rDataLength=0]
> Mar 13 18:05:42.350 - datagram packet sent to: 192.168.3.2
> 00000: 00 03 01 10 00 01 00 00 00 00 00 00 20 43 4B 41 |............ CKA|
> 00010: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
> 00020: 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 |AAAAAAAAAAAAA..!|
> 00030: 00 01 |.. |
>
> Mar 13 18:05:44.361 - nbt name service packet sent
> NodeStatusRequest[nameTrnId=4,isResponse=false,opCode=QUERY,isAuthAnswer=false,isTruncated=false,isRecurAvailable=false,isRecurDesired=true,isBroadcast=true,resultCode=0,questionCount=1,answerCount=
> 0,authorityCount=0,additionalCount=0,questionName=*<00>,questionType=0x0021,questionClass=IN,recordName=null,recordType=0x0000,recordClass=0x0000,ttl=0,rDataLength=0]
> Mar 13 18:05:44.362 - datagram packet sent to: 192.168.3.2
> 00000: 00 04 01 10 00 01 00 00 00 00 00 00 20 43 4B 41 |............ CKA|
> 00010: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
> 00020: 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 |AAAAAAAAAAAAA..!|
> 00030: 00 01 |.. |
>
> Mar 13 18:05:48.378 - nbt name service packet sent
> NodeStatusRequest[nameTrnId=6,isResponse=false,opCode=QUERY,isAuthAnswer=false,isTruncated=false,isRecurAvailable=false,isRecurDesired=true,isBroadcast=true,resultCode=0,questionCount=1,answerCount=
> 0,authorityCount=0,additionalCount=0,questionName=*<00>,questionType=0x0021,questionClass=IN,recordName=null,recordType=0x0000,recordClass=0x0000,ttl=0,rDataLength=0]
> Mar 13 18:05:48.379 - datagram packet sent to: 192.168.3.2
> 00000: 00 06 01 10 00 01 00 00 00 00 00 00 20 43 4B 41 |............ CKA|
> 00010: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
> 00020: 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 |AAAAAAAAAAAAA..!|
> 00030: 00 01 |.. |
>
> Exception in thread "main" java.net.UnknownHostException: no name with
> type 0x00 with no scope for host 192.168.3.2
> at jcifs.netbios.NbtAddress.getAllByAddress(NbtAddress.java:495)
> at jcifs.netbios.NbtAddress.checkData(NbtAddress.java:634)
> at jcifs.netbios.NbtAddress.getNodeType(NbtAddress.java:665)
> at Query.main(Query.java:30)
> -------------------------------------------------------------------------
>
> I don't understand why all the requests are being sent directly to
> the 192.168.3.2 address. My understanding is that based on my
> properties settings I should see requests first being sent to the
> WINS server and if that fails requests would next be broadcasted
> on the local subnet. What am I missing?
>
In addition to Chris' response,
Instead of doing a reverse lookup on each host directly you should probably build a list of
network information by using listFiles on workgroups. Provided the user knows what workgroup
the're interested in you can get a list of all hosts and record their IP addresses. The rev-lookup
thing does not work with Win95 and I suspect newer XPish machines. I would also avoid the
NetBIOS functions as they are being slowing phased out by MS. Also, you might want to use
UniAddress if you're going to do any direct lookups. But you really need DCE/RPC functionality
to build good CIFS networking tools which jCIFS does not do.
Mike
More information about the jcifs
mailing list