Samba Traffic #14 For 1 Mar 2000

By Peter Samuelson

Table Of Contents


The theme of the week has been Windows95. In the ever-exciting SAMBA_TNG code branch, Windows95 support has been on back burner for quite some time. (See BROKEN KCREF for why this might be the case.) Much of this week's list traffic has been about getting Windows95 to work with SAMBA_TNG again. Good news for some people out there, to be sure. [Note that Windows98, from the perspective of a Samba server, is very nearly identical to Windows95, so generally when we say "Windows95" we mean both of them.]

Mailing List Stats For This Week

We looked at 454 posts in 883K.

There were 145 different contributors. 53 posted more than once. 44 posted last week too.

The top posters of the week were:

1. VMware Fixes License Violation

26 Feb 2000 (1 post) Archive Link: "Samba in VMware (Was: Another GPL violation?)"

People: Regis DuchesneGreg Dickie

Maybe it was Greg Dickie's original e-mail to VMware. Maybe it was our coverage in BROKEN KCREF. Maybe it was the Linux Weekly News coverage ( of our coverage. One way or another, something got VMware's attention with regard to their Samba licensing issue. Regis Duchesne of VMware posted this note to samba-ntdom:

I just wanted to let you know that your voices have been heard, and that the next release of VMware will do the following:

  1. A file called SAMBA-LICENSE will be always installed in <DOCDIR> (/usr/doc/vmware by default) when VMware is installed.

    This file contains:

    1. A header from VMware explaining where (URL) to find VMware diffs to the Samba source version 2.0.6
    2. The full content of the file COPYING (GPL v 2) included in the Samba source version 2.0.6

  2. At configuration time of VMware, if the user decides to use the Samba server binary modified by VMware, he will be pointed at the file described in 1)

Again, sorry for the delay, but we are at least as busy as you guys are :)

[While we commend VMware for taking the time to deal with this, we are not really surprised. Years ago we used to worry about what would happen when a company tried to violate the GPL either from carelessness or for competitive reasons. Would we notice? Who would sue them? Would the court system uphold the GPL, or could a company just get away with it? More recently it has been demonstrated, in several cases like this one, that we needn't have worried. Companies tend to realize that their reputations are much more important than whatever they might hope to gain by violating open-source licenses.]

2. Windows95 and Beer

18 Feb 2000 - 21 Feb 2000 (85 posts) Archive Link: "TNG works with Win2k, fails with Win98"

People: Pat LoPrestiLonnie BorntregerLuke LeightonRichard SharpeGreg LeblancKarl Denninger

Pat LoPresti kicked this one off on samba-ntdom. He wrote: "We have been authenticating Win98 users against Samba 2.0.5a for a long time, but I need a real PDC by next week (ahem) or the Powers That Be just might start imposing a real NT infrastructure." He tried SAMBA_TNG and it worked fine with Windows 2000, but unfortunately, none of his Windows98 clients could log in. He was more than willing to help track down the problem: "I have a 55K level 10 debug log of the entire failed effort; I would be glad to send that and my smb.conf to any interested parties. I am also a reasonably competent C hacker with lots of spare time available this weekend..."

Now it happens that this is a known problem; people have been complaining off and on for quite some time about SAMBA_TNG botching the Windows95/Windows98 logon procedure. The person best qualified to fix this, Luke Leighton, is counted among the Windows95-haters of the world, and refuses to install that on any of his machines for testing. Some time ago he offered to fix the problem but only if someone could get him network traces of a Windows95 machine logging into an NT domain controller. Lonnie Borntreger noted this, and added: "I've asked for someone to do that trace several times in the last 4-6 months, and no-one has stepped forward and done it." Pat was puzzled: "Why is this necessary? I can authenticate 98 against Samba 2.0.x just fine; why is a netmon trace of that process not sufficient? Or, why can't TNG authenticate 98 machines the same way 2.0.x does?" Luke explained: "i specifically need to know EXACTLY what the difference between a win9x UDP 138 request and an nt one (GETDC and SAMQUERY) and i need to know what the responses are --- from an nt server. samba is not sufficient for this task."

Richard Sharpe decided to try his hand at debugging the problem, though not for lack of other things to do. He had network traces and started reading them. "Samba-TNG has no problems with the logon request being sent by Win95, and even returns a response that Win95 can understand. However, when Win95 tries to connect to IPC$ using a SessionSetup&X, Samba-TNG returns a bad password response. This seems to be a problem with the LM# that Win95 is sending, and perhaps Samba-TNG is expecting an NT#." Pat was excited: "If you get this working within the week, a case of beer (*) of your choice is on me. I do not know how I will get it to Australia, but I will find a way."

Richard and Luke went back and forth a bit hunting the bug. Some eight hours later, Richard found it:

Luke, You IDIOT!

When you cut and paste, you have to make sure you fix up the variable names.

All it was that was preventing Win9X clients from logging in and accessing Samba TNG was that you were calculating MIN(nt_chal_len, sizeof(lm_owf)) when that should have been lm_chal_len!! Of course it was zero and as a result you were passing through an initialized buffer instead of the lm_chal_resp!


In another message, he claimed his case of beer:

Now, from Win98 I get:

You were successfully logged on to SAMBA1 as win95user by \\LINSRV1 with USER privilege.

Make it Sam Bass please. We drink real beer here in Oz :-) Actually, I would not advise sending a case of beer to OZ. Keep it until I get to a conference in the US! Then we can share it among the members of the team who are there.

