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

[Andrew Bartlett]

On Mon, 2003-02-17 at 14:02, Peter Hurley wrote:
> > >
> > > When running a WINS server using the following configuration:
> > > 	[global]
> > > 	wins support = yes
> > > 	interfaces = 192.168.1.0/24
> > > 	bind interfaces only = true
> > > the WINS server erroneously discards 127.0.0.1 requests from SMBD
> > > children.  This happens whenever libsmb/resolve_wins() is called.  I
> ran
> > > into this trying to understand why bringing up a Print dialog would
> take
> > > > 6 secs, but I would guess that there are other places this would
> come
> > > up.
> > 
> > I don't see how this is erroneous.  If you specifically configure
> Samba
> > not to listen on an interface, I might imagine that it might just
> happen
> > to not listen on that interface.  The documentation is quite clear on
> > this matter - you really should include localhost in your interface
> > list.
> >
> 
> 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.

> 2) "interfaces=" is an overloaded option.  Setting the loopback address
> in "interfaces=" has both SMBD and NMBD listening to it.  But in the
> default mode, SMBD will only listen to all broadcast addresses EXCEPT
> loopback, whereas NMBD will listen to every address.

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


> 3) I've seen quite a few misconfigured "interfaces=".  I think this is
> probably a very common oversight that goes largely undetected.  In my
> case, I was running this misconfiguration on one server for two years,
> and on another for 9 mos.  It was only because I decided to seriously
> bulldog a seemlingly unrelated problem (long time to bring up Print
> dialog) that I uncovered the misconfiguration for myself.

I think that some extra testparm logic would go a long way here. 

> 4) I believe this to be the most serious.  The only indication that
> something is wrong is that things run slow or sporadically slow.  But
> slow-running stuff is hard to diagnose.  It could be network hardware,
> server hardware, misconfigured network hardware, corrupted firewalls,
> complex multi-subnet installations, etc.  The security-conscious (a lot
> of people) are going to and do use "bind interfaces only = yes", without
> realizing all the ramifications.
> 
> A lot of posts on the samba list are about complex problems that start:
> it's running slow.  Remember the thread, "How Samba let us down"?  Quite
> a furor:  interestingly, Chris de Vidal states in his e-mail of 23
> October 2002, 10:46:29, "I did try WINS in testing;.... I would see
> "WINS server appears to be down"...Have you seen better documents on
> implementing Samba WINS..."
> 
> 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.  

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

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030218/0c5ffe43/attachment.bin