Bug 1079 - nmbd incompatibility with NT 4.0 WINS w/ 1C records
Summary: nmbd incompatibility with NT 4.0 WINS w/ 1C records
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: nmbd (show other bugs)
Version: 3.0.0
Hardware: All FreeBSD
: P3 normal
Target Milestone: none
Assignee: Christophuzzy R. Hertel
QA Contact:
Depends on:
Reported: 2004-02-15 17:00 UTC by Bert Driehuis
Modified: 2005-08-24 10:21 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Bert Driehuis 2004-02-15 17:00:25 UTC
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);
Comment 1 Gerald (Jerry) Carter (dead mail address) 2004-02-17 09:02:24 UTC
movning to samba 3.0
Comment 2 Christophuzzy R. Hertel 2004-03-04 11:40:28 UTC
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
Comment 3 Christophuzzy R. Hertel 2004-03-12 12:59:48 UTC
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.
Comment 4 Gerald (Jerry) Carter (dead mail address) 2004-03-15 08:55:58 UTC
adding myself to CC list.  Need to test and get this into 3.0 before 3.0.3
Comment 5 Christophuzzy R. Hertel 2004-06-07 11:16:27 UTC
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.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:21:28 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.