Adding Netbios Datagram Distributor support to Samba (fwd)
Christopher R. Hertel
crh at nts.umn.edu
Mon Mar 6 22:38:56 GMT 2000
On Mar 6, 2:56pm, landy at alumni.caltech.edu 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 alumni.caltech.edu
> >
> > > - add Netbios Datagram Distribution support to nmbd
> > >
> > > - change the way nmbd registers group <00> names: register the individual
> > > IP addresses rather than 255.255.255.255. 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
> > 255.255.255.255 as a group name issue. The one about which Paul Leach
> > wrote "Further, I believe [RFC] 1001/1002 in general to be
> > overspecified".
> >
> > See:
> >
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind9910c&L=cifs&F=&S=&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 255.255.255.255 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
> > 15 - DATAGRAM POSITIVE QUERY RESPONSE
> > 16 - DATAGRAM NEGATIVE QUERY RESPONSE
> >
> > 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.
1001:13.1.1:
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
impact.
Also... I wonder if it would work to list 255.255.255.255 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.
Kewl!
> > > 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? http://jcifs.samba.org/
>
> 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 nts.umn.edu Networking and Telecommunications Services
More information about the samba-technical
mailing list