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); + return; + } + 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", nmb_namestr(question) )); + wins_process_name_registration_request(subrec,p); return; }
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 registered. The proposed fix looks good. I'm adding it to Head and then will port it to 3.0.
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.