Samba 1.9.18.px nmbd problems

Jeremy Allison jallison at
Mon Feb 23 19:26:15 GMT 1998

Janne.Harju at wrote:
> Hello
> We caught bad Samba behaviour when we upgraded one Samba
> server to version 1.9.18p3. nmbd started sending denial packets
> to PC's trying to release/refresh their group name <00>.
> Here's the message from log.nmb:
> validate_nmb_response_packet: Bad REG/REFRESH Packet.
> Ignoring response packet with opcode 8.

Ok - this is triggered in nmbd_packets.c by a check
that the answer count is not zero. Note that this code
checks a *response* packet, not a request packet.
Note also that according to rfc1001/1002 no-one
should be sending response packets with that opcode
- the correct response to a name refresh (opcode 8
or 9) broadcast request packet should be to ignore it 
(if it's not your name :-).

Do you have some network sniffer logs/nmbd debug
level 10 logs of these packets you could send me ?

> After this Samba started hosing:
> process_name_release_request: Attempt to release name DOMAINNAME<00>
> from IP on subnet being rejected as
> it is one of our names.

A name DOMAINNAME<00> should be a group name. Release
of group names is explicitly ignored by this code in
the process_name_release_request() function.

  /* If someone is releasing a broadcast group name, just ignore it. */
  if( group && !ismyip(owner_ip) )

Note that the owner_ip address is the IP address of the
node releasing the name. Checking that it's not one
of nmbd's own IP addresses is valid here as we don't
want someone else releasing one of the names that nmbd
owns. If this check is failing and the code is falling
through then it means either someone is trying to release
a name DOMAINNAME<00> and not setting the group bit in the
packet (which is an error), or they are trying to release
the group name DOMAINNAME<00> and trying to release
an IP address that nmbd owns.

Either way, a problem.

> This caused the PCs sending release/refresh packets 300 times per sec!
> All the client PCs seemed to be old Windows 3.11 with FTP OnNet
> TCP/IP stack. Obviously our network was flooded. We had to shutdown
> Samba and revert back to 1.9.17p2.

Ok - you need to check if one of the PC's thinks it
has the same IP address as the nmbd machine, or if
these PC's are not setting the group bit in the name
release packet (that would be a bug in the PC's :-).

> After this I checked couple of things with all 1.9.18px releases
> in our lab. I've found out one thing so far:
>  nmbd does not register group names <00> and <1E>
>  if "wins server =" is not configured

Hmmmm. The code in register_my_workgroup_and_names() does call
initiate_myworkgroup_startup() (which does the broadcast name
registration for group names <00> and <1e> on all configured
subnets - even if the wins server is not defined....).

Are you sure you're not just missing these name registration
broadcasts (they'll be done at nmbd startup) ?

> Is this correct behaviour?
> Has anyone experienced the same problem?
> I'll be experimenting more tomorrow with the help of a network sniffer.

That would be very good. Please let me know what you

> By the way, this behaviour reminds me very much of a similar problem
> we had with the early version of Network Appliance's CIFS
> implementation. When PCs sent out name registration broadcasts NetApp
> replied with "OK" which caused shutdown of the PCs. If I recall
> correct it did also reply "OK" to name refresh/release packets.
> The PCs affected also had FTP OnNet TCP/IP stack configured.

Hmmm. The nmbd code in 1.9.18p3 has been extensively tested
with MS TCP/SMB redirector code - but I don't have access to
FTP's OnNet stack or redirector code.

> Jeremy, are you sure you haven't gotten any code from NetApp? ;)

Don't even *joke* about stuff like that. I take *great*
care to ensure I never see anything that could compromise
Samba code. I don't sign NDA's and certainly don't look
at other SMB implementors code !

Jeremy Allison,
Samba Team.

Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.

More information about the samba mailing list