[jcifs] Server resolution for Windows 98

[Christopher R. Hertel]

Matthew Tippett wrote:
> 
> >
> > Um... It's not a "name" per. se.  It's just that it is a permitted
> > CALLED NAME in the NBT Session Request.  Windows is picky about the
> > CALLED NAME field (Samba is not).  So, if you are talking to Windows
> > NT4, XP, 2k, or to Samba, you can use the "*SMBSERVER" name as the
> > called name.  This is very useful if the user handed you a DNS name or
> > IP address instead of a NetBIOS name.
> 
> I also notced it is in the CIFS spec too.  I figured if I had the
> definition wrong, I was pretty much on the right track.

If you mean the SNIA CIFS Technical Reference (it's not allowed to be a
specification...) then (sheepish grin) I wrote that part.  :)

> > The correct wildcard name is
> >
> >   *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
> >
> > ...which translates to:
> >
> >   CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> 
> Could you explain what this 'translation is to?  It looks like it is a
> wierd hex offset from AA?

See http://ubiqx.org/cifs/NetBIOS.html#NBT.3.1.1

> >   "*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
> >   "*               "
> >   "*\0fooberrypie"
> >
> > Would all be read by Samba (after encoding, sending over the wire, and
> > decoding) as the same thing: "*".
> >
> 
> Doesn't that present an opportunity for some subtle bugs?  I assume that
> Andrew (know him from Australia) wouldn't just rely on language
> behaviour (NULL terminated) since the full 16 bytes have a real purpose.

It doesn't, really.  The asterisk is an illegal first character for NetBIOS
names under NBT (per RFC1001/1002).  That's why anything that cleanly
reduces to "*" is okay.  The "*SMBSERVER" name isn't a problem because

1) It is never registered.
2) It is only ever used in the Session Service, while the "*" name is
   really only supposed to be used in the name service.

>   (I would go so far as to say that it could even leave Microsoft an
> angle to break a couple of releases of Samba with (by putting a <00>
> near the start.

No, Samba is more flexible than Windows.  It *accepts* all of the examples I
gave because they all reduce to "*", but it only ever sends the
"*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" name because we know that Windows is
picky.

> > On the other hand, all of the Windows systems I've tested do *not*
> > translate the NBT name strings back to their original form before
> > comparison.  So Windows is looking for
> > "CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA".
> > That's a speed hack, but it does mean that Windows is pickier.
> 
> Is the encoded form supposed to be opaque by the standard?  It would be
> interested in finding the rationale for the translation somehwere :).

It's in the RFCs and the reference above.  :)

> 
> > I would say your patch is correct.  If it's faster (and simpler) to
> > define it as an array of bytes in encoded form then doing so might
> > make sense. I'll let Mike answer that one.  From a theoretical point
> > of view, there's no need to translate it more than once.
> 
> I prefer the human readable form :) Plus it is a one line patch as is :).

It's very easy to translate it *back* to human readable form.  The encoded
form is used on the wire to make the names fit DNS best practices.  Fun, eh?

> >
> > Captain Pedantic -)-----
> >
> 
> Another bug defeated, I am off to bed!

Bed?  Oh... right... sleep...  I remember that.

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