Netbios name %m not always correct

[David Lee]

On Tue, 21 Oct 2003, Christopher R. Hertel wrote:

> On Tue, Oct 21, 2003 at 11:06:28AM +0100, David Lee wrote:
> > [...]
> > 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.)
>
> Kewl.

[ 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.") ]

> > [...]
> > 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.
>
> Yep.
>
> > 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?
>
> Nope.  :)

Ah!  Right.  We're converging...  Thanks.

> The MS-RPC version is also considered a security hole (think about all
> those funderful RPC worms wigglin' about the 'net).  [...]

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

> 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
> do MS-RPC.
>
> 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".)

> [...]
> 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.)

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.).

Thanks again, Chris.  Best wishes.

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 334 2752                  U.K.                  :