Netbios name %m not always correct
Christopher R. Hertel
crh at ubiqx.mn.org
Tue Oct 21 16:16:55 GMT 2003
On Tue, Oct 21, 2003 at 11:06:28AM +0100, David Lee wrote:
> On Sat, 18 Oct 2003, Christopher R. Hertel wrote:
> > The WinPopup application, which is common on home and desktop Windows
> > flavors (Win9x, ME, and possibly XP-Home) uses a very old remote function
> > call system known as the Windows Messsanger Service. It's documented here
> > and there. Probably the best place to start would be the X/Open's
> > 11-year-old SMB specifications. (See the References section in my on-line
> > book.)
> Presumably the Microsoft/Intel "File Sharing Protocol" "PN 138446" (and
> similar) from November 1988? (It so happens that a few months ago, I
> supplied two patches to "SMBsend*" code in "libsmb/climessage.c" that
> implements that spec.)
That stuff is obscure, so I never expect people to know how it works.
I sure don't. :)
I haven't looked into it beyond reading through the docs to know that I
wasn't going to document it in my book. I may give it a whirl some other
> > With WindowsNT4 (possibly in some service pack) it was recognized that the
> > NetBIOS based Messanger Service was outdated and needed replacing. The
> > functionality was re-implemented using Microsoft's Remote Procedure Call
> > (MS-RPC) system. The basics are the same. A message is sent to the
> > receiver and displayed. I *don't* know a lot about the workings of
> > the RPC call based Messanger Service, but:
> > - It doesn't require NetBIOS.
> > - It only works on systems that support MS-RPC.
> But can we briefly return to the "Big Picture", (away from the technical
> detail for just a moment, although we'll return...)
> The Big Picture:
> 1. PC connects to a samba server;
> 2. smb.conf (e.g. "print command") can invoke some mechanism to send some
> sort of message back to that same PC.
> In "the good old days"(!), the particular implementation of this "big
> picture" is step 1 providing a name (it so happens, a NetBIOS name) to the
> samba server, and that step 2 could invoke "smbclient -M ... %m ...".
> Note the linking role of "%m" (which happens to be that NetBIOS name).
> Closing in towards some detail:
> You suggest (if I understand correctly) that the above implementation is
> increasingly inappropriate/unusable (two counts: NetBIOS/WINS on the wane;
> Windows Messenger Service outdated and/or insecure). Fair enough.
> So it sounds as if we need a version of "smbclient -M ..." (or something
> analogous to it) that can use a DNS-name or IP-address (instead of "%m"
> NetBIOS name) and that can use this MS-RPC thingy (instead of "SMBsend*").
> Is that correct?
The MS-RPC version is also considered a security hole (think about all
those funderful RPC worms wigglin' about the 'net). In addition, it's
only supported on a limited set of clients. If you're only running NT4,
W2K, XP-Pro, and W2K3 then you could probably make use of the MS-RPC
version of the call. If you have Win/9x & ME rattling about, those don't
One solution is to do *both* the NetBIOS and MS-RPC versions. Still, the
results are likely to be flakey.
> Could you give me two pointers:
> 1. Whereabouts in the Samba 3.0.0 code should I start looking for the
> existing code?
Eeeek. Dunno. General RPC marshalling/unmarshalling would be a place to
start. I have not dug into RPC much yet. Sorry.
> 2. Is there a document (the equivalent to Nov.1988 138446) that describes
> the protocol?
Not that I'm aware of. There must be something, though, because there are
a few spammer-types out there who have written code to exploit the MS-RPC
Messenger Service. (Yet another reason people turn it off.)
If I get some time I'll have a look. I'll be doing google searches though
so we're starting even.
I am wondering if there might not be some other solution, like running a
third-party tool that will listen on a port and accept messages. The
problem, of course, is that the users would need to run the application.
(Perhaps it could be put into some sort of logon script.)
My gut reaction to all of this is that adding MS-RPC Messanger support to
smbclient would provide a partial solution. Even with such support, I
think that client support for receiving messages will be spotty. That,
however, is a client issue. If there's some (secure?) tool out there that
users could load so that they can receive messages then the users who want
to receive such messages would be able to install and use it. A third
party tool might also provide support for non-Windows platforms.
> > Chris Hertel -)-----
> > Durham University Alumnus :)
> [I seem to recall your Dunelm pedigree from a conversation a couple of
> years ago. Greetings!]
...and I know all the words to Fog on the Tyne. I saw Lindisfarne live at
Dunelm House back in '82. I still have the poster somewhere... :)
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the samba-technical