nmbd incompatibility with NT 4.0 WINS w/ 1C records

[Bert Driehuis]

On Wed, 11 Feb 2004, Christopher R. Hertel wrote:

> To summarize, the bug you are reporting is that nmbd (2.2.8a) is ignoring
> refreshes for #1C group names unless the IP address is already registered
> as a group member.
>
> That it?

Yup. Right on the money.

> You said:
> > I'm wondering why a Refresh for an existing 0x1c record, that
> > the requestor is not yet a member of, isn't treated like a Register as
> > well.
>
> My *guess* (not having looked at the code) is that we handle the refresh
> by updating the TTL only.  So, if the names not there, we're not adding
> the missing IP address.  That's a complete guess.

That is a close description of what's happening: if the name is not
there, the IP address is ignored, but as an artifact of the order in
which the checks are made, a refresh of a 1C will result in an addition
if the entire record doesn't exist yet.

My wonder was directed more at the fact that the code looks like it does
what it does on purpose. If a record is nonexistent, it gets added
straight away, including if it's a group 0x1c record. I think the
original code assumed that NT would properly check the results of the
original Register and thus avoid refreshing a non-member IP address, and
that the case where the IP address is not be a member of the group
record would be a "can't happen" case.

> Please enter a bug report on this (bugzilla.samba.org) and let me know the
> bug ID.  Your fix looks like it may be correct (and I'm not above making
> the code more readable).  I will look it over.

Bug #1079.

> If you are correct that a refresh on a unique name causes the name to be
> registered, and that NT does it this way, then there's no reason that
> we should not do so as well for the 0x1C group names.

That is tangential to this issue. Any record that doesn't exist at all
(lookup returns namerec == NULL) is treated as a registration, whether
unique or group.

> If I make this fix, it will be fixed in 3.0.x (next release candidate) and
> will work its way into production from there.  It won't be in 2.2.8a, so
> you'll want to use your own patched version of that.

Fair enough! My only concern about running with private patches is that
they might hamper future software updates, which obviously won't be the
case if that future update incorporates the private changes.

Cheers,

				-- Bert
-- 
Bert Driehuis -- driehuis at playbeing.org -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!