[jcifs] no name with type 0x00 with no scope for host

[ashish]

yep.. NbtAddress.ALL_HOSTS_NAME is used for query .
so i guess jcifs is sending proper request in the PDU if thats is the only
problem.
Well, I have taken latest version of jcifs and it still same problem exists.
so what exactly needs to be done...



----- Original Message -----
From: Allen, Michael B (RSCH) <Michael_B_Allen at ml.com>
To: <crh at ubiqx.mn.org>
Cc: <jcifs at lists.samba.org>
Sent: Tuesday, February 19, 2002 6:21 PM
Subject: RE: [jcifs] no name with type 0x00 with no scope for host


>
>
> > -----Original Message-----
> > From: Christopher R. Hertel [SMTP:crh at ubiqx.org]
> > Sent: Tuesday, February 19, 2002 8:53 PM
> > To: Allen, Michael B (RSCH)
> > Cc: 'crh at ubiqx.mn.org'; jcifs at lists.samba.org
> > Subject: Re: [jcifs] no name with type 0x00 with no scope for host
> >
> > "Allen, Michael B (RSCH)" wrote:
> > :
> > > > Use "*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" for NODE STATUS REQUESTS.
> > > >
> > >         Same thing. The 16th byte is <00>.
> >
> > But you are not sending a name.  You're sending the wildcard.  If I do:
> >
> > $ nmblookup -S foo
> >
> > Then the first thing nmblookup does is send a name query for
> >
> >   FOO\20\20\20\20\20\20\20\20\20\20\20\20\0
> >
> > If it gets a response, the -S option will cause it to send a follow-up
node
> > query for the same name.  Yes, it ends with a <00>, but it still starts
with
> > "FOO".  We know this will work, however, because the positive name query
> > response tells us that the name in question exists on the other node.
> >
> > If you don't know what names are on the other node, then use a wildcard
> > query.  Yes, it ends with a <00> but then entire name is different.
> >
> > Note that Microsoft doesn't even bother to decode the names when doing
> > comparisons.  Windows compares the level-1 encoded name itself.  So,
it's
> > looking for CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.  That's a wildcard name to
> > Windows.
> >
> Well, I'm not sure I understand what the significance of using the name ve
rses the
> wildcard is but jCIFS *always* uses the wildcard because all methods that
provoke the
> Node Status are doing so to determine the names available. If you look at
the
> getAllByAddress it builds a NodeStatusRequest with the
> NbtAddress.ALL_HOSTS_NAME which is the "*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
name and
> with a  type of <00>.
>
> > > >   It's a
> > > > wierd name, I know, but it's actually in the RFCs.  It's an asterisk
> > > > followed by 15 nul bytes, then encoded as usual.  It's the wildcard
name.
> > > > It is illegal to register it, but all NBT nodes are supposed to
respond to
> > > > it (within the proper scope ID, of course).  It is also the
precursor to the
> > > > "*SMBSERVER" name.
> > > >
> > >         What is, node status?
> >
> > No, the wildcard name (just '*' followed by 15 nuls) is the precursor to
> > *SMBSERVER.
> >
> I don't understand. The NodeStatus *is* the wildcard name with 15 nuls, a
hex code of
> <00>, and a type of NBSTAT. The *SMBSERVER is used in the Session
Establishment
> message and has nothing to do with Node Status. You might use Node Status
to help
> figure out a good calling name though.
>
> > > Actually at this point sending the node status *after*
> > > SMBSERVER is a little better I think. The node status is a last
resort.
> >
> > Depending upon what you're doing.  I you are trying to find a called
name in
> > order to set up an SMB session, then it all depends upon whether you
think
> > there are more Samba, Win/NT4, W2K, and W/XP systems out there than W/9x
and
> > W/Me.  Probably a good guess, so *SMBSERVER should come before adapter
> > status.
> >
> What's different about these servers? We always do the same thing when
trying to do
> session est.:
>
> Try to use whatever name was provided
>     or use the first label if it looks like a dns name
>     or use the ip if that's all that was provided
> If that fails try SMBSERVER
> If that fails use ip if it was not already.
> Finally, try to figure out the name using Node Status.
> else throw UnknownHostException
>
> I think that's how it goes. The firstCalledName and nextCalledName code in
UniAddress
> and NbtAddress shows clearly what happends. Now, I don't think I've ever
seen this fail
> where another client succeeded so I'm interested to know what the OPs
problem is
> with XP... :~(
>
> > All I'm saying about Adapter Status is that you should use the wildcard
name
> > unless you *know* that a specific name (eg., FOO<00>) exists on the
remote
> > node.  From the original problem report, it looked as though the
> > <machine><00> name was being used.
> >
> Ahh. No. The debugging message just printed it that way. jCIFS *always*
uses the
> wildcard name for node status b/c it's not very useful to print out the
"*\0\0\0\0\.." name. It
> prints the IP instead.
>
> >   On XP, which doesn't register
> > <machine><00> by default, you really do need to use the wildcard name.
> >
> We always do....
>
> Mike
>
>