[jcifs] problem with NbtAddress.getAllByAddress()

[ashish]

Ok, here's sniffer output... when Node Status Request is send.
And I don't see any reply for this request from the remote machine......



UDP:  ----- UDP Header -----
UDP:
UDP:  Source port = 61764
UDP:  Destination port = 137 (NBNS)
UDP:  Length = 58
UDP:  Checksum = 00EA
UDP:
NBT:  ----- Netbios Name Service Header -----
NBT:
NBT:  Type = Query Request
NBT:  Status = Success
NBT:  Transaction ID = 0x0004
NBT:  Flags Summary = 0x0110
NBT:     - Broadcast
NBT:     - Recursion Desired
NBT:  Question count = 1
NBT:  Answer Count = 0
NBT:  Name Service Count = 0
NBT:  Additional Record Count = 0
NBT:  Question Name = *..............[0]
NBT:  Question Type = 0x0021
NBT:  Question Class = 0x0001
NBT:



----- Original Message -----
From: Christopher R.Hertel <crh at ubiqx.mn.org>
To: ashish <ashishn at ntechra.com>
Cc: <jcifs at samba.org>
Sent: Monday, May 13, 2002 10:55 AM
Subject: Re: [jcifs] problem with NbtAddress.getAllByAddress()


> 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
>