Windows Server 2003 Enterprise Edition and Windows XP Home (SP2) fail to respond to broadcast wildcard name queries.

That's a bug.

Here are some examples to illustrate the problem:

    crh@Moose:~$ nbtquery ivanova
    192.168.101.23  [U,B] IVANOVA<00>

    crh@Moose:~$ nbtquery -A ivanova
    Response to Node Status Request for: *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>
    IVANOVA        <00> [U,B,ACT]
    IVANOVA        <20> [U,B,ACT]
    UBIQX          <00> [G,B,ACT]
    UBIQX          <1e> [G,B,ACT]
    MAC Addr: 00:0c:f1:02:f9:39

    crh@Moose:~$ nbtquery \*
    192.168.101.10  [U,B] *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>
    192.168.101.14  [U,B] *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>
    192.168.101.16  [G,B] *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>
    192.168.101.21  [U,B] *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>

(The nbtquery program is a little utility I cooked up. It's similar to the nbtstat utility under DOS or Samba's nmblookup tool, except that it has a few additional knobs that allow me to run some unusual tests.)

What the above examples show is that node IVANOVA will respond to a Broadcast Name Query for a name it has registered. It will also respond to a Node Status Query. It does not, however, respond to the broadcast wildcard query, as can be seen by the fact that IVANOVA's IP address (192.168.101.23) isn't in the list of IPs in the third test above.

IVANOVA is running Windows XP Home with Service Pack 2 applied. The firewall rules have been adapted to permit NBT and SMB filesharing within the local subnet.

In testing, Windows 2003 Enterprise Edition showed the same behavior.

This is an annoying bug. It makes it difficult to identify NBT nodes on the local LAN. It is possible that this behavior represents a misguided attempt to "protect" NBT nodes by hiding them. If so, it's quite ineffective because versions of Windows that have this bug will respond to the wildcard query if the B bit is cleared.

In the following example the query is sent to the broadcast address, but the -U option causes RD to be set to 0:

    crh@Moose:~$ nbtquery -vU 192.168.101.255 \*
    Query Name: [*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>]
      NBT Name: [ CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\0]
    Sending from port 55180.
    Sending to 192.168.101.255:137.

    Reply from 192.168.101.10:137
    192.168.101.10  [U,B] *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>

    Reply from 192.168.101.14:137
    192.168.101.14  [U,B] *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>

    Reply from 192.168.101.16:137
    192.168.101.16  [G,B] *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>

    Reply from 192.168.101.21:137
    192.168.101.21  [U,B] *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>

    Reply from 192.168.101.23:137
    0x3 == Name Not Found: *\0\0\0\0\0\0\0\0\0\0\0\0\0\0<00>

Note that node IVANOVA does respond, but with an error code of 0x03 (Name Not Found) which suggests that someone at Microsoft either forgot or decided not to include support for the wildcard name.

In contrast, the node at IP address 192.168.101.16 is running Windows 98. Note that it does respond correctly to the wildcard query.

One additional oddity that this testing points out is that W/98 reports the wildcard address as a group name ("[G,B]") while all of the others (excluding the W/XP system that responds with an error) mark it as a unique name ("[U,B]"). Those other nodes are all running Samba, so this is a (wildly trivial) Samba issue. It's a minor point, but in this case I tend to agree with Windows.