NT_STATUS_ADDRESS_ALREADY_ASSOCIATED

[Günter Kukkukk]

Am Freitag, 4. Januar 2013, 05:32:42 schrieb Ricky Nance:
> The issue is if your system is using a port (say 53) then samba starts
> every service except DNS, without a fail or warning (except in the log
> files), this is quite an issue as you can imagine. I have worked with
> Guenter on this (who has done the real work) to discover the issue is
> actually in irpc_binding_handle_by_name() function, I think he has chatted
> with Tridge and Metze about this issue. For some reason the main samba task
> registers with a pid and task id of 0 (samba-tool processes confirms this
> behavior).  On a somewhat related note not all of the services are
> registered correctly with the irpc messenging system. I am sure there is
> much more to this that I am leaving out, so hopefully Guenter will fill in
> the missing pieces to the puzzle. I am not sure if there is a bug on this
> specific issue, I thought I filed one when I had this problem with slapd
> running then samba tried to run, it silently failed with odd errors.
> 
> The biggest issue now is that so many people have X running and
> NetworkManager is spawning DNSMasq, eating up port 53, then the internal
> DNS fails to start causing what appears to be a Kerberos issue, so then the
> user tries like mad to fix the kerberos issue, when in fact its DNS not
> handing out the right information, because DNS is actually DNSMasq... sound
> confusing?
> 
> I have seen different distro's using various other ports for some reason or
> another and it always ends up taking quite a bit of time trying to convince
> a user that its not the last error in the log, but the one stating that
> there is a port in use already.
> 
> Anyway this is so far beyond my programming ability it about makes my nose
> bleed just thinking about it, so I guess the point of the mail (if there is
> a point at all) is, if anyone has any insights to this potentially very
> complex issue, please share. And as always I truly appreciate the work you
> all do to make this software what it is!
> 
> Thanks in advance,
> Ricky
> --

well, i've not chatted with Tridge - but had some email exchange with metze.

I had a very close look at the sources regarding this issue - and all the
tasking, cluster, messaging and mode startup side-effects is 
unfortunately far "above my programming skills". :-(

The only time i carefully looked at this code in the past was some months ago when
the ldap service took about 4 minutes to start on opensuse (due to crypto calculations).

So i just put in here what i already sent to metze in my latest email (somewhat modified):

Atm the samba main-task does _not_ terminate, when a sub-task is terminating
in a FATAL way - but obviously it should - as documented:

-------------
source4/smbd/server.c
/*
  called when a fatal condition occurs in a child task  <<<=== !!!!
 */
static NTSTATUS samba_terminate(struct irpc_message *msg, 
                                struct samba_terminate *r)
{
        DEBUG(0,("samba_terminate: %s\n", r->in.reason));
        exit(1);
}

/*
  setup messaging for the top level samba (parent) task
 */
static NTSTATUS setup_parent_messaging(struct tevent_context *event_ctx, 
                                       struct loadparm_context *lp_ctx)
{
        struct imessaging_context *msg;
        NTSTATUS status;

        msg = imessaging_init(talloc_autofree_context(),
                              lp_ctx,
                              cluster_id(0, SAMBA_PARENT_TASKID), event_ctx, false);  <<<<== !!
        NT_STATUS_HAVE_NO_MEMORY(msg);

        status = irpc_add_name(msg, "samba");
        if (!NT_STATUS_IS_OK(status)) {
                return status;
        }

        status = IRPC_REGISTER(msg, irpc, SAMBA_TERMINATE,
                               samba_terminate, NULL);    <<<<<=== !!!!

        return status;
}
-------------------------

The samba main-task is started with "cluster_id(0, SAMBA_PARENT_TASKID)"
(see above), which results in:
struct server_id {
        uint64_t pid;
        uint32_t task_id;
        uint32_t vnn;
        uint64_t unique_id;
}/* [public] */;
that both "pid" and "task_id" are set to 0 (null)!

In the fatal case in 
./source4/smbd/service_task.c -> task_server_terminate()
a lookup for the irpc binding handle is done for the
registered (main) task "samba":
....
irpc_handle = irpc_binding_handle_by_name(task, task->msg_ctx,
                                                          "samba", &ndr_table_irpc);
....

That (main-) task "samba" is running, but no binding handle is returned,
always <nil>!

In irpc_binding_handle_by_name() an error check is done
  if (sids[0].pid == 0) {
which is always true for the "samba" main-task.
It's above my skills why that check is needed here.
(sure, all server_id arrays are usually terminated with
a final entry cluster_id(0, 0) )

struct dcerpc_binding_handle *irpc_binding_handle_by_name(TALLOC_CTX *mem_ctx,
                                         struct imessaging_context *msg_ctx,
                                         const char *dest_task,
                                         const struct ndr_interface_table *table)
 {
         struct dcerpc_binding_handle *h;
         struct server_id *sids;
         struct server_id sid;
 
         /* find the server task */
         sids = irpc_servers_byname(msg_ctx, mem_ctx, dest_task);
         if (sids == NULL) {
                 errno = EADDRNOTAVAIL;
                 return NULL;
         }
         if (sids[0].pid == 0) {         <<<<===== !!!!!! always TRUE for "samba"!
                 talloc_free(sids);
                 errno = EADDRNOTAVAIL;
                 return NULL;
         }
         sid = sids[0];
         talloc_free(sids);
 
         h = irpc_binding_handle(mem_ctx, msg_ctx,
                                 sid, table);
         if (h == NULL) {
                 return NULL;
         }
 
         return h;
}

Cheers, Günter