nmbd using the wrong source address upon sending Node Status requests

[Christopher R. Hertel]

On Thu, Apr 24, 2003 at 06:00:50PM +0200, Volker Lendecke wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi!
> 
> Being a LMB nmbd has to send out a node status request to the DMB to
> find its real name to send as called name. This is done from the wrong
> source ip address if we use 'bind interfaces only = yes' to a virtual
> interface. This is needed if you want to run several LMBs on a machine
> or in a cluster environment.
> 
> The node status request goes out with the main interface's IP address
> as the socket used to send the UDP packet is bound to 0.0.0.0 and nmbd
> will not receive this. I have not really followed why we ignore the
> reply.
> 
> I can supply logs, sniffs & confs upon request.
> 
> I have a little proof of concept patch that revives the socket address
> parameter for this purpose:
> 
> Index: source/nmbd/nmbd.c
> ===================================================================
> RCS file: /space/vl/cvstree/samba/source/nmbd/nmbd.c,v
> retrieving revision 1.105.2.21
> diff -u -r1.105.2.21 nmbd.c
> - --- source/nmbd/nmbd.c	30 Mar 2003 23:04:17 -0000	1.105.2.21
> +++ source/nmbd/nmbd.c	24 Apr 2003 15:20:55 -0000
> @@ -532,7 +532,7 @@
>     */
>  
>    if ( isdaemon )
> - -    ClientNMB = open_socket_in(SOCK_DGRAM, port,0,0,True);
> +    ClientNMB = open_socket_in(SOCK_DGRAM, port,0,interpret_addr(lp_socket_address()),True);
>    else
>      ClientNMB = 0;
>    
> There was some discussion on irc that this might be not the right
> solution as 'socket address' is now deprecated. But what is the right
> one to this rather obvious bug? This *definitely* needs fixing. Why is
> 'socket address' deprecated in the first place?

As Volker says, the problem is that we send the NBT Node Status query from 
0.0.0.0.  The outbound packet is then assigned the address of the 
interface from which it is actually sent (which depends upon the routing).

So, by sending from 0.0.0.0, the source address may be one to which Samba
is not bound.  As a result we are, essentially, spoofing the packet.  The
reply will then arrive on an interface to which Samba is not bound and
will, therefore, be ignored (we probably don't even put it into
unexpected.tdb).

Volker's solution is to use the "socket address" parameter, and bind the 
outbound socket to the interface specified by the "socket address".  Doing 
this proves that he's got the right diagnosis.  I think, though, that the 
better solution might be to choose the first address in the "interfaces" 
list, if such is defined (if not, using 0.0.0.0 will be okay).

Using the first "interfaces" entry means that "socket address" can remain 
depricated, and it also means that the sysadmin doesn't have to think 
about configuring the "socket address" parameter.

I also thought about running through the list of interfaces to see if one 
of them was on the same subnet as the destination address.  Volker pointed 
out, however, that in the case he's dealing with the Node Status is being 
sent to a node on a separate network.  We would wind up needing to dig 
into the routing table to find useful information.  Ick.  Probably not a 
good idea...

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org