Samba Traffic #11 For 9 Feb 2000

By Peter Samuelson

Table Of Contents


This was the Week of the Great SAMBA_TNG Function Interface Overhaul. (Not to be confused with other weeks.) Luke Leighton and his Merry Men managed to make the SAMBA_TNG branch even more volatile than usual, as nearly every RPC-wire-protocol function was being adjusted to a new standard. (Recall that Microsoft DCE/RPC functions are what makes the world of NT domain service go 'round. That means there's a lot of RPC code in SAMBA_TNG!) It's official: even Luke admits that using the current code in production might not be a good idea right now.

Rumblings have started about possibly feature-freezing Luke's SAMBA_TNG code in preparation for merging some of his functionality into the more stable branches. At this point, Luke's reaction seems to be "sure, great idea, just let me finish up these three areas first ... wait, better add in this one here ... oh, and those other two as well...." One can tell that he simply doesn't think in terms of release management. Good thing Jeremy and Andrew are around.

Mailing List Stats For This Week

We looked at 500 posts in 1005K.

There were 186 different contributors. 69 posted more than once. 64 posted last week too.

The top posters of the week were:

1. RPC API Conversion Project in SAMBA_TNG

24 Jan 2000 - 27 Jan 2000 (8 posts) Archive Link: "coding volunteers needed for msrpc server-side API conversion"

People: Luke LeightonAnders ThorsenLuke Howard

