samba - Jun 2009 - why is my "nmbd" confused about network interfaces?

The only thing related to 'addresses' in my
/etc/samba/smb.conf file is a "hosts allow":
         hosts allow = 192.168.3.0/24 127.1

I'm going to ignore the 'local hosts case, as if I solve the other,
the localhost case may get solved by inference.

I thought the 'hosts allow' would allow any host on the
local 192.168.3.0/24 subnet.

The hosts have no problems that I'm aware of, but 'nmbd'
is issuing confused messages in the log.

Upon starting it tries (and successfully) becomes the
For the local subnet, it starts out trying to become master on subnet
'192.168.3.1', but isn't the subnet 192.168.3.0?

The it gets further errors and eventually fails:

nmbd:  become_domain_master_browser_bcast:
nmbd:  Attempting to become domain master browser on workgroup BLISS \
        on subnet 192.168.3.1
nmbd: nmbd/nmbd_become_dmb.c:become_domain_master_browser_bcast(304)
nmbd:  become_domain_master_browser_bcast: querying subnet 192.168.3.1 \
        for domain master browser on workgroup BLISS
nmbd:  libsmb/nmblib.c:send_udp(839)
nmbd:   Packet send failed to 192.168.3.255(137) ERRNO=Invalid argument
nmbd:  nmbd/nmbd_packets.c:send_netbios_packet(160)
nmbd:  libsmb/nmblib.c:send_udp(839)
nmbd:   Packet send failed to 192.168.3.255(137) ERRNO=Invalid argument
nmbd:  nmbd/nmbd_packets.c:send_netbios_packet(160)
nmbd:   send_netbios_packet: send_packet() to IP 192.168.3.255 port 137 failed
nmbd:  nmbd/nmbd_namequery.c:query_name(244)
nmbd:  query_name: Failed to send packet trying to query name BLISS<1d>

My local 'ifconfig for eth0' shows my inet params as:
           inet addr:192.168.3.1  Bcast:192.168.3.255  Mask:255.255.255.0

So it would 'seem' to be in order.

Any ideas why I am getting this repetitive failure?

If nmbd successfully becomes the master-browser, will it stop retrying
every 5 minutes (*crossing fingers*)?

Thanks,
Linda

Previously I wrote (abbreviated msg summary):
> nmbd: become_domain_master_browser_bcast: Attempting to become dom mast \
>   browser, wrkgrp BLISS, subnet 192.168.3.1;  nmbd/nmbd_become_dmb.c: \
>   become_domain_master_browser_bcast(304)
> become_dom_master_browser_bcast: querying subnet 192.168.3.1 for \
>	dom mastr brwsr on wrkgrp BLISS
> 2 x {
> libsmb/nmblib.c:send_udp(839);  Packet send failed to 192.168.3.255(137) \ 
>  ERRNO=Invalid argument; nmbd/nmbd_packets.c:send_netbios_packet(160) }
> }
> send_netbios_packet: send_packet() to IP 192.168.3.255 port 137 failed
> nmbd/nmbd_namequery.c:query_name(244);  query_name: Failed to send \
>   pckt trying to query name BLISS<1d>
--------

Looking at traffic from the originating machine, on port 137, I see:
	Source	Dest.	Proto	Info
4 x {	#Note: ISHTAR="primary hostname", others are aliases
	for $HOSTNAME$ in ISHTAR, WEB-PROXY, CLOCK, WPAD; see {
		Ishtar	bcast	NBNS	Registration NB $HOSTNAME$<20>
		Ishtar	bcast	NBNS	Registration NB $HOSTNAME$<03>
		Ishtar	bcast	NBNS	Registration NB $HOSTNAME$<00>
	}
	Then 3 lines for $HOSTNAME$=BLISS (domain name), but with
	suffix values of:
		<00>, <1e>, <1c>
}
About 31 seconds later, I see some client interaction with some valid
	and an 'invalid' (or potentially misleading) response(?):
	Source	Dest.	Proto	Info
	Athena	Ishtar	NBNS	Name query NB BLISS<1c>
	Ishtar	Athena	NBNS	Name query response NB 192.168.3.1
	Athena	Ishtar	NBNS	Name query NB BLISS<1b>
	Ishtar	Athena	NBNS	Name query response NB 127.0.0.2
At about 608.2 second intervals, there were 4 repetitions of the above
4 lines (when I terminated monitoring).

1st Observation -- There is nothing on the line indicating what the
	parameter ERROR is that is being returned in the log
2) Should NMBD be 'advertising' to other hosts that it is a master
	browser for 127.0.0.2?  It seems it should limit that information
	to any 'clients' on the host, but not broadcast that to other
	hosts, as their 'localnet', if it had more than one host (i.e.
	virtual hosts) would be 'local' to those other hosts -- i.e. I'm
	not sure it would be a global NBNS for other host's "local
subnets"
	(which would be virtual 'vmnets', I believe...no?)