Adding Netbios Datagram Distributor support to Samba (fwd)

Christopher R. Hertel crh at
Mon Mar 6 22:38:56 GMT 2000

On Mar 6,  2:56pm, landy at wrote:
> Subject: Re: Adding Netbios Datagram Distributor support to Samba (fwd)

I'm taking this to Samba Technical.  Hope that's okay.

> > > ---------- Forwarded message ----------
> > > Date: Fri, 03 Mar 2000 15:21:16 -0600 (CST)
> > > From: landy at
> >
> > > - add Netbios Datagram Distribution support to nmbd
> > >
> > > - change the way nmbd registers group <00> names: register the individual
> > > IP addresses rather than  Note the RFC's call for all
> > > group names to be handled identically, registering the IP's of all
> > > members.
> >
> > Luke, this is the discussion we've had previously.  It's the whole
> > as a group name issue.  The one about which Paul Leach
> > wrote "Further, I believe [RFC] 1001/1002 in general to be
> > overspecified".
> >
> > See:
> >;L=cifs&amp;F=&amp;S=&amp;P=800
> >
> > Microsoft did *not* implement this per RFC.  They munged the whole
> > thing.  The RFCs say that you're supposed to keep all of the IPs
> > registered for a group name.  If the list is too long for a UDP packet,
> > then a client may negotiate a query+response via TCP.
> >
> > Microsoft never implemented that.  They store store for
> > group names *except* in special cases (type 0x1C, IIRC).  They don't
> > offer the TCP option at all.
> >
> > I *believe* that Samba does this the Microsoft way.  I'd really like to
> > know how close we are to Microsoft's implementation (and what we could
> > do to exceed their capabilities).
> >
> > > - fix build_dgram and parse_dgram to properly handle 0x14, 0x15, 0x16
> > > datagram types.
> >
> >            14 -  DATAGRAM QUERY REQUEST
> >
> > Basically, these are used to query the NBDD server to ask if it is
> > capable of relaying a datagram message.  Remember that we are emulating
> > a LAN across a routed TCP/IP internetwork.  The NBDD server is a
> > helper, in much the same way that the NBNS server is a helper.  The
> > NBDD provides LAN Multicast functionality by forwarding datagrams to
> > all members of a group.
> >
> > Of course, since Microsoft did not bother to implement the IP listing
> > correctly, all of this is moot.  Microsoft's WINS server can't possibly
> > return an 0x15 *except* in the case of the--what was it--Internet
> > special names (?).  (I can't currently get to the CIFS mailing list
> > archives and I can't remember the name or the name type.  I *think* it
> > was a type 0x1C).
> It is 0x1C in nmbd_winsserver.c.  I chose to add 0x00 as an exception,
> like 0x1C, although I think the correct (RFC) operation is to maintain IP
> lists for all groups.  I did this to minimize the changes I was
> making.  There are certainly other approcahes as well.

You are correct about RFC operation.  The RFC also states that if the list is
too long for a UDP packet the client may repeat the request over TCP.


   Each NetBIOS packet contains all the necessary information to process
   it.  None of the protocols use multiple UDP packets to convey a
   single request or response.  If more information is required than
   will fit in a single UDP packet, for example, when a P-type node
   wants all the owners of a group name from a NetBIOS server, a TCP
   connection is used.  Consequently, the NetBIOS protocols will not
   fail because of out of sequence delivery of UDP packets.

