In the face of network unreliability, nmbd may refuse to add a BDC to the 0x1c
record for the domain, where NT WINS works as expected.
The way NT registers a BDC relies on the first WINS Register succeeding. If that
single network packet is lost, NT will later try to register the BDC using
Refresh packets. Nmbd ignores those refreshes, unless the group record doesn't
yet exist. Apparently, a WINS server on NT 4.0 will honor such a Refresh packet
to add the BDC's IP to the 1C record.
The proposed patch treats a Refresh of an existing 1C group record, that doesn't
yet have the IP address of the BDC as a member, as a Register.
*** nmbd_winsserver.c Fri Mar 14 22:34:48 2003
--- /var/tmp/nmbd_winsserver.c Thu Feb 5 19:14:20 2004
*** 479,482 ****
--- 479,489 ----
send_wins_name_registration_response(0, ttl, p);
wins_hook("refresh", namerec, ttl);
+ else if((group && (question->name_type == 0x1c)))
+ DEBUG(3,("wins_process_name_refresh_request: Name refresh for name %s and \
+ the IP is not yet associated with the name. Treating as registration.\n",
movning to samba 3.0
This is an odd corner case having to do with <1C> group names (DC names). <1C>
group names are called (by MS) "Internet Special Groups", which means that
Microsoft's WINS servers will attempt to handle these names in something
approximating an RFC1001/1002 compliant manner.
The problem being reported here is this: If an initial registration sent by one
of the group members is lost (network error, whatever) then subsequent refreshes
from that particular machine will also fail. This only happens if the name is
already active (because of other group members).
In most cases, we (and MS) handle refreshes as registrations if the name is not
in the database. In this situation, we missed the corner case.
In our code (the code I'm fixing), when a <1C> refresh comes in...
- If the name does not exist at all, then the refresh is handled
as a registration.
- If the name exists but is inactive, clear the inactive name and
handle the refresh as a name registration.
- For unique and <1C> names, if the IP is in the list of IPs for
the name, then we update the TTL. That's it. This is okay for
unique names with multiple IP addresses (eg. multi-homed hosts)
but for <1C> names we should add the IP if it's not in the list.
...and that's why some <1C> names don't get registered when they should get
The proposed fix looks good. I'm adding it to Head and then will port it to
I have submitted a fix to HEAD but I don't have the testing environment needed
to test the fix. I'm working on some tools. Others may want to test this fix
and move it to 3.0.x.
adding myself to CC list. Need to test and get this into 3.0 before 3.0.3
This fix is now in the production code, so I assume it met with Jerry's
approval. I have not been able to build a test environment to test it to my own
liking, but I was confident in Bert's analysis and patch.
Time to close this one.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.