[jcifs] name resolving

[Alexander Buloichik]

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.

WBR, Alex.


On 8 September 2004 03:45, Eric Glass wrote:
> > > can we implement this rule in jcifs ?Which java class should I change ?
> >
> > I think it would be problematic to even determine what your subnet mask
> > is. Look at:
> >
> > jcifs/netbios/NameServiceClient.java:getByName
> > jcifs/netbios/NameServicePacket.java:readResourceRecordWireFormat
> >
> > and try to determine why the ssnLimit doesn't achive what you want.
>
> You could possibly bitwise-or jcifs.netbios.baddr with
> jcifs.smb.client.laddr, then with each of the target IPs to see which
> one matches.  I'm still not clear on what the original poster's issue
> is, though, unless the other address (the one jCIFS is selecting) is
> unreachable from the client.
>
> 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?
>
>
> Eric