Bug 97 - nmbd from samba classic and TNG on one box
Summary: nmbd from samba classic and TNG on one box
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: nmbd (show other bugs)
Version: 3.0.0preX
Hardware: Other other
: P2 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-19 11:08 UTC by Elrond
Modified: 2005-02-07 07:56 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elrond 2003-05-19 11:08:08 UTC
This is a long known problem:

nmbd (from either classic or TNG) binds to 0.0.0.0:137.
Of course, only one process can bind to that port.
Even for "bind interfaces only = yes".

There obviously must be a reason for still letting it bind to 0.0.0.0 even for
bind interfaces only = yes. Something about receiving broadcasts I understand.

I see two generic solutions:
1) Make it possible to run both at the same time.
2) Run only one nmbd and make the other side "register" with that already 
   running nmbd.

About "register":
* This could either be by hand (editing smb.conf for the active nmbd and telling 
  it, that there is another thing on the same box, but different IP, etc.)
* Or it could be some dynamic form of registration, that is, smbd or whatever 
  could dynamicly register with the nmbd of the other side.
  For this version we would need to agree on a sane API...
  We might talk to crh on the API, if he has some ideas.
  If needed, I'll note in a later comment, how I define "sane".

One of the things I would like about this issue:
I don't want to be presented with a final thing in 3.0/head and a comment on the
lines of "We solved this, you might be interested in putting it into tng". I'd
rather appreciate the following things:
- discussion before.
- me helping coding.
- (possibly untested) patches for TNG.


    Elrond
Comment 1 Gerald (Jerry) Carter (dead mail address) 2003-08-09 15:36:45 UTC
taking this one over
Comment 2 Gerald (Jerry) Carter (dead mail address) 2003-08-27 13:01:24 UTC
Am not going to have time to address this before RC2.  Putting on the 
back burner temporarily.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2004-05-27 04:03:09 UTC
apparently no one is going to do anything with this. 
Sorry.
Comment 4 lkcl 2004-05-29 20:03:39 UTC
guys, you _know_ that it's necessary to create a proxy / NAT translation service
for NetBIOS port 137 and 138.

and it's really simple, too.

you manage connections to the proxy.

you use NAT translation on the nmb packet id.

you can then even split nmbd down into separate services and clients, create a
separate and _much simpler_ winsd daemon, create a separate "browserd", and the
problem of the "unexpected nmb packet" MELTS away.

please sort it out.
Comment 5 lkcl 2004-05-29 20:05:08 UTC
oh, and the wine project can play as well, rather than having to do what they do
at the moment, which is to ask people to DISABLE nmbd and they are writing THEIR
OWN version of nmbd because 1) LGPL and GPL incompatibilies (they can't use the
unexpected nmb packet interface, which is a stupid idea in the first place) 2)
there's no alternative input mechanism.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-02-07 07:56:57 UTC
originally reported against 3.0aph24.  Bugzilla spring cleaning.  
Removing old alpha versions.