> As far as I can tell, at logon OS/2 sends a datagram to the NBDD with a
> destination of DOMAINNAME<00>, to which PDC/BDC's reply, and in that
> manner discovers a DC which can process the logon.  I'm certain it uses
> this mechanism for other purposes as well, but logons are the most
> noticeable.
> I did not add any kind of parameter to control this.  I just haven't
> gotten to it.
> > I wonder if Microsoft's WINS replies to DATAGRAM QUERY REQUEST at all!
> >
> > > - Added a parameter to turn NBDD support on/off
> >
> > Good.
> >
> > > - added a parameter to add a "grace" period to the WINS ttl (defaults to
> > > 0).  I noticed some machines, usually OS/2, wouldn't refresh their name
> > > before the negotiated ttl expired.  I added a parameter such that Samba
> > > uses the current max_wins_ttl to negotiate with the client, but takes
> > > negotiated_ttl+max_wins_grace_ttl for entry into wins.dat.
> >
> > Hmmm... Interesting.  Dunno about this.
> The RFC's indicate that the NBNS, when an entry expires, should challenge
> the owner of the name before removing it from its database.  It didn't
> look like Samba does this (and I don't know if OS/2 would respond
> anyway).  I didn't have the time to figure out how to do this, so I came
> up with this hack instead.
> I don't know why the OS/2 machines begin to refresh late.  I would see a
> machine drop out of wins.dat in the morning, and reappear that night.  At
> the time I didn't have any way to track down the root cause of the
> problem, so that provided another reason to implement this.
> > > I had originally been in contact with Jeremy Allison regarding this
> > > support, but he never got back to me on how to get this included in the
> > > Samba base code.  I also tried submitting another request to samba-bugs,
> > > which never elicited a response.  I thought you might be able to
> > > help.  This support adds the capability for Samba to function as an
> > > NBNS/NBDD for OS/2 domains.  OS/2 requires the NBDD to be present, it is
> > > used for some server-server communication, and for clients to locate
> > > domain controllers during a logon.
> >
> > It is quite likely that IBM got it right.  The real question, then, is
> > can we make our NBNS server work in *both* the Microsoft *and* the IBM
> > manner.
> >
> > I believe that NTS (the company, not the department I work for at the
> > UofMn) had a Whitepaper on this subject.
> If I remember correctly I thought NTS Shadow followed the RFC's, and did
> work fine with MS - 95, NT, etc.
> > > I'm willing to do any work necessary to make the code suitable for
> > > inclusion.  The actual number of changes is pretty minimal.  I've been
> > > running the code on various versions of Samba for a year now without
> > > incident, so I feel it's pretty stable.  I haven't, but could, add a
> > > parameter (or use the nbdd parameter) to control how <00> group names are
> > > registered.  I don't see any need to add a parameter to control how
> > > build_dgram and parse_dgram work - they aren't correct currently.
> >
> > How are they not correct?  Again, there's the RFC (correct?) way and
> > the Microsoft way.
> I meant RFC correct.  But, actually, I meant something a bit deeper than
> that in reference to parse_dgram and build_dgram.  If you look at the RFC,
> dgram types 11,12,13 have different headers and header lengths than
> 14,15,16.  If you look at the current code, the header is processed
> identically for all six types, and then the message is processed for
> 11,12,13.  I changed it to process the identical part of the headers
> first for all six, and then finish the rest of the packet differently for
> each type.

That makes sense.  My thinking is that the Samba NBNS follows Microsoft's
example here, though.

Here's the catch:  If we do things "right" (i.e., the RFC way), what will we
break with respect to interoperability with Microsoft.  If we stick with the
Microsoft way, we are obviously breaking the OS/2 implementation.  So... is
there a way to maximize our "correctness" without denting our interoperability?

> > > So, I'd really appreciate a reply, this code would be a real value to the
> > > OS/2 community.  If there is someone else better to contact, let me
> > > know.  I'm just tired of sitting on this - I'd like other OS/2 users to
> > > benefit as well.
> >
> > How do Windows boxes deal with all of this?  I'd really like to
> > understand the implications better.
> I have a mixed network - around 10 NT and WinFrame server, around 20
> OS/2 servers, a few OS/2 clients, a few 95 clients, and mostly NT
> clients.  I haven't seen any problems.
> The biggest problem I could think of is that registering group names
> differently would probably eliminate any possibility of replication
> support with MS WINS servers.

I'm not sure Samba does that yet.  I'm also not sure if it really would have an

Also... I wonder if it would work to list as the first entry in
a group name table.  I'm not sure if that would buy anything.

> With this support, I can use an OS/2 workstation and logon to OS/2 and NT
> domains with Netbios over IP.  That always worked with NetBEUI.  NT
> systems (using IBM's Coordinated Logon Client) are also able to logon to
> OS/2 domains.


> > > btw, I've been using an IBM PS/2 model 77 (MCA 486) as my sole NBNS/NBDD
> > > works great.
> >
> > Yep.
> >
> > > Thanks again for your time and help.
> >
> > Brian:  Any chance you code in Java?
> Actually, I never have, but I've always wanted to learn.  Time has always
> been the big problem - beside working I'm in an evening MBA program.  What
> were you looking for?

More coders.  jCIFS is intended as a library of CIFS routines, constructs, and
applications--all written in Java.

> Would you like me to send the patches to you, or to samba-patches, or
> both?

I'm not sure yet.  I'm personally swamped and I'd need the okay from Tridge
and/or Jeremy to put this stuff in.  I think we need to understand the issues a
bit better before we go ahead with it.

...but I'm really, really glad you did this work.  I've been wrestling with
this issue for a while and now I know there are tools to play with.  Thank you!

Chris -)-----

Christopher R. Hertel -)-----                   University of Minnesota
crh at              Networking and Telecommunications Services

More information about the samba-technical mailing list