problem with source addresses for remote browser sync

Eric V. Smith eric at trueblade.com
Thu Jan 20 02:08:15 GMT 2005


I'm running 3.0.10 on FC2.

I posted this today on samba at lists.samba.org, but it occurs to me that 
this might be a more appropriate place, since it's more programmer-y and 
less end-user-y.  The original message is at the end of this one.  It 
contains some specifics about my problem.

But the root of the problem is that when doing a remote browser sync, 
the announcement is done by browse_sync_remote().  It ends up doing a 
send_mailslot(), which ends up using the source address specified by my 
smb.conf "interfaces=" parameter (by way of a call to 
find_subnet_mailslot_fd_for_address()).  This is actually the behavior I 
want.

But when the actual sync is done (as opposed to the announcement), it 
uses sync_child(), in nmbd_synclists.c.  This in turn calls 
cli_session_setup(), etc., which ultimately calls open_socket_out() with 
the address of the machine identified by "remote browse sync".  My 
problem is that this picks a different source address than the 
send_mailslot() call does.  This is confusing my VPN setup (see below), 
because now I have a mixture of internal and external source addresses 
being used; one set for the initial announcement, and the other for the 
actual syncing.

What I'd really like to do is specify an interface and/or address to be 
used for the source address for both the browse sync announcement and 
the actual syncing.  Short of that, I'd like to at least use the same 
source address for the syncing that was chosen for the announcement.

Both of these look like they'll require some surgery to the cli_xxx() 
functions and to open_socket_out(), if nothing else.  I don't mind doing 
this work, but before I do I'd like to find out if anyone here has any 
preference on the best way to do this.  I suspect the easiest thing to 
do is pass a source address (and port?) in to open_socket_out(), and 
bind to it if it's non-NULL or zero or something (INADDR_ANY, maybe). 
Then somehow I'd have to select the address that was used by the 
announce call, which looks like FIRST_SUBNET->myip.  But specifying a 
source address in smb.conf is more flexible, and I can see situations 
where that might be better.  However, doing that seems more invasive, 
since I'd have to do the work to cli_xxx() and to the send_mailslot() code.

Any suggestions or pointers on how best to proceed?

Thanks for your time.  I hope this wasn't too long.

Eric.




---------------------------

I have a network configuration where I have 2 hosts, A and B.  Each has 
a local LAN on which the run Samba, plus they're connected by a VPN.  So 
has A has addresses lanA and wanA, and host B has addresses lanB and 
wanB.  Because of the way the VPN works, they can talk to each other 
either via their LAN addresses (lanA <-> lanB), or their WAN addresses 
(wanA <-> wanB), but not lanA <-> wanB, or lanB <-> wanA.  Each host has 
only their LAN interface in smb.conf, and has "bind interfaces only = 
yes".  Everything relating to smbd works great.

I'm trying to set up host A as a domain master browser, and host B as a 
local master browser.  This works fine, until they try to sync the 
browse list.  They register with each other correctly because 
nmbd/nmbd_sendannounce.c's browse_sync_remote is binding to the LAN address:

send_mailslot(True, BROWSE_MAILSLOT, outbuf,PTR_DIFF(p,outbuf),
               global_myname(), 0x0, "*", 0x0, addr, FIRST_SUBNET->myip, 
DGRAM_PORT);

So I have "remote browse sync" set to the other hosts's LAN address, 
because the source address must local host's LAN address 
(FIRST_SUBNET->myip).  I've verified that each host sees the other's 
browse sync request.

So that's all well and good, but the actual sync happens in 
nmbd_synclists.c's sync_child().  It isn't doing any bind() or anything 
to set the source address, so it is sending data from wanA to lanB, but 
that doesn't work in my case.

Is there any way to control the source address that sync_child() uses? 
Any other suggestions?



More information about the samba-technical mailing list