winbindd and missing 0x1c role on UNICAST_SUBNET

[Kevin Stefanik]

I'm trying to get winbindd working (2.2.6pre2) but it won't start because it 
claims to not find the domain controller (Samba as PDC) that the rest of the 
network is happily using.

-d10 output from winbindd:
Could not open a connection to U_MTPPI for \PIPE\lsarpc 
(NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)

Digging into the code, winbindd gets a list of domain controllers via 
broadcast and then confirms each directly with a unicast query to the 
controller itself (in cm_get_dc_name in winbindd_cm.c) specifically querying 
the 0x1c role.  That query is coming into nmbd as a unicast query.

from log.nmbd:
process_node_status_request: status request for name U_MTPPI<1c> from IP 
192.168.92.56 on subnet UNICAST_SUBNET.

Well, it seems that my nmbd isn't registering itself with a 0x1c on the 
UNICAST_SUBNET, because the GET_NEXT_SUBNET_INCLUDING_UNICAST macro (really 
the get_next_subnet_maybe_unicast function) only returns the unicast subnet 
as part of that linked list if the samba server is a WINS client.

So the domain controller is not responding to the request from winbindd.  
Winbindd fails to get secrets, and does not work.

If there's a way to make that query not come in as a unicast, then that's 
probably the best fix, but I don't know how, or even if it's possible.

So, I can either fix winbindd to not directly confirm 0x1c, but maybe just use 
another role (0x1e?) or fix nmbd to register 0x1c on the UNICAST_SUBNET by 
replacing the GET_NEXT_SUBNET_INCLUDING_UNICAST with an alternative 
implementation of that get_next_subnet_maybe_unicast that returns the 
UNICAST_SUBNET even when not a WINS client.  

What's best?  Does NT/2000/XP put itself on the UNICAST_SUBNET with the 0x1c 
role when it's acting as the PDC?

Thanks,
Kevin Stefanik