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

ashish ashishn at ntechra.com
Thu Feb 21 09:07:30 EST 2002

I have tried one more stunt.. :-)
I started "NbtAddress.getAllByAddress(ip) " request in a loop.
As stated by Micheal, it may not respond coz java process started before
machine was connected thru dial up .
First machine was connected and it gave prompt replies :-)
then I disconnected the dial up connection and it started giving same error
then i again connected thru dial up and it again started giving replies.
So u see, its same JVM and it worked fine thruout ...

And till now I haven't set laddr property...

I checked out one more scenario.. I reduced "jcifs.netbios.retryTimeout" to
1 ms and for obvious reasons, I got the same error message.
I don't know if we can attribute my earlier problems to timeouts. but
default is 3 seconds and I guess this should be sufficient...

I am with Christopher here regarding error message.. when timeout is reduced
to 1ms, it's status request which has timed out
rather than it was not able to get type 0x00" name...

----- Original Message -----
From: Christopher R.Hertel <crh at ubiqx.org>
To: Michael B Allen <mballen at erols.com>
Cc: <jcifs at lists.samba.org>
Sent: Wednesday, February 20, 2002 12:44 PM
Subject: Re: [jcifs] no name with type 0x00 with no scope for host

> On Wed, Feb 20, 2002 at 02:50:25PM -0500, Michael B Allen wrote:
> > On Wed, 20 Feb 2002 11:44:05 -0600
> > Christopher R.Hertel <crh at ubiqx.org> wrote:
> >
> > > By specifying that "no name with type 0x00" was found, it suggests
> > > the query was specifically looking for a name with that suffix, and
> > > it may have missed other names.
> > >
> >
> > It *is* looking for a name with that suffix but I don't see why you
> > it could miss the other names;
> I don't think that the NODE STATUS REQUEST will miss names with that
> suffix, I think that the error message is confusing.
> > they're all returned in the node status.  If
> > you get a response to the node status at all, the name with that hexCode
> > (in this case <00>) is being advertised and the getAllByAddress call
> > is ultimately successfull. If you don't get a response it doesn't know
> > about <00> so we throw what I think is a very informative and accurate
> > UnknownHostException.
> I find it inaccurate.  It's like saying "no name 'foo' was found" when we
> were not looking for 'foo'.  We were looking for any name, with any
> suffix.  Saying no name with type 0x00 was found is the same kind of
> problem, in my mind.
> [I should mention that the Scope ID does restrict the NODE STATUS REQUEST.
> There is no wildcard scope ID.  If you specify a Scope ID of "", then you
> should not get a response from a node in scope "banana", and vice versa.]
> > You're thinking "get node status" when you need to be thinking "get all
> > the names at the host advertising this name".
> Right.  That is what I'm thinking.  The "get node status" uses the
> wildcard name which, since it is a wildcard, doesn't really have a name
> type.  It's *any* name, no matter what the suffix.
> > Let's go one level down to see how jCIFS does the getAllByAddress
> > exactly. Theres not a lot of code behind this BTW so looking at the
> > source is the best way but here goes.
> Have (just a short while ago).  You're right, of course, that that's where
> the answers are.
> > When you call:
> >
> >   getAllByAddress( NbtAddress addr )
> >
> > it calls:
> >
> >   addrs[] client.getNodeStatus( addr )
> >
> > where client is a static instace of NameServiceClient and addrs is
> > the resulting array of NbtAddress' representing the names advertised
> > by the host at addr. Every NbtAddress has an IP and a Name object as
> > a member. Every Name object must have a String name, and int hexCode,
> > and a String scope but the scope can be null.
> >
> > Now getNodeStatus builds a NODE_STATUS_RESPONSE message, encodes it in
> > a datagram packet and sends it to the IP associated with addr.
> I think you mean a NODE_STATUS_REQUEST, yes?
> > Here's the pertaintent part; IF you get a response, that name with
> > whatever hexCode is being advertised by the target (in practice <00>
> > is the only hexCode that works reliably), your getAllByAddress call is
> > successfull and the original addr object will be in the array of other
> > addrs[]. If however the host is NOT advertising a name with that
> > you will not get a response and an UnknownHostException: no name with
> > type <hexCode> ... is thrown.
> >
> > In Ashish's case, he called:
> >
> >   getAllByAddress( String host )
> >
> > which is just shorthand for:
> >
> >   getAllByAddress( getByName( host, 0x00, null ))
> >
> > and if host is a dot quad IP getByName is a noop.
> Okay, that's where the problem is, and it goes back to my original
> message.  You say above "in practice <00> is the only hexCode that works
> reliably"... but it's not since XP doesn't register it by default like the
> others do.
> I see what is going on in the code above, and it's cool that it can be
> done, but it can also be misleading and problematic.
> In the getByName(), if the host is not a dot quad IP then you are stuck
> (particularly with XP) since you cannot know that an 0x00 name will be
> present.  The lack of the 0x00 name doesn't mean that the host doesn't
> exist within the NBT network.
> If the host in getByName() is a dot quad (or a DNS name or something else
> we can resolve) then you'll have an IP address.  You no longer need to
> consider the 0x00 suffix.  It is no longer relevant to the query.
> > > environment that lead me astray.  I still think that the particular
> > > message is misleading.  If a "real" name and suffix are specified,
> > > I'd want to see "name <name> with suffix <suffix> and scope <scope>
> > > not found".  If the wildcard name is used, then I would like to see
> > > status response from host <ip address>".  Or something along those
> > >
> >
> > The NODE_STATUS_REQUEST message is a type of direct name query. This
> > physical layout of the message is exactly the same. The only thing that
> > distingushes a NAME_QUERY_REQUEST from a NODE_STATUS_REQUEST is one
> > single bit.
> Yes.  Well, no...  Three bits.  The B and RD bits are significant in the
> NAME QUERY but not in the NODE QUERY.  The bit you're talking about is the
> difference between 0x0020 and 0x0021 in the QUESTION_TYPE.  (Sorry, being
> pedantic again.)  :)
> > The QUESTION_NAME in both messages is a "real name" and
> > therefore has a hexCode associated with it. It can be <20>, <1E>,
> > In practice MS hosts only reliably respond to <00> though. You can try
> > with:
> >
> >   getAllByAddress( "ip", 0xXX, null );
> I understand what you are doing here, and why you picked the 0x00 suffix.
> The problem is that the 0x00 suffix is only *more* reliable than any
> other.  Unfortunately, it is not completely reliable, as XP emphasises.
> The RFCs require that a permanent name be registered to avoid exactly this
> problem.  Microsoft failed to follow spec.
> > >
> > > Of course, we still don't know what's going on in Ashish's case.
> >
> > I thought we figured this out? He's running on the wrong interface. I
> > directed him to the laddr and baddr properties.
> His later messages suggest otherwise.
> If he is trying the lookup using a host name, then the code will be:
>     getAllByAddress( getByName( host, 0x00, null ) )
> and the lookup *will* fail because XP doesn't register the 0x00 name.  In
> that case, the message saying no name <host> with type <00> exists is
> correct.  This would be the equivalent of doing:
>   nbtstat -a <hostname>
> The question is, what does Microsoft do in that case?  If they only check
> for the <00> name then they, too, would return an Host Not Found error.
> If he is using an IP address, then:
> a) He should get a response if 'nbtstat -A <ip>' gets a response.  If not,
>    I'd want to see a packet trace.
> b) Even if he's doing something wrong, my own 2cents is that a status
>    query using an IP address that does not get a response should report
>    "no status response from host <ip> was received" rather than "no name
>    with type 0x00" was found".
> Another reason for this is that some W/95 boxes send query replies to the
> wrong port number, so a "no status response from host <ip> was
> received" seems more accurate to me.
> You know I enjoy hair-splitting discussions like this.  ;)
> Chris -)-----
> --
> Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
> jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development,
> ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org

More information about the jcifs mailing list