[jcifs] name resolving

[Michael B Allen]

On Wed, 8 Sep 2004 13:34:32 +0300
Alexander Buloichik <Alexander_Buloichik at epam.com> wrote:

> Hi !
> 
> >
> > It sounds like (just restating for clarification and verification)
> > that a multihomed client is registering two IP addresses in WINS under
> > the same name (10.6.2.70 and 147.204.20.105).  jCIFS always selects
> > "147.204.20.105", whereas Win2k clients always select "10.6.2.70".
> > The issue (I guess) is that 147.204.20.105 cannot be reached from the
> > client, causing jCIFS to be unable to connect.  Is this a correct
> > assessment Alex?
> >
> 
> Right.
> 
> I investigated this problem.
> 
> In the NameServicePacket.readResourceRecordWireFormat :
>         end = srcIndex + rDataLength;
>         for( int i = 0; srcIndex < end; i++ ) {
>             srcIndex += readRDataWireFormat( src, srcIndex );
>             if( i == addrIndex ) {
>                 addrIndex++;
>                 if( addrIndex == LOOKUP_RESP_LIMIT ) {
>                     addrIndex = 0;
>                 }
>                 return end - start;
>             }
>         }
>         addrIndex = 0;
> 
> It returns any address in new position without ckecking network. So,
> first, second, etc.
> I think, we should try to return address by rule #1.
> We need to find address for our network, and for that we need to have
> local IP(laddr) and netmask. I think, it not possible to find address only
> by baddr correctly.
>  But we can calculate baddr by local IP and netmask. Seems to we need to
>  add 
> netmask property instead baddr.
>  We can calculate which address more equal for baddr, and use this
>  address, 
> but it is not a right way.

Also, note that the hashCode() of an InetAddress is the integer value of the
IP. You can then use bitwise operators with those hashCode() values as
operands to test for rule #1.

Mike

-- 
Greedo shoots first? Not in my Star Wars.