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

Christopher R. Hertel crh at ubiqx.org
Thu Feb 21 18:31:34 EST 2002


"Allen, Michael B (RSCH)" wrote:
:
>         This particular message is generic to the least common
> denominator.
> 
>           getAllByAddress( hostname )
>         calls
>           getAllByAddress( hostname, 0x00, null )
>         calls
>           getAllByAddress( getByName( hostname, 0x00, null ))
> 
>         so the message is thrown out of all of these methods.

Yes, I see that.  It makes sense from a programming perspective.  This
discussion really is a somewhat esoteric thing but, hey, that's the kind of
stuff I like.  :)

> > Hang on.  If you send a query using the wildcard name and the remote
> > host doesn't have a <00> name you'll still get a response if the
> > remote host is
> > running NBT.  Getting a response to a wildcard NODE STATUS REQUEST has
> > nothing to do with there being a <00> name there or not.
> >
>         Well this is news to me. My understanding was that the hexCode
>         in the query had to be advertised by the target. In fact I'm
>         pretty sure it does for stuff other than 00.

This is where we get to fine details of the system...

What we need is an XP system to test against, but the way I understand it is
this:

  The wildcard name doesn't have a type byte.
  There wasn't any such thing as a type byte when the wildcard name was
  invented.  NetBIOS names with a type byte included are a descendant type
  of the original NetBIOS names.  The wildcard name is part of the parent
  class and, therefore, not impacted by the type byte question.

  So, the wildcard name means "any name", no matter what the target node
  has registered.  In fact, I believe that if there is a node running NBT
  which does not have *any* names registered, it should still reply if
  sent an NODE STATUS REQUEST.

  That's because the NODE STATUS REQUEST was put in the RFCs in order to
  allow implementation of the ADAPTER STATUS NCB.  That is, there was a
  function in the NetBIOS API that would query the remote NIC (not the PC,
  the NIC) to gather information.

>         If you do a node status on a host with a hexCode that it doesn't
>         advertise it will simply not respond.

Right, because changing the last byte of the wildcard name makes it a
different name.  It's not the wildcard name any more because the wildcard is
*always* "*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0".

I just tried sending an NODE STATUS to a W/95 box here at home.  Using the
wildcard name, I got:

$ nmblookup -A 192.168.101.15
Looking up status of 192.168.101.15
	ZATHRAS         <00> -         B <ACTIVE> 
	UBIQX           <00> - <GROUP> B <ACTIVE> 
	ZATHRAS         <03> -         B <ACTIVE> 
	ZATHRAS         <20> -         B <ACTIVE> 
	UBIQX           <1e> - <GROUP> B <ACTIVE> 

I tried changing the last byte to <20> in the outgoing packet and... no
response.  That's what I'd expect.

>         I've never seen a host that didn't advertise the 00 name.

I hadn't either until I came across XP.  It does make sense, though.  The
<00> name represents an SMB client.  If the box is just offering services it
has no need to register the <00> name.

The RFCs require a permanent name, but Microsoft doesn't meet that part of
the requirement (and even if they did, there's nothing that says it would
need to be the <00> name).

>         With the exception of XP (which we appear to be short on
>         information about)

...agreed!...

>         when have you seen machines that didn't advertise 00 to come to
>         this conclusion?

I came to the conclusion that Microsoft saw the <00> name as an optional
name after arguing about it for most of Connectathon 2001 with a guy from
Microsoft.  Nice guy, actually.  Microsoft is wrong about not choosing and
registering a permanent name, but the guy was right that the <00> name is
use as the "calling name" by clients and is not required if the machine
isn't going to be a client.  I believe it is possible to turn off the <00>
name in W2K and possibly NT4.  Dunno, haven't actually tried.

>         It does. When you try to connect with an NbtAddress it's hexCode
>         will be a 0x20 name

...makes sense to me.

>         Separate the getByName call (which does a standard name query
>         request) from the getAllByAddress (which does a node status).

Okay...

>         If the getByName call fails you get an UnknownHostException but
>         with a different message from the one in question.

Makes sense.

<snips>