Pat replied with a partial success report: "OK, current CVS works a lot better, but I still have two problems. First, my Win98 machine still fails to log on the first time I try, but works the second and subsequent times. I am not even re-typing the password; I just click "OK" the second time and it works. If, after it is working, I wait a few minutes *or* try to log on as someone else, it again fails once and then succeeds. Second, my netlogon script is not running for Win98 nor for Win2k (is it even supposed to for the latter?)." He later found and fixed the latter bug: "I think I found the bug. In sampass.c:getsamfile21pwent(), you are checking a bunch of char *'s in the "user" structure against NULL to see if you need to fill them in. The problem is that they aren't NULL, they are just empty; so things like the logon_script field end up empty instead of acquiring their proper values from the smb.conf file. When I fixed this, my logon scripts started working again." He appended a patch, which Luke acknowledged.

As for his one remaining problem, the intermittent login failures, he and Luke narrowed it down over the course of a few messages. Ultimately, it turned out to be a problem with Pat's CVS checkout. As Luke explained: "check param/loadparm.c it should have machine_trust_password_timeout = 60*60*24*7, if there's a line saying =60, you got a cvs update just when i was doing some tests :)" This is indeed what happened: Pat's Samba server was changing trust account passwords once a minute instead of once a week. Luke continued: "however... it seems like you've brought up a really important point: there is a race condition that can result in intermittent login failures. hmmm.... hmmm..... how am i going to fix this? i store the old value, but that's kind-of tacky, reading new value of $MACHINE.ACC and old value of $MACHINE.ACC and checking two logins!" [...] "thanks for finding this, it would have been one of those bitch-to-find bugs as it would only come up once a week." A reasonable fix, he decided, would be if the server only changed its trust account password when it wasn't in use. Finding such a window of opportunity once a week should not be a problem, he concluded.

In another thread ( , Greg Leblanc asked for a recap of the issue so far: "I read all the messages, but I'm still not clear. What is and isn't working with regards to Win9x machines logging into a TNG PDC? If it's not working, do you guys still need a netmon trace? I'm at work today with my PDC and 250 workstations, so I can get any kind of login traces you might want, but that's not to say that I can make heads or tails of them." Luke summarized: "richard fixed auth over the weekend. someone else reported printing not working (needs more details). usrmgr.exe and srvmgr.exe (win95 versions) don't work, probably related to GETDC request not being right." As for the GETDC ("get domain dontroller") response, Richard figured out that apparently you have to return different information depending on who is asking (NT or Windows95) -- sending back too much information to Windows95 seems to confuse it.

Karl Denninger reported trouble building SAMBA_TNG; his compiler was crashing. Even bad input should never crash your compiler, though, so when that happens there's either a compiler bug or a hardware glitch.

Karl also complained that profiles were not working. Luke knew why: "*sigh*. you're now at the stage everyone else is, where the fact that the NETLOGON connection, over which the profile is obtained, is on an anonymous SMB session. therefore, the profile returned is that of the guest user -- for every single user." A short time later he added: "karl just did a reasonably good hack-fix for it :) i'm cvs committing right now."

3. LDAP and the Legendary Feature Freeze

21 Feb 2000 (8 posts) Archive Link: "[RFC] LDAP user management tools"

People: Inge-Håvard HunstadJerry CarterLuke LeightonSander Striker

Jerry Carter, some time ago, mentioned that he was working on some tools to manage users in an LDAP database. So now Inge-Håvard Hunstad wanted to know how Jerry was getting along on this: "Was the interest so low that it wasn't worth finishing or did you try to implement it and have a tool ready for alpha or beta testing? If the latter is true then I'm willing to try it:)" Jerry answered, "Well...I wrote an initial script and got distracted by other things. Right now we are in the processing of pushing into LDAP very hard. So I've picked it back up. It's not ready for any release yet. Only command line driven at the moment (no GUI stuff)."

But the thread started to get interesting when Luke Leighton joined in. He looked at Jerry's original post and it reminded him of something he had thought of before but never implemented: "a much more, f you're asking my opinion, noteworthy and fairly easy task, would be to take the display_*.c code and add a switch to print html as well as text. that was actually the original intention, except i never got round to doing the html. then, making these programs run as a swat-like daemon is absolutely trivial. hmm. an interesting, intriguing project :)"

