[jcifs] inconsistency (a bug?) in NameServiceClient.getByName() as called by NbtAddress.getByName().

[Eric Bloch]

Hi JCIFs folks,

We've been using JCIFs very happily for over two year in a number of
production environments with no issues but we think we're finally seeing
one... or at least something strange that we could use a little help
understanding.

We're seeing an inconsistency (a bug?) in NameServiceClient.getByName() as
called by NbtAddress.getByName().  We get different behavior for

   NbtAddress.getByName('foo', 0x20, null)

and

   NbtAddress.getByName('foo', 0x20, InetAddress.getByName(255.255.255.255))


We have a network where the broadcast query response for 'foo' reliably
comes back with two address.

Code inspection (and empircal behavior) shows that if we pass null in as the
broadcast addr (srv), we get the first address.  But if we provide a
broadcast address of 255.255.255.255, we get the second address.  I would
expect to get the same address regardless.  But perhaps I'm missing
something as I'm a cifs newbie.

Code details:
Line 330 of NameServiceClient has

                   if( response.received && response.resultCode == 0 ) {
                       int last = response.addrEntry.length - 1;
                       response.addrEntry[last].hostName.srcHashCode =
addr.hashCode();

                       return response.addrEntry[last];

                   }


Line 376 has


               if( response.received && response.resultCode == 0 ) {

               /* Before we return, in anticipation of this address
               being cached we must
               * augment the addresses name's hashCode to distinguish
               those resolved by
               * Lmhosts, WINS, or BCAST. Otherwise a failed query from
               say WINS would
               * get pulled out of the cache for a BCAST on the same name.
               */

                   response.addrEntry[0].hostName.srcHashCode =
                   request.addr.hashCode();
                   return response.addrEntry[0];
               }

It appears that jcifs is not compliant with advice from Microsoft about
choosing the address that is "closest" to the client address.  I've written
up an attempt at detecting the "closest" address, but could use some advice
here.

Any help or advice would be gratefully appreciated.

Best,
-Eric Bloch

Director, Engineering
bloch at clearwellsystems.com
-------------- next part --------------
HTML attachment scrubbed and removed