> > It could, or it could mean that you're talking to an early W/95 box
> > that doesn't know how to answer a query properly.
> >
>         Or it could mean that the client isn't advertising an address
>         that matches the 'addr' argument in the getAllByAddress call in
>         which case it really shouldn't respond to the node status and
>         everything's ok.

Sorry, that confused me.  If 'addr' is a name, then I understand why we'd
get an UnknownHostException in some cases.  The name must be resolved first
to an IP in order to do the NODE STATUS.  What I don't understand is why we
would get an UnknownHostExeption if 'addr' is an IP already.

>         Remember, let's not forget the context of the whole argument
>         here. You're arguing
>         that the message returned by
> 
>         public static NbtAddress[] getAllByAddress( String host )
>         public static NbtAddress[] getAllByAddress( String host, int
> type, String scope )
>         public static NbtAddress[] getAllByAddress( NbtAddress addr )
> 
>         which are all described as:
> 
>         "Retrieve all addresses of a host by it's address. NetBIOS hosts
>         can have many
>         names for a given IP address. The name and IP address make the
>         NetBIOS
>         address. This [method] provides a way to retrieve the other
>         names for a host with
>         the same IP address. See getByName(java.lang.String) for a
>         description of type
>         and scope.
>           Parameters:
>             host - hostname to lookup all addresses for
>             type - the hexcode of the name
>             scope - the scope of the name "
> 
>         Kind of a crappy dummed-down description but notice no where
>         does this mention
>         anything about doing a node status request. It just so happends
>         that the node
>         status request is used to service this request but the user does
>         not know this
>         (although if you're messing around with NbtAddress it would be a
>         good idea). So if
>         this operation fails I believe the only exception you'll get
>         besides datagram socket
>         IO related stuff is:
> 
>         "UnknownHostException: no name with type 0x00 with no scope for
>         host 10.0.100.114"
> 
>         if the callers arguments where "10.0.100.114", 0x51, foo.net you
>         would get:
>
>         "UnknownHostException: no name with type 0x51 with scope foo.net
>         for host 10.0.100.114"
> 
>         You argue it should be:
> 
>         "UnknownHostException: no status response from host 10.0.100.114
>         was received"

Hmmm... I'm not being clear then...

>         Now which message is more accurate?
> 
>         Back to you .... :~)

getAllByAddress( Addr )
  In this case you are not doing a host lookup.  The only failure would be
  that no response is actually received.  In this case the term
  "UnknownHostException" would be very wrong.  You would want to report
  that you got no response, not that the host is unknown.  Both are
  equally troubling to a user who doesn't understand how (badly) this
  NBT/SMB/CIFS stuff works.  I just think that "NoResponse" is more
  correct and helpful than "UnknownHostException".

getAllByAddress( Host )
  In this case, the user specified a host but no suffix.  Internally, the
  software needs to do some guessing.  Without any other clues (such as
  wanting to start an SMB session) the <00> suffix is a good guess.
  Perhaps you could try both <00> and <20>, as these are the most common.
  There really is no 100% good answer here since the user did not supply a
  complete name.  The name is not complete without the suffix.
  By definition, a NetBIOS name is 16 bytes.  The fact that the 16th byte
  has a special meaning was something that was added after both NetBIOS
  and NBT were created.

  Anyway, if the name could not be resolved, I'd expect:

  UnknownHostException: Name <Host> not found.

getAllByAddress( Host, Suffix )
  In this case, if the name could not be resolved I'd expect:

  UnknownHostException: Name <Host><<Suffix>> not found.

  Eg. if <Host> is "Zaphod" and the suffix is 20,

  UnknownHostException: Name Zaphod<20> not found.

getHostByAddress( Host, Suffix, ScopeID )
  Similar to the above.  If the ScopeID is "marvin.net", you might see:

  UnknownHostException: Name Zaphod<20> not found in scope marvin.net.


The basic underlying thing from my perspective is that you get an
UnknownHostException if the host name cannot be resolved to an IP address,
and a NoResponseException if you've gotten the IP address, but the remote
node isn't answering.

Sure would make it easier to debug.

Chris -)-----

PS.  My 7-year-old daughter calls me "Captain Pedantic".  Ouch.

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




More information about the jcifs mailing list