Adding Netbios Datagram Distributor support to Samba (fwd)

[landy at alumni.caltech.edu]

On Mon, 6 Mar 2000, Christopher R. Hertel wrote:

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

No problem at all.  I'm going to delete a lot out of this message to make
it a bit more manageable.
 
<stuff deleted>

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

I still don't think this particular issue (parse_dgram, build_dgram) is a
question of RFC vs. MS.  Packets of type 0x10, 0x11, 0x12 have DGM_LENGTH
and PACKET_OFFSET in their headers (1002:4.4.2).  However headers for
packet types 0x14, 0x15, 0x16 do not contain those values (1002:4.4.4,
4.4.5).  I'll admit that 1002:4.4.1 makes it seem like they all share the
same header, which might be why the current code was written as it
currently is.

The current Samba code treats all those packets the same, meaning it feeds
garbage values from the destination name portion of the packet into the
variables for dgm_length and packet_offset.  All I did was fix parse_dgram
to skip those fields for packets that don't contain them, and similarly
for build_dgram.

If Samba never responds to 0x14, 0x15, 0x16 packets, and never creates
them, then it doesn't hurt to have it properly parse (and theoretically
build) those packets.  As long as it never does, we couldn't possibly
have a conflict with the MS method.  So this would be independent from the
decision to add the functionality to deal with those messages.  If that
functionality is added, then parse_dgram and build_dgram definitely need
to be fixed.

Now, changing how Samba registers group names and having it deal with
datagram query packets - that is RFC vs. MS.

I believe my code also properly processes the header for 0x13 packets, but
doesn't do anything with the error code itself, nor did I ever deal with
those packets.
 
<more deleted>

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

Oops, I didn't mean to imply that it did yet, I meant in case someone
wanted to add that functionality.
 
> 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.

I hadn't thought of that.
 
> > 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!
> 

<a little more deleted>

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

I didn't know if you had specific pieces you were looking for people to
work on, or just looking for people in general.  I'm interested, I just
don't want to commit to something I can't follow through on.  I would
definitely like to hear a little more about where the project is at, etc.

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

I'm going to forward them to samba-patches, maybe looking at the
changes would alleviate some of these concerns.  I probably didn't comment
the code as much as I should have.  If it needs more before you can look
at it, let me know and I'll add it in.  And if you don't have the time to
look at them now, wait until you do.

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

Thanks!  It actually wasn't nearly as difficult as I thought it would be.


Brian Landy
landy at alumni.caltech.edu
 
> Chris -)-----
> 
> -- 
> Christopher R. Hertel -)-----                   University of Minnesota
> crh at nts.umn.edu              Networking and Telecommunications Services
> 
>