Sander Striker thought he saw it coming. "No Luke No. Not a new idea, please... :-)" Luke's response: "it's not, it's an old one (over 2 years), re-voiced." Sander: "Ok. Ok. You win, just put it in the freezer for now, until after the big code freeze. Any ideas on when this is expected?"

As regular readers will recall from BROKEN KCREF, there have been rumblings about feature-freezing the SAMBA_TNG branch for some time, and lately even Luke has been amenable to the idea, with reservations. In this thread, though, he went further than before:

well, i've basically been idling along now for over a week, just tinkering and fixing things that people report. so it's kind-of already in effect.

if i get bored, there's always samrtdb (which doesn't affect anyone else but me, it's not enabled by default).

i'm still taking in code clean-ups and mini-useful stuff from elrond, sander and others.

i still have the "reestablish dce/rpc connection" code to do,i haven't even started investigating this, i'm still thinking about it [including whether to do it].

what else.. there's still a surs implementation to do, and that's a simple, simple bit of code -- behind an API, in a separate library anyway.

Sander Striker thought he understood that last sentence. "Heh heh, so you can freeze and still play around :-)" Luke: "damn, someone noticed."

[This is probably as good a place as any to mention that Luke took issue with our characterization of him in Issue #11 (sm20000210_11.html#0) , where we said, "One can tell that he simply doesn't think in terms of release management." What we meant, of course, is that from recent-past behavior he does not appear to think in terms of release management. Our perception is definitely changing, as he has started pushing out alpha releases of TNG. Besides, the last time he announced an overhaul of a major Samba subsystem was at least two weeks ago; he must be serious this time. We must confess that until recently we did not realize Luke had it in him to behave this way. Frankly, we are impressed.]

4. Auto-Generating RPC Interface Stubs

21 Feb 2000 - 22 Feb 2000 (11 posts) Archive Link: "(M)IDL compiler"

People: Luke LeightonSander StrikerMatt Chapman

For some time, Samba people have talked about the RPC function interfaces in SAMBA_TNG. Every distinct RPC call needed by Samba has two interfaces, the client side and the server side. In between, there is the wire protocol -- the actual arrangement of bits that flow across the network. The interfaces have to convert between the wire protocol and the internal Samba data structures, and currently each interface has to take care of this individually, causing code duplication and endless possibilities for bugs.

Luke Leighton has long been wishing for a way of automatically generating these interface functions from simple templates, which would be written in an interface definition language (IDL). (This would correspond roughly to the XDR layer in Sun/ONC RPC.) The problem is finding or creating a compiler for the IDL. Luke asked the general population of samba-technical: "there were a couple of people i know who were interested in such a project. please speak now (again), on samba-technical, if you were or are." He continued, "i'm well aware of the disadvantages of maintaining, manipulating and adding to 56 THOUSAND lines of hand-crafted msrpc marshalling / unmarshalling and smb-interface code. if 40,000 of that can be replaced with auto-generated code i will be WELL happy."

Sander Striker replied: "I'm currently working on an implementation of a MIDL (MS Interface Defenition Language) compiler. I still need to work out the details, because MIDL is underspecified. IDL, however, is fully specified; there is an BNF spec available. I'm now trying to incorporate the MS specific features of MIDL into IDL, for which I have a working parser. I will be posting a BNF spec of MIDL here, for MS techies to confirm (please do!). If anyone has already made the effort of creating a BNF spec of MIDL, I would be very grateful if I could use it for the development of the MIDL compiler." [Backus-Naur Format (BNF) is a convention for unambiguously communicating the context-free portion of a language's grammar. In other words, it allows one to specify exactly what components can be put together in what order to make a valid statement in a given language. BNF, along with Extended BNF, is the de facto standard way to express the syntax of a computer language.] He also posted a link to a BNF specification for the original IDL ( . Luke replied:

apparently, according to microsoft's MSDN RPC info, the only things are:

  1. no implementation of non-unique pointers. i.e all pointers are unique
  2. a type wchar_t - wide char (16-bit) for Unicode strings.

Matt Chapman chipped in with for the IDL used in DCE (the Distributed Computing Environment developed at the Open Software Foundation; DCE RPC is the foundation for Microsoft RPC).

Sander was happy to see the Open Group's IDL specification. "Great! This is exactly what I'm looking for. Looks like MIDL and DCE IDL are almost the same. A cpp_quote must be added, but at a first glance I'm pretty satisfied. I'll start working on this one whenever I get home tonight."

5. Using Long Usernames

21 Feb 2000 - 23 Feb 2000 (7 posts) Archive Link: "Long User names"

People: David BannonOndrej HanakLuke Leighton

David Bannon had a question for samba-ntdom: "Who knows about length of user name limits ? I have been using an old (Oct99) NTDom stream version in a production situation (NT4sp4) and have just found that our IT department is making student logon names as long as 15 characters." He explained that users with long usernames were able to log in, but could not map their home directories.

Luke Leighton thought it might be a limitation of the underlying Unix system. (Traditional Unix had an eight-character limit on the lengths of usernames and passwords. This is why ls -l uses the field widths it does for the names of users and groups.)

But Ondrej Hanak had more details on the situation at hand: "Users with too long (e.g. 13 chars) usernames (cause big change from NT server to SAMBA, all users we accomodated on Linux) did't have H: drive mapped as others. I can see that user's home of his/her name in share list, but after effort to connect to this share error message appeared: "Can't find share name..." I solved this problem by mapping homes in user's login script (net use h: \\server\homes). Can anybody explain what's wrong?" Luke could: "ah! that is a limitation of NT - 12 chars is the maximum share length. you can change the location of profiles to \\server\homedirs\%L\profile and the problem will go away." Almost as an afterthought: "or upgrade to nt5, and the problem will go away."

6. More SAMBA_TNG Debugging

22 Feb 2000 - 23 Feb 2000 (12 posts) Archive Link: "joining a domain works, but login fails"

People: Lars KneschkeGeorge CameronPierre HjälmLuke Leighton

Lars Kneschke, maintainer of the Samba-TNG FAQ ( , was trying to update the FAQ, but got stuck while installing a fresh copy of TNG. He posted to samba-ntdom: "I can join the domain, using the join dialog from networksettings(under windows nt). I have not created a workstation trustaccount with rpcclient before. I created a password entry for root in smbpasswd and created a unix user for the workstation. After that i was able to join the domain. But after reboot i was not able to login. The error message was: computer account does not exist or the password is wrong. (translated from german) I can't find something wrong in the log.files." He also reported a bus error crash with rpcclient.

George Cameron replied, "I think there may be a bug in samedit where it incorrectly uses pdc's username+password for the local machine, but it works if they happen to be the same (and as long as you remember to update your, which I hadn't!)." As for the rpcclient crash, he said:

There seems to be a problem in the code page code. If you comment out the call in lib/cmd_interp.c :

#if 0

(line 1475 in my version, recently updated), the command line programs should work again, and stop overwriting the binaries with zero-length files :-o

Pierre Hjälm tracked down the actual rpcclient bug. "Actually, it's a problem with the debugging/logging code. Someone (no names) decided it would be a good idea to take the name for the log file from argv[0]. That works if you happen to have rpcclient in your PATH but if you have to start it by giving the whole path to it, it will overwrite the binary." Luke replied, "that explains why ... *muur*! can u try 2 fix it and send me a diff -u patch? thx" The source file client/client.c from a recent TNG checkout appears to still have the bug as we go to press.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.