TDI + NetBIOS = Network Neighborhood
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Tue Dec 16 00:10:02 GMT 2003
wrote to the wine-devel mailing list about this one describing
a few words about what's needed to be done to "support" your
rfc1001.txt and rfc1002.txt - these describe NBT (netbios over tcp)
and how to get:
- datagrams (port 138) equivalent to UDP
- sessions (port 139) equivalent to TCP
- names (port 137) LISTEN UP! THIS IS EQUIVALENT TO DYNAMIC-DNS + DHCP!
the last one of these needs careful explanation.
in light of the recent attempts by the wireless IETF crowd
to create a dynamic routing protocol is is _totally_ ironic
that netbios got there first _by over twenty years_ - and that
there is a FREE implementation for the taking, in nmbd.
it's also pretty ironic because they've had to play catch-up
with concepts like node status queries in additional extension
draft rfcs, and they STILL haven't added the "name conflict"
concept which is there to tell anyone that will listen that
a name which is attempting to be claimed is being taken by
someone else who won't give it back.
port 137 _is_ actually dns, so if you happen to know of any wine-licensing
compatible DNS client code then you can use that as the basis for your
it's dns but it's extended: the names of the types of packets mean
slightly different things;
there is additional packet types to represent NAME_REGISTER
there is also a different CNAME type to cope with netbios names;
the "dns zone" is there it's called a "scope";
the "dns name" is "compressed" it's a brain-dead misnomer
given that the name is actually expanded in some sort of
stupid base-4 (no, not base-64, yes, that's right, base-4)
encoding scheme that turns a 16-byte space-padded thing into
an overbloated 64-byte monster.
eek, it's been a while. have a look at www.cb1.com/~lkcl/ntdom.
no, try this: http://www.monyo.com/technical/samba/rfc/
actually, first try this: http://ubiqx.org/cifs/References.html
which will give you a better idea of what the other one contains:
the ftp://ftp.microsoft.com/developr/drg/CIFS directory appears
to be inaccessible, now, which is just typical.
basically you should read cifsbrow.txt in conjunction with rfc1001.txt
YOU ONLY NEED A MINIMAL SUBSET OF THOSE DOCUMENTS FOR A CLIENT
the only reason that you need to read those docs - skimmed - is
because you need to know what you are going to be communicating
with (not implementing, server-side, just connecting to, client-side).
all you _really_ need is to be able to do a NetBIOS name query and
also to be able to do a couple of SMB queries to obtain lists of
THAT IS ALL THAT A CLIENT-SIDE NETWORK NEIGHBOURHOOD BROWSER IS.
if you're implementing this from scratch, however, expect to allocate
about ... mmm ... anywhere between four and eight weeks.
i _thoroughly_ recommend that you investigate finding some dns client
code to adapt and save yourself some time with decoding port 137.
also, while you're at it, you might want to next focus on the contents
of the ntnp.doc file which was last available with the ms-dev that
contained visual studio 4.3.
ntnp.doc stands for nt network provider and it had a companion
"client-side" document to describe the other bit that went with it.
basically there is a "redirector" protocol on both client _and_
server-side that covers browsing.
these two protocols "merge" the network neighbourhoods into one big
happy family, such that netware's network neighbourhood can be installed
and cooperate happily with the smb network neighbourhood can be
installed and cooperate happily with the kerberos-domain-based
network neighbourhood and it was all one big happy family yippee.
so, whilst you may believe that it is best to implement
the network neighbourhood browsing functions as "direct" as
possible, if you ever install the "client for netware" under
wine and then wonder why it doesn't appear in the network
neighbourhood, remember what i said in the paragraph above!!
More information about the samba-technical