Bug 6348 - Remote Domain Join breaks with "interfaces =" and "bind interfaces = yes"
Remote Domain Join breaks with "interfaces =" and "bind interfaces = yes"
Status: RESOLVED FIXED
Product: Samba 3.5
Classification: Unclassified
Component: Nmbd
unspecified
Other Linux
: P3 normal
: ---
Assigned To: Stefan Metzmacher
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-11 11:09 UTC by John H Terpstra
Modified: 2010-04-12 23:58 UTC (History)
5 users (show)

See Also:


Attachments
PDC smb.conf file (2.11 KB, text/plain)
2009-08-14 09:51 UTC, John H Terpstra
no flags Details
BDC smb.conf file - main office (1.60 KB, text/plain)
2009-08-14 09:52 UTC, John H Terpstra
no flags Details
Remote office BDC smb.conf file. (1.58 KB, text/plain)
2009-08-14 09:52 UTC, John H Terpstra
no flags Details
patch to honor all 127.0.0.0/8 as loopback addresses (1.10 KB, text/plain)
2009-10-15 03:36 UTC, Björn Jacke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John H Terpstra 2009-05-11 11:09:35 UTC
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.
Comment 1 John H Terpstra 2009-06-03 10:33:38 UTC
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?
Comment 2 Stefan Metzmacher 2009-06-03 11:16:31 UTC
Hi John,

could you paste the whole smb.conf?

metze
Comment 3 John H Terpstra 2009-08-14 09:51:02 UTC
Created attachment 4560 [details]
PDC smb.conf file

Attached is the smb.conf file for the PDC.
Comment 4 John H Terpstra 2009-08-14 09:52:17 UTC
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.
Comment 5 John H Terpstra 2009-08-14 09:52:56 UTC
Created attachment 4562 [details]
Remote office BDC smb.conf file.

This is the smb.conf file from one of the remote branch offices.
Comment 6 Björn Jacke 2009-10-15 03:36:10 UTC
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.
Comment 7 Björn Jacke 2009-11-18 07:27:21 UTC
John: ping ... any results?
Comment 8 John H Terpstra 2009-11-18 08:04:17 UTC
(In reply to comment #7)
> John: ping ... any results?
> 

I will contact the original site for approval to test this. Sorry about the delay.
Comment 9 John H Terpstra 2010-02-04 14:52:54 UTC
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.
Comment 10 John H Terpstra 2010-04-12 23:03:50 UTC
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.
Comment 11 John H Terpstra 2010-04-12 23:58:50 UTC
Please disregard my last update - firewall problem. It works!