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