Not too long ago, as mentioned in the introduction (sm20000203_10.html#general) to last week's issue, Luke Leighton got it into his head to revamp his SAMBA_TNG branch yet again. The goal this time was to produce an RPC client/server API identical to the one Microsoft uses in MSDN. He started by sending out (to samba-ntdom and samba-technical a general call-for-assistance:

if anyone wants to help with a very boring but basically self-consistent task, i'd really appreciate it. the goal is, examine rpc_client/cli_*.c functions, e.g samr_open_domain(), and create a srv_*.c function with EXACTLY the same paramaters called _samr_open_domain(), for all functions in rpc_client/cli_*.c and srv_*.c.

please see samba tng's rpc_server/srv_samr.c and samrd/srv_samr_passdb.c for examples of the code-conversion in progress. i cut/paste a section of proto.h from rpc_client/cli_samr.c into the top of samrd/srv_samr_passdb.c to make this job easier.

He posted some more detailed instructions about how people should coordinate their efforts and how they should submit their completed work to him, and ended with: "i will be chewing through srv_samr.c from the top: if anyone wants to start at the bottom and work up, i'll meet you somewhere in the middle :)"

Two days later he posted again. "ok, people, i _really_ need help with this. i estimate that if i work on this full-time it's going to take about... two weeks." He continued that current CVS was broken and would remain so until he finished this project. Finally, "i'm intending to replace the broken passdb/*.c and groupdb/*.c code with a proper samr implementation, but only after the samr conversion."

Various people volunteered to help with various subsystems. Anders Thorsen wasn't sure how to be useful: "Bear in mind that i'm not an expert on the samba internals, but want to help out with the basic tasks + I want to learn more about them." Luke answered the next day, giving a status report while he was at it:

excellent! ok, i suggest you start with browserd (which contains one function. examine wkssvcd first (comments etc). talk to sean millichamp and sander striker, who are also involved with this [wonderful, boring] task, and well, basically, divide the task between yourselves :)

elrond is doing lsarpc.

sander wanted to do svcctl because he is also wanting to improve it.

that leaves netlogo and srvsvc as the biggies, and i'll leave them up to you as to how you want to tackle those.

A day or so later, under cover of a new thread, Luke announced that the samr code was finished -- "untested, of course, except for a few minor bits / pieces." He launched into a tutorial of how to use the shiny new functions. Luke Howard, who is writing the new LDAP code (see Issue #9, Section #10 (sm20000127_9.html#10) ), asked for and got a clarification on some minor issues.

In the next few days several more people managed to get into the action. Luke Leighton's status report on Feb 3 was a bit complicated:

sander's doing netlogon conversion, he's just gone to sleep.

elrond's doing lsarpc conversion, he doesn't like the msdn api format, but then again, neither do any msdn developers like lsa_lookup_sids and lsa_lookup_names.

[elrond, would you be happy with a client-side "wrapper" function that looks like rpc_client/cli_lsarpc.c's lsa_lookup_names?]

sean millichamp's first foray into programming for a while resulted in srvsvc conversion, he even had fun doing it.

lars volunteered for srv_reg.c, and is having the same conceptual difficulties with the task to be carried out that sean used to have before sander explained in a mini HOWTO (Thx sander)!

luke howard hates passdb/*.c and groupdb/*.c as much as i do. he's not touched the pre-existing schema so he's created an nt5ldap schema. it all works, but falls down silly in exactly the same way that the smbpsswd API samrd does (i.e without --with-ldap).

luke also liked the surs thing so much he wrote a surs_nt5ldap_sid_to_uid function - in 20 lines of code. YESS :)

i'm also trying to get luke h. to write a samrnt5ldapd, but he coded himself silly on the passdb/ groupbd/ version so needs a rest. i'm also encouraging him to "track" what i do for samtdbd, so he doesn't have to waste effort.

i'm trying to write samtdbd, but the rest of you are so busy in the mornings (when i'm not even up) that i had 100 email messages when i started work and they just kept on coming...

And so it goes, and so it goes. [And all those functions, I suppose. Apologies to Billy Joel.] The API conversion project does seem to be getting done, slowly but surely.

2. SMB Without NetBIOS Sessions

26 Jan 2000 - 30 Jan 2000 (13 posts) Archive Link: "NetBIOS-less SMB on port 445?"

People: Richard SharpeJerry CarterChris HertelLuke LeightonJohn Malmberg

Richard Sharpe started this one out on samba-technical. He asked: "When did MS introduce the NetBIOS-less SMB stuff on port 445. Was it only in NT5/Win2K, or did it appear in one of the SPs of NT4?" Jerry Carter answered, "Was only in Windows 2000 i believe." Chris Hertel wanted to know: "Um... How true to draft-leach-cifs-v1-spec-01.txt is it?" Luke Leighton wasn't sure, but noted that, in any case, it was fairly simple: you just don't set up a NetBIOS session at the beginning. Chris continued, almost as an aside, "As I do my research, I find more and more ways in which MS took liberties with the RFC specs. You'll note our long discussions about group name query responses, and the differences between the RFC-specified Adapter Status Query statistics block and what MS actually send."

Richard Sharpe noted: "However, this NetBIOS-less SMB stuff is a major loss, as you can no longer do virtual servers. Samba virtual servers are neat and have lots of uses." Luke Leighton answered, "YES I KNOW. i xxxxing told microsoft about this and they xxxing refused to listen." He outlined a problem he had heard Microsoft was having with their new approach, and finished: "i mean, honestly: how stupid can you get? sorry, i will defend the corner that i think's sensible, even if microsoft's in it too, and in this case, they're not."

John Malmberg had a possible answer to Richard's lament about loss of functionality, though. It is, of course, only speculation:

That capability is reserved for the Microsoft Enterprise Edition when cluster server is installed.

Notice the price difference in this product from the standard Server prices.

If the base server could do the virtual server stuff, it could hurt sales of the Enterprise edition, since normal servers could be arranged in a hot standby configuration, with no failover of a disk farm needed.

3. Samba Pre-2.0.7 Testing

28 Jan 2000 - 2 Feb 2000 (16 posts) Archive Link: "Samba pre-2.0.7 snapshot available."

People: Kim Bjoern NielsenJeremy AllisonAndy BakunDavid LeeShirish KaleleGiulio OrseroDejan IlicGreg Dickie

Last issue, Section #5 (sm20000203_10.html#5) covered Jeremy Allison's announcement of the first Samba 2.0.7 prerelease. There were several reactions to this release, most of them reporting one bug or another.

Kim Bjoern Nielsen reported, "I have trouble executing from IRIX 6.5.6f R4400." Jeremy's response: "This is not specific to 2.0.7pre1. This is actually a known problem with gcc strcture passing conventions and IRIX 6.5.x. Either compile with the SGI compiler or change includes/config.h to use MMAP rather than SYSV shared memory and it should work fine. Bug Herb [Lewis] if you want the full details on this (I'm emailing from my crappy laptop on the road at the moment :-)." Don Badrak responded with a horrible hack to work around the gcc bug in question. (It's really ugly ... but at least one other IRIX user reports it to work.)

Andy Bakun had an unrelated compile problem on IRIX with gcc. Greg Dickie noted that IRIX cc worked fine for him, which prompted Andy to say: "Heh, I don't know which is worse: gcc on Irix or the standard SGI cc." The problem Greg had reported was a real bug (a mismatched type declaration), so apparently the native IRIX compiler wasn't paying attention.

Giulio Orsero had a nice long list of known problems. Briefly:

  1. the print command parameter does not work in the [global] section any more
  2. various socket options give errors in the logs
  3. smbpasswd still doesn't have a command-line switch to delete a user (Jeremy earlier promised, I believe, to do this for 2.0.7)
  4. various documentation is out of date
  5. the profile directory saga (see Issue #9, Section #1 (sm20000127_9.html#1) ) is still not documented
  6. various bugs and user-interface glitches in smbclient (most of them not new to 2.0.7)
  7. inconsistency with NT in anonymous browsing
  8. difficulty browsing from Windows 2000
  9. log files are not closed/reopened when Samba is sent SIGHUP -- this can mess up log rotation
  10. smbmount shows the length of the password in the ps output, which is information nobody needs to know
  11. smbmount can get confused about volume labels under some circumstances
  12. Samba doesn't log enough information about failed login attempt
  13. s
  14. log files can show false positives: authentication "failures" that later succeed

David Lee noted happily that the "utmp" and "inherit permissions" patches (see Issue #1, Section #11 (sm19991201_1.html#10) had been integrated. He also found a few build errors to be cleaned up, and wondered about the status of a patch for quota support under Veritas filesystems in Solaris. Dejan Ilic was confused: quotas worked fine for him under Solaris. But David explained:

The patch is specifically for when Veritas FS (VxFS) is added to Solaris. VxFS has quotas, but the mechanics are completely different.

Case 1: Some systems hide this (I think HPUX is one such): the user calls a generic OS quotas subroutine which internally calls the native filesystem or VxFS as appropriate. No problem.

Case 2: The remainder (of which Solaris is one) require the caller to work out whether the filesystem is native or VxFS and for the caller then to do different things accordingly. Problem (for Samba, C, Perl, scripts, ...).

The Samba patch was developed for Solaris+VxFS, it ought to be reasonably portable to other systems. BUT... I understand that Veritas's preferred solution is for the OS manufacturer to implement "Case 1" above. If they don't, then Samba needs to do "Case 2". The programming interface for "Case 2" is, apparently, "unsupported" by Veritas. Grrrrrr.....

Shirish Kalele (Our Man at Veritas) further explained, apparently speaking for his employer: "This patch is required because Solaris' quotactl() call is UFS specific and doesn't take the VFS switch route. We believe Sun will eventually fix this bug in Solaris, and the quotactl() system call will then work on VxFS file systems, including NFS mounted VxFS file systems. So you might want to modify the patch to try the quotactl(2) system call first before diving into VxFS specific code." He further cautioned that the Veritas quota API was not guaranteed stable. But, "with these points in mind, Veritas welcomes including your patch in Samba. And we'll do our best to keep the patch updated."

4. The Sendmail Trap

28 Jan 2000 - 2 Feb 2000 (33 posts) Archive Link: "PATCH: 'source environment' param and % token subs for 'netbios name'"

People: Nicolas WilliamsLuke LeightonRichard SharpeJeremy AllisonDave Collier-BrownDan KaminskyNico WilliamsSteve Langasek

Nico Williams had a patch that he wanted considered for Samba 2.0.7. He posted to samba-technical:

This patch does two things:

He posted a somewhat length rationale for both parts of the patch. Mainly they make it easier to support a single set of Samba binaries and config files across multiple machines -- specifically, Nico was thinking of HA configurations. (HA, or High Availability, is a paradigm of having multiple redundant servers in a hardware and software configuration that allows one to take over for another automatically when it fails. Companies like IBM and HP make a lot of money selling this stuff.)

Luke Leighton like the HA part. "whooooaaa. MAJOR advanced functionality. nico, can you write this up, how to set it up? that's kind of... really important marketing points for samba." Nico replied, "Oh and, this is not so major. Just a few scripts and standard config [sub-]files in standard locations." Luke thought that would be a fine joke: "that's even better marketing. "it's so simple to set up samba high availability that even a script kiddie can do it". oops, um..."

Richard Sharpe was excited too. "This sort of feature is so important for HA that I am about to commit your patches to 2.0.7, if Jeremy hasn't already done it. If Jeremy doesn't like the patch, he can argue about it." Jeremy duly argued. "Please don't do it quite yet. I fully intend to grab it and apply it for 2.0.7 (I emailed Nicolas and told him so), but I want to do some work on the popen() part of it first to make it paranoid and bullet-proof first. I recognised how useful it was for HA work as soon as I looked over it :-)." Meanwhile, Dave Collier-Brown found what he thought was a small bug in the patch; nobody commented on it.

Dave then started another thread to ponder config file formats.

I've been wondering about what programming primitives one needs in and smb.conf ile fro a long time, and Mr. Williams' patch re-raises this question.

In a very early version of the O'Reilly book, I described the smb.conf file as having all the basic primitives of a programming language:
  variable assignment
  conditional code ("include" and "copy" using a %-variable)
  blocks (files, sections)
but lacking a way of setting a %-variable.

This was too academic, and promptly disappeard from the book, but it is a decent question of the development team: how much programmability should there be in the main smb.conf file?

I've seen two proposal to extend the language:

One was from a site with a very large .conf file that contained the definition of all the shares for a cloud of servers. They wanted a way to ignore inappropriaste shares, and save memory thereby.

The other is Mr. Williams' proposal, to do conditionals on netbios names, and to provide a general ${env-var} construct, which they use for Samba-failover on a Veritas HA server.

On the other hand, smb.conf is a much easier language to read and maintain than, say, tcl. We may well want to keep it that way!

Dan Kaminsky thought a simple extension would be nice:

Presently, we include outside files. Why not allow inclusion based upon outside executables? We can use environment variables to pass all of Samba's variables into the outside process, and with almost every existing scripting language able to parse environment variables, we automatically become compatible with whatever scripting language the user posseses.

Include Exec would take two forms:

  1. include exec = <executable which outputs valid smb.conf parameters>
  2. parameter = `cat /etc/parameter`

#2 allows for cheap one liner perl scripts to do their work.

Nico looked around for a good slippery slope, found one, and started down. What he wanted was to turn smb.conf into a scripting language without turning smb.conf into a scripting language:

Sure. I think Samba could easily be modified to support multiple config language options, so long the global/share parameter paradigm is kept as it is.

Basically all a scripting language for Samba configuration needs to provide is methods for defaulting, setting and querying the value of global and share parameters and methods for creating, deleting and looking up shares.

Samba config language modules would need to provide a simple entry point to Samba so that it can be called when including config files of that langugae. And Samba needs to provide a registration mechanism so that these modules can inform Samba of their existence (even if this were a static, compile-time mechanism).

I have visions of an embedded Tcl configuration system...

There's only one serious issue: how to tell Samba the language type of the config files. One way would be for Samba to check for '#!' as the first two characters of a config file and use the basename of the path that follows to index into the list of registered config language modules (or load it if it exists and isn't loaded yet).

Hmmmm. I should buy an asbestos suit.

These ideas got bounced around a little. Nobody actually came out and said "", but presumably the thought crossed at least some people's minds.

Meanwhile, Luke Leighton was (for once) on the down-to-earth side, as opposed to the oooh-shiny-new-feature side: "no, no, and no. use outside exes to generate the scripts, off-line." Dan thought that would lose too much flexibility. "This isn't all that big of a deal, Luke." But Steve Langasek raised the question of just how often smb.conf is read -- could it be a major performance hit to be runnine executables each time? Luke answered the question: " on startup.
on a TCP connection (at least twice)
on NetBIOS session request
on SMBnegprot
on SMBsesssetupX (at least twice)
on SMBtconX
there may be more [triggered by incoming network traffic, that is]."
So Nico suggested having additional syntax to indicate whether executables should be run just once or every time. Luke, back in character, said: "it's not so much a matter of it being a big deal [to run external programs: %`cat somefile`], it just that it won't go into the main samba distribution, for reasons already discussed by jeremy and andrew on a patch submitted over eighteen months ago that had this functionality. i put it in, jeremy took it out. andrew had already reviewed and rejected it."

5. Off-Topic: NT Images on Unix

31 Jan 2000 - 3 Jan 2000 (22 posts) Archive Link: "NT Workstation duplication"

People: Alfredo RamosSchlomo ShapiroSeth VidalGreg DickieAaron BrooksGreg Leblanc

Alfredo Ramos, continuing a discussion on text files versus other configuration methods (see last issue, Section #6 (sm20000203_10.html#6) ), asked on samba-ntdom: "You have touched a subject I am very interested in: Imaging NT's. I need to be able to remotely image NT's from a unix box. The NT administrator uses PCRDIST to download the image from the unix box, but he swears he has to visit every NT workstation in order to get the imaging process going."

Schlomo Shapiro described his setup:

We use Ghost to install the NTs (multicast is a very very good feature), using a NT client (on my desk) for ghost multicast server (Symantec ! Wake up and make a linux ghost server !). After that we use GHOSTWALKER (also from symantec) to change the name and SID of the NT on the file system and the registry WITHOUT changeing anything else (especially machine acocunt passwords).

The NT duplication trick is in that before duplicating the NTs I register the master in the Samba domain and then I copy the password hash values from the master machine account the the to-be-created NT WS accounts (in smbpasswd). Thus the NT clients will be able to re-connect to the domain without problems with their new name (I got scipts for all that) since on the client side ghostwalker changed the name, but not the password, while on the server side I copied the password to the name accordingly.

One should register the master just before duplication since otherwise you could get a problem with the life time of the machine passwords and NTs not talking to the domain because the password is too old etc. (Didn't try it though).

Then he gave his parting shot: "I am asking each and every NT admin how to do THAT trick on NT Server but didn't yet get an anwser :-) Looks like there is no solution for automatic re-registration of the NT client in the domain."

Other ideas came down the pipe as well. Greg Leblanc suggested having a small MS-DOS bootable partition that would boot, run the imaging software and reboot into NT. Seth Vidal extrapolated: "do this same thing with lilo and a small linux partition instead of dos and you're life is even easier. you can do all sorts of crazy things." Schlomo had yet to find a Linux program that met his specs for this, though. "Please, please point me to such a program (ghost for linux ?) and I will immediately use it." Sean Millichamp pointed out that Cosource has a proposal ( for a Ghost clone, though nobody had taken it up yet.

Schlomo, at this point, raised the concern of being off-topic for samba-ntdom. Nobody seemed to mind. Greg Dickie went so far as to say, "Personally I like this discussion since I too need a solution for this. Its a topic that seems to have no clear solution and pops up on the clearcase users group mailing list quite a lot as well. Maybe a good opportunity for an IPO? ;-)" [This is also our justification for covering this thread in KC Samba.]

The most elaborate solution posted on the list would have to be that of Aaron Brooks of Taylor University.

A year ago myself and my co-worker Joel Martin, created a linux boot disk system which can build any of our lab in about an hour and a half. The build process is a true NT install complete with 75+ applications which serve the CSS and Science divisions which we service. Did I mention that these machines dual boot to linux too and that is part of the build? The components are the following:

This is the only way that our network is managable. Our hardware is totally heterogeneous, our custom configurations is broad, we need some machines to run all apps on the network, some machines need to run some off of the network and others that need all apps to be local. The system is entirely customizable. A full, proper installation is done, dual booting linux, in about 1-2 hours depending on config. (It used to be under an hour before we started installing MetroWerks Codewarrior and Visual Studio locally for performance reasons.)


6. Windows95 PPP Login Trouble

31 Jan 2000 - 2 Feb 2000 (8 posts) Archive Link: "very slow "network login" over PPP"

People: Daniel StenbergLuke LeightonDan Kaminsky

Daniel Stenberg was having problems with Windows95 doing things very slowly over PPP. He posted to samba-technical: "When I login as a mere user from a Win-box doing a domain login, I can count to 20 netbios-ns broadcasts before the first netbios-dgm is sent (and thus replied to if there is a server around for it). (packets recorded by tcpdump) The total time for those 20 broadcasts is around 7-9 seconds. Can I force the client to behave differently? Can I fake a message reply earlier? I am prepared to do (other) protocol nastinesses in order to drastically cut these times to a minimum. Any ideas? Any hints? Any suggestions? I want to cut seconds! :-)"

Luke Leighton suggested two ways to solve this on the Windows95 end, but Daniel couldn't do that: "I am not allowed to do a single change to the clients or their setups. All changes must be at the server-side." Luke's reaction: "that's, if you ask me, a stupid policy. what if the win9x clients aren't set up correctly (which they aren't)?"

Dan Kaminsky's idea: "What happens if we spoof the response to the point to point lookups before the client asks for them? Is Windows amenable to gratuitious announcements?" Luke said that that should work. At this point, the topic drifted to what a malicious but unknown login server could do to clients that put too much trust in unknown login servers. Daniel put in: "My experiment server I have running here sends a really nasty login script to whoever logins to my network using any username, any password on any domain. I can't see why a faster login thanks to speedier packets would change the client's acceptance to run what the server tells it to. My 'nasty' program disables the 'login to domain' checkbox in the dialup properties for the currently used dialup connection that lead to the login attempt... :-) Imagine what fun you could have with a little hack like this on a portable that you connect to your favourite company's network. Then you can just sit and wait until you hear the screams and shouts down the hallways... B-]"

7. Unix vs. Microsoft OS Semantics Differences Strike Again

1 Feb 2000 - 2 Feb 2000 (8 posts) Archive Link: "pre2.0.7 disk quota bug"

People: Sergei MakarovJeremy AllisonWilliam JojoGiulio Orsero

Sergei Makarov reported a bug to the samba list: "The old disk quota bug is still here. If user tries to write the file to SAMBA share and disk quota is exceeded, SAMBA fills remaining space within the target file with spaces, and writes it to the share."

Now, this situation is the result of semantic differences between Unix and the various Microsoft OSes. Jeremy Allison explained it really well:

It isn't Samba that is doing this, it is the client.

The problem occurs because the client sets the file size before doing the writes. Under UNIX, this is allowable sa it creates a file full of "holes" (zeros) that takes no space, so the user has not gone over quota. When the client actually tries to fill the file with real data the user goes over quota and Samba returns an error. But the file size was set before the writes, so still seems correct.

The only way to fix this would be to do an explicit user quota check on every file size change, which would be very expensive (read - SLOW !).

Samba is returning the over quota error to the client.

What tdo you execpt us to do here ?

That pretty much closed the issue, but then William Jojo had a related anomaly:

If I check properties on a share (read only apps and stuff) - Open M:/select all/properties, it reports 85,212 files, 3878 folders and on the size line:

Size: 7.15GB (7,682,881,503 bytes) 27,111,194,624 bytes used

What in the world is that second number?! I'm sure NT is confused (as usual) but really...

Giulio Orsero replied, "Probably nt thinks that partition is fat16 or something like that, so maybe it tells you the overhead (like it does for local stuff)?" He had numbers from his own site to back up this theory.

8. More on Samba/HA, and Another Brilliant Idea Hits Luke

4 Feb 2000 (13 posts) Archive Link: "High-availability cluster and samba"

People: Nicolas WilliamsLuke LeightonNico Williams

Frédéric Dubuy posted a rather detailed description of a two-node HA cluster he had recently demonstrated at the Linux Expo in Paris. The article ( is a bit long to quote (or even summarize) here. Nico Williams asked a few questions on some of the particulars, which Frédéric answered.

Nico also asked, in passing: "Luke, can you make sure that smbd communicates with the MSRPC daemons in SAMBA_TNG in a way that allows the running of more than one set of daemons per host, with each set being conceptually separate as I showed above?" Luke Leighton's response: "actually, i have to do that. i am going to have to associate one msrpc daemon per separate smb virtual user id (vuid). this will only happen for Windd / winframe/ TSE, but it's not very pretty."

Nico was puzzled. "Why can't you pass the PID/vuid along with the DCE/RPC NDR packets to the msrpc daemons??" Luke had his answer ready: "because dce/rpc pdr packets have nothing to do with PID.vuid, there's no space for it." He continued, "and there's definitely no means to do this:

lps_open_policy("PID.vuid@\\SERVERNAME, &policy_hnd);
so the contexst "used" to be just \\servername and implicitly it used to be smbd PID by forking() smbd. now i have to either fork() on a vuid (no way!) OR... maintain INDEPENDENT sets of msrpc connections on a per-vuid basis." Nico also had his answer ready. "So? Encapsulate them."

Luke liked the idea. "i used to have a "NetBIOS-like" interface which encapsulated a DCE/RPC packet in a NetBIOS length+char* format (i used send_smb() basically!) that original implementation is starting to have merits. it allows the simulation of "threads". HEY! bing OF COURSE! dammit, dce/rpc already is sutable to threaded environments! YESS, nico, you're a genius. COOL, it's even 16 bit! see context_id, below:" He posted some rather cryptic C structure declarations.

Nico still felt Luke didn't understand. "The idea is not to insert PID/VUID information as extra NDR-encoded DCE/RPC arguments! The idea is to encapsulate, i.e., add a packet "frame" for the SMBD<->MSRPC protocol; these packet frames are terribly simple: they contain three fields: SMBD PID, VUID, DCE/RPC NDR data" Luke agreed that this was the way he had done this in the past, but then explained the brilliant idea he'd had in the last post:

each dce/rpc request contains this as part of the header. it contains an unused field, context_id, which is use to identify DCE/RPC "threads"... if you have a threaded environment.

well, with the smbd vuid, we do have a threaded environment.

so i am going to overload context_id with the smbd vuid. the only other bit of info i need to get over there is the smbd process id (PID).

and that's it! we have the smbd PID.vuid index into the TDB database.







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.