Netbios name %m not always correct

[Christopher R. Hertel]

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.

Likewise.

Keep in touch.

Chris -)-----

-- 
"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