Netbios name %m not always correct

Christopher R. Hertel crh at
Tue Oct 21 17:39:15 GMT 2003

On Tue, Oct 21, 2003 at 06:18:11PM +0100, David Lee wrote:
> [ Oops.  I just realised that my original "I supplied two patches... that
> implements that spec" might have been ambiguous.  Clarification: the code
> already existed, I merely provided two tiny patches to improve it.
> (There's a chance someone might have read it as "I supplied two patches
> ... that [completely, ex-nihilo] implements that spec.") ]

Doesn't matter.  You've touched it, which is more than I've done.  I'm the 
theory guy.  :)

> Do you mean "MS-RPC is inherently, and unavoidably, insecure"?  Or that
> "the worms exploited patchable bugs in an otherwise (other bugs excepted!)
> secure mechanism"?

No, that's not really what I mean.  There could be an argument made, since 
the RPC calls are transported over all sorts of other protocols.  I read 
somewhere that W2K supports Active Directory Replication via SMTP.  I have 
to wonder whether they're doing RPC calls over that, too.  Ouch.

I mention the recent RPC worms only because the result is that some folks 
(probably correctly) will disable and/or block RPC access to their Windows 
systems.  The RPC-based Messenger Service is guarded particularly well 
because there are tools available to send pop-ups across the wide 
Internet.  (I assume you block 135 at the border, though.)

Anyway, the current worm-infested climate will only serve to increase the
effort in "best effort", at least with regard to your goals.

> > One solution is to do *both* the NetBIOS and MS-RPC versions.  Still, the
> > results are likely to be flakey.
> Thanks.  I'm at the bottom of a steep learning curve here, but I was
> beginning to think that some sort of "both" might be the case, so it's
> good to have it confirmed by you.
> (Incidentally, our particular uses of the mechanism have always been with
> "reasonable efforts" rather than "guarantee".)

CIFS, in all its facets, does have a steep learning curve.  I also work
for a University so I have some idea what you're looking at.

> So a revised smbclient+ might need to be configurable/driveable to send
> via one or more of a set of different types (SMBsend, MS-RPC, 3rd-P/[1..n]
> etc.).  Looks like we're heading to a multi-choice plugin-type design here
> (analogous to passdb, VFS, etc.).

An updated smbclient might do SMBsend and MS-RPC.  I don't see it doing a 
third party thing since that would be outside of the scope of Samba.  The 
problem is that SMBsend does not return any success/failure.  It just 
sends.  That means that there's no good way to know whether the message 
was received.  Of course, before performing SMBsend we could check for the 
existence of the <03> NetBIOS name.  That only gives us a clue (since we 
don't know whether WinPopup or equivalent is running), but in a best 
effort environment that should be enough.  Not sure what MS-RPC does.

> Thanks again, Chris.  Best wishes.


Keep in touch.

Chris -)-----

"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team --     -)-----   Christopher R. Hertel
jCIFS Team --   -)-----   ubiqx development, uninq.
ubiqx Team --     -)-----   crh at
OnLineBook --    -)-----   crh at

More information about the samba-technical mailing list