bug fix?: 2.2.7a, nmbd/nmbd_packets.c, listen_for_packets()

[Peter Hurley]

Andrew,

After being enlightened regarding "the bigger picture", I have included
an alternate solution below that may be more appropriate, in addition to
my other comments.

> > I think there are several good reasons to include this fix:
> > 1)  I think the documentation is ambiguous on this subject.
> 
> Then this is a very good argument for a doco patch.

OK.  I would additionally suggest a brief discussion in the "wins
support=" section of smb.conf man page, and in "2.3.5, WINS Lookup".
Something to the effect that 127.0.0.0/8 (or equivalent) must be in the
"interfaces=" when using "bind interfaces only = yes".  Additionally,
the documentation should add that the WINS server interface when "wins
support = yes" is the first interface in "interfaces = ", or the first
probed interface that is not loopback and (insert other conditions
here).  Perhaps an alternate commented-out entry in the default smb.conf
as well?

> > 2) "interfaces=" is an overloaded option.  Setting the loopback
address
> > in "interfaces=" has both SMBD and NMBD listening to it.......
>
> This is incorrect.  SMBD listens on wildcard, while NMBD listens on
each
> detected broadcast interface and on the wildcard.   NMBD later
discards
> packets if 'bind interfaces only' is set, as an attempted security
> measure.

I just meant that SMBD and NMBD interpret "interfaces=" differently
which makes it hard to control without side effects.

> Given that we might be running a different nmbd on localhost,
> and that we don't always have a wins server running locally, I'm not
> sure that forcing localhost into the list is the best idea.

Perhaps I'm mistaken, but I don't think "a different nmbd on localhost"
is possible.  In nmbd/nmbd_subnetdb.c : create_subnets(), loopback is
specifically checked for and ignored if present in the interface list.

> > 3) I've seen quite a few misconfigured "interfaces.......
> 
> I think that some extra testparm logic would go a long way here.

I like this idea.

> > 4) I believe this to be the most serious......
> >
> > I think in this situation a small change could go a long way.
> 
> It may do so, but we need to make sure it's also the 'correct' fix.

I meant to submit the fix only as a potential solution for review by
more knowledgeable persons than myself.

An alterate short-term bug fix would be to fix libsmb/namequery.c :
resolve_wins().  Instead of,

        if (lp_wins_support()) {
                /*
                 * We're providing WINS support. Call ourselves so
                 * long as we're not nmbd.
                 */
                extern struct in_addr loopback_ip;
                wins_ip = loopback_ip;
                wins_ismyip = True;
        } else if( wins_srv_count() < 1 ) {

Replace with:

        if (lp_wins_support()) {
                /*
                 * We're providing WINS support. Call ourselves so
                 * long as we're not nmbd.
                 */
                wins_ip = *iface_n_ip(0);
                wins_ismyip = True;
        } else if( wins_srv_count() < 1 ) {

This mirrors the code in nmbd/nmbd_subnetdb.c : create_subnets();

  else if(lp_we_are_a_wins_server())
  {
    /* Pick the first interface ip address as the WINS server ip. */
    unicast_ip = *iface_n_ip(0);
  }

I'm not thrilled with this either:  "knowing" that WINS will bind here
is not the best idea either.  I am only suggesting it as a stop-gap
measure until a more robust solution is available (see below).

> We sill need a way to control the way nmbd binds to interfaces, and to
> allow multiple nmbd servers per physical machine.  (People do
> multi-hosting like this).

Perhaps separating smb.conf into two (or more) files with the SMBD
configuration in smb.conf and the NMBD(s) configuration is nmb.conf.
Then, for example, the local SMBD children could use the "wins server="
configuration (with a local WINS server included as one of the multiple
NMBD servers) in smb.conf to support fail-over to other WINS servers.
Also, then the semantics of "interfaces=" would not be overloaded since
they would be in separate configurations.  Just a thought...

This is mostly just a logical separation though, since a similar
separation can be achieved with the "-s config file" command-line
option.  Although it seems pretty complicated to run multiple NMBD
servers on a single machine (like making sure they're each using
different "lock directory=" settings, for example).

Thanks,

Peter Hurley
phurley at imaginexd.com