[jcifs] problem with NbtAddress.getAllByAddress()

Christopher R.Hertel crh at ubiqx.mn.org
Tue May 14 03:55:37 EST 2002


On Mon, May 13, 2002 at 10:32:14AM -0700, ashish wrote:
> ok, this time it's a different story.
> I am polling a remote subnet to see what type of boxes are there.. sort of
> asset tracking...

Hmmm...  Are you using the directed broadcast address or are you going
through the IP range one address at a time?

> So I really cannot tell you whether it is dial up or not.

If nbtstat can retrieve the information then we should be able to get it
too, assuming that the same network path is available and is being used.

> here's output of nbtstat -A
> 
>    Name               Type         Status
> ---------------------------------------------
> XXXXXX <00>  UNIQUE      Registered
> WORKGROUP      <00>  GROUP       Registered
> XXXXXXX <20>  UNIQUE      Registered
> WORKGROUP      <1E>  GROUP       Registered
> XXXXXXX <03>  UNIQUE      Registered
> XXXXXXX <01>  UNIQUE      Registered
> 
> MAC Address = YY-YY-YY-YY-YY-YY

If the XXXXXX<00> name is there, then we should be able to send the query.

> I have changed the name and mac address in this output.

Well, I can see that.  ;)

> I agree that XP may have a problem or dial up may have problems...
> My only point is what so unique about Nbtstat that it works.

Dunno.  I wanted to see the nbtstat output to see if the <00> unique name
was in the list.  It is, so it shouldn't be a problem.

> You wrote that nbtstat may be getting information from other means. What are
> those means.

I know that jCIFS looks for the <00> name and that XP does not always
register the <00> name.  This is a problem with Microsoft's
implementation.  They don't follow STD19, which states that there should
always be a machine name registered.

Given the above output, and assuming that jCIFS could not send the
Adapter Status Query to that same node (via UDP port 137) or could not
receive the reply...  I would need to see sniffer traces to discover what
is actually happening.

Another option for you is to try the nmblookup tool that comes with
Samba.  That does the same job as nbtstat, but can be run from a Unix
system.  If nmblookup can get results, then I would *really* need to see a
sniffer trace.

Basically, though, I know of no problems in jCIFS that would cause it to
fail to send queries and receive responses.  The <00> issue is a problem
that XP has, and other Windows flavors can have the same problem (though
it is less likely to occur).  I believe that there are ways to work around
the <00> issue, but they are all ugly.  I'm not sure what nbtstat does if
the remote node doesn't have a <00> name.

Bottom line:  I don't know what the problem is, so I cannot help fix it.

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org




More information about the jcifs mailing list