With recent linux kernel updates remote domain joins and some domain logons break when DCs use the "interfaces =" and the "bind interfaces = yes" parameters. In the test case, the PDC is at IP 192.168.10.23, a BDC is at 192.168.10.33, the remote BDCs are at 192.168.30.33 and 192.168.20.33. Local client network joins work perfectly. Remote joins fail. When the "interfaces =" and "bind interfaces = yes" parameters are removed from all DCs, remote joins and remote logons work without fail. Analysis of network captures shows that when the "interfaces =" and the "bind interfaces = yes" parameters are used the client does not get a response to the \MAILSLOT\NET\NETLOGON request over UDP 138. The nmbd log reports this sequence at the PDC (192.168.10.23): process_dgram: datagram from CLIENT<00> to DOMAIN<1c> IP 192.168.30.245 for \MAILSLOT\NET\NETLOGON of type 18 len=73process_logon_packet: Logon from 192.168.30.245: code = 0x12 process_logon_packet: LOGON_SAM_LOGON_REQUEST sidsize 0, len = 73 process_logon_packet: len = 73 PTR_DIFF(q, buf) = 65 process_logon_packet: LOGON_SAM_LOGON_REQUEST sidsize 0 ntv 11 process_logon_packet: LOGON_SAM_LOGON_REQUESTprocess_logon_packet: LOGON_SAM_LOGON_REQUEST request from CLIENT(192.168.30.245) for , returning logon svr \\PDCNAME domain DOMAIN code 13 token=ffff process_logon_packet: processing delayed initial logon reply for client CLIENT(192.168.30.245) send_mailslot: Sending to mailslot \MAILSLOT\NET\GETDC682 from PDCNAME<00> IP 127.0.0.2 to CLIENT<00> IP 192.168.30.245 Sending a packet of len 232 to (192.168.30.245) on port 138 Packet send failed to 192.168.31.245(138) ERRNO=Invalid argument Note: The PDCNAME address in the mailslot reply was 127.0.0.2. I do not know where nmbd obtains this address!!!!! When the "interfaces =" and "bind interfaces = yes" parameters are removed from all DC smb.conf files, the PDCNAME address is in the mailslot reply is returned like this: send_mailslot: Sending to mailslot \MAILSLOT\NET\GETDC682 from PDCNAME<00> IP 192.168.10.23 to CLIENT<00> IP 192.168.30.245 That is the correct reply and it works! Ergo: The use of "interfaces =" and "bind interfaces = yes" is broken for remote network clients. If we do not fix this, this breakage must be documented as a "do NOT use" parameter set. - John T.
I've come across another site that was bitten by the same problem. I do not want to elevate the severity level, but could we get some indication of when this might get looked at? If this is relegated to low priority we should at least update the man page to reflect a work-around. Agreed?
Hi John, could you paste the whole smb.conf? metze
Created attachment 4560 [details] PDC smb.conf file Attached is the smb.conf file for the PDC.
Created attachment 4561 [details] BDC smb.conf file - main office This is the smb.conf file for the BDC that is on the same network segment as the PDC.
Created attachment 4562 [details] Remote office BDC smb.conf file. This is the smb.conf file from one of the remote branch offices.
Created attachment 4850 [details] patch to honor all 127.0.0.0/8 as loopback addresses John, can you please give this patch a try? This will break "make test" as socketwrapper doesn't seem to like that 127.0.0.2 is not an ordinary IP then. It fixes similar issues for me like you have.
John: ping ... any results?
(In reply to comment #7) > John: ping ... any results? > I will contact the original site for approval to test this. Sorry about the delay.
AT long last and answer from the site. Samba will be shutdown June 1st. The entire site is in process of migrating to ADS and Windows Server 2008. With this decision made they saw no point in testing bug resolution. Jack - So sorry to have to report this. I was not getting replies to requests for permission to test the patch. - John T.
This problem persists in 3.5.2. It is NOT possible to join a Windows XP Pro, Vista (32 or 64), or Win7 (32 or 64) client to a Samba 3.5.x domain over a routed network connection IF the "interfaces" and "bind interfaces only" parameters are specified in smb.conf. It IS POSSIBLE to join these Windows clients to the Samba 3.5.x domain simply by removing the "interfaces" and "bind interfaces only" parameters. In my test case I had: Samba 3.5.2 at 172.16.10.20 172.16.10.0/24 (network) 172.16.10.24 (router) | | 192.168.3.30 (router) 192.168.3.0/24 (network) Windows 7 Pro 64 at 192.168.3.50 Note: I have a test environment that is available to any team member who wishes to investigate this further.
Please disregard my last update - firewall problem. It works!