wxp SP2 host responds to "nmblookup HOST" but not "nmblookup *"
Christopher R. Hertel
crh at ubiqx.mn.org
Wed Dec 29 02:23:40 GMT 2004
On Wed, Dec 29, 2004 at 12:25:49PM +1100, Andrew Bartlett wrote:
> On Tue, 2004-12-28 at 19:16 -0600, Christopher R. Hertel wrote:
> > On Wed, Dec 29, 2004 at 10:14:12AM +1100, Andrew Bartlett wrote:
> > > On Tue, 2004-12-28 at 14:33 -0800, David Wuertele wrote:
> > >
> > > > I didn't realize the messenger service was handling this. Or is it
> > > > that some security logic is only turning on the "respond to wildcard"
> > > > feature if it sees that the messenger service is running?
> > > >
> > > > Dave
> > >
> > > I'm pretty sure that's what happened. Remember, SP2 was a compromise
> > > between better security (which would mean not listening at all) and not
> > > breaking applications people used. While we may all find it
> > > frustrating, I'm sure winpopup is actually used in some organisations
> > > even in it's (frustrating) broadcast mode.
> >
> > No, Winpopup is not in broadcast mode. The names are all unique names and
> > the protocol is something like a mailslot protocol (though it isn't... I
> > have some docs and some captures...).
>
> I assure you, the winpopup wars I had on my network (before I disabled
> messenger service on all my machines) were broadcast UDP packets, as
> mailslot requests. I almost got a program written to catch them, and
> record host addresses.
>
> I hoped they were just unicast sessions to smbd, as then my 'beartrap'
> would have caught the bastards involved....
Well... First thing is that it doesn't matter. A name query should be
handled by the NBT layer, not by any NetBIOS application or service.
Those exist above the NBT layer. Starting the the Messenger Service
shouldn't (but, empirically, does) have any impact whatsoever. It's weird
behavior on XP's part.
Regarding the Winpopup stuff...
Looking at the old X/Open C195 document, I get this (pg 99):
These three forms of messaging take different approaches to delivering
the message. For the first case, a directed message,
NetMessageBufferSend() attempts to establish a NetBIOS session with
the specified system if an existing LMX session is not present. Two
attempts are made, the first being to a forwarded name (see Chapter 6 on
page 119), and the second being the message name; the sixteenth byte is
0x05 and 0x03 respectively. If one of these NetBIOS sessions is
established, the function proceeds with the construction and
transmission of the messaging protocols. There is no requirement to
issue the SMBnegprot or other LMX server session setup protocols for the
NetBIOS session. If this new NetBIOS session is used, then it is
destroyed after the message has been sent.
I have captures of a WinPopup message being sent. The captures show an
NBT session (port 139 NBT Session Request/Response) being established
followed by a single SMB command/response (no NegProt, no Session Setup).
The command code is 0xD0: Send Single Block Message. The content of the
message is contained within the data portion of the SMB. There's no
mailslot or share or anything like that indicated anywhere in the message,
but that's okay since it's going to the Messanger Service (suffix <03>),
not the Server Service.
There are also three SMB types used for longer messages:
0xD5: Send Start of Multi-Block Message
0xD6: Send End of Multi-Block Message
0xD7: Send Text of Multi-Block Message
I have captures showing multi-block messages too, and they follow the same
basic pattern as the single-block message.
The X/Open docs go on to say...
In the case of a message directed at a group of users within the
network, NetMessageBufferSend() sends the message using NetBIOS group
names (refer to Chapters 14 and 15 of the Protocols for X/Open PC
Interworking: SMB).
Note that the <03> names are always unique, not group. That implies that
a different group name would be used as the destination name. More from
the X/Open docs:
The NetBIOS group name is constructed from a domain name. Each LMX
server implementation has an implementation-defined method of specifying
this name. For broadcast messages, NetBIOS broadcast datagrams are used
to send the protocol block. (See Chapters 14 and 15 of Protocols for
X/Open PC Interworking: SMB.)
So I'd guess that the destination of a group or broadcast message
would probably be WORKGROUP<00>. That'd be the most likely candidate
(though the X/Open docs state that <03> names are used and <05> names can
be used to forward messages to <03> names... yeah, it's more involved
than it ever really needed to be).
I'm 'fraid I don't know how to send a group or broadcast message of this
type, so I don't know how to capture that kind of message.
The Messaging protocol itself is described starting on page 119 of the
X/Open docs. ...and there's no mailslot mentioned.
Of course, this is CIFS we're talking about. There are a lot of different
messaging services. There may be one based on mailslots... one that I
haven't seen yet. It may be the broadcast stuff you're seeing (since
there'd be no sense in creating an NBT session to send a group or
broadcast message).
The one I've seen (which drives WinPopup) is an old NetBIOS thing. In the
X/Open stuff, it's documented in addition to Mailslots and Named Pipes.
I'd love to see those captures you've got. All new stuff to me...
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
More information about the samba-technical
mailing list