NMBD Duplicate Name Error

[otmshank]

After upgrading one of my two FreeNAS boxes to FreeNAS-9.3-STABLE-201506162331 I'm getting the following error repeated in my logs on my server running FreeNAS-9.3-STABLE-201506042008.

Jun 21 11:35:23 zar nmbd[97875]: process_lanman_packet: Discarding datagram from IP 192.168.2.114. Source name ZARABETH<00> is one of our names !

Setup:
Production host: ZAR 192.168.2.117 running FreeNAS-9.3-STABLE-201506042008, physical server.
Development host: ZARABETH 192.168.2.114 running FreeNAS-9.3-STABLE-201506162331, virtual server on ESX 6.0.

Scenario:
Both production and development were running FreeNAS-9.3-STABLE-201506042008 and I had no issues. I upgraded development to FreeNAS-9.3-STABLE-201506042008 and almost immediately I got the above referenced error in my logs on production, repeating every minute. I searched the GUI for name collisions and also looked at the smb4.conf file to confirm no duplicate name references existed. I see no issues. On a whim, I reverted development to FreeNAS-9.3-STABLE-201506042008 and the errors stopped.

Any advice on what could be wrong?

 

[Ed Hornsey]

Ditto,

Have exactly same console messages with my two physical node Freenas cluster both at FreeNAS-9.3-STABLE-201506232120. Error first seen on early June update.

Bug report lodged with dump info.

 

[jkh]

Do you actually have another SMB machine using the name ZARABETH on your network? Samba is generally pretty good about reporting this as a genuine error in the user's configuration.

 

[otmshank]

Do you actually have another SMB machine using the name ZARABETH on your network? Samba is generally pretty good about reporting this as a genuine error in the user's configuration.

I do not, I checked each machine. I also checked for extra DNS entries in my DNS server and it is clean. The weird thing is that ZAR thought it was ZARABETH, but only after I upgraded ZARABETH. It's the weirdest thing.

 

[otmshank]

I've been doing more work on this and still haven't found a solution. I got both servers upgraded to the same version in hopes that this would cure it but the errors (every minute) persist. I changed the host name of my development server, ZARABETH, to ATOZ and confirmed that change in the CIFS service setting. I manually edited DNS (I do not run a WINS server) to reflect the update and then rebooted the development server.

In my production server, ZAR, I still get the following error every minute:
Jul 14 15:44:12 zar nmbd[36547]: process_lanman_packet: Discarding datagram fr
om IP 192.168.2.114. Source name ZARABETH<00> is one of our names !
Jul 14 15:45:12 zar nmbd[36547]: [2015/07/14 15:45:12.324109, 0] ../source3/nmb
d/nmbd_packets.c:1174(process_lanman_packet)
Jul 14 15:45:12 zar nmbd[36547]: process_lanman_packet: Discarding datagram fr
om IP 192.168.2.114. Source name ZARABETH<00> is one of our names !

There is no longer a server named ZARABETH on my network.

On my production server I ran the command grep -iR zarabeth /etc/*
The only result was my rsync module that had the old name of the development server. In summation, my production server is insane. If there's any logs or conf files you want let me know and I'll post them.

 

[Elo]

I also have this issue:

Aug 2 10:41:58 OB-NAS nmbd[4503]: process_lanman_packet: Discarding datagram from IP 192.168.111.5. Source name OB-NAS2<00> is one of our names!

Both servers are running: FreeNAS-9.3-STABLE-201506292130

Server Maximum protocoll is SMB3
Server Minimum Protocol ----

I have looked at the bug report Bug: #10301

This bug refers to duplicate SMB names which is not the case for me.

Any tips on how to get rid of these messages as they swarm my system?

 

[otmshank]

I did some reading on the smb.conf file and was able to stop the messages by setting the following parameters in the Services->CIFS->Auxiliary parameters

netbios aliases =
netbios name = hostname

Where the netbios aliases setting is purposefully left blank and the netbios name is the actual hostname of each individual server. So in my exact case on my production box I have:
netbios aliases =
netbios name = ZAR

And on my (newly renamed) dev box I have
netbios aliases =
netbios name = ATOZ

This has fixed the message flood but it's still weird I had to add this only after the upgrade. All things considered it's obviously minor but it was a puzzlement that something in there was not respecting the system names.

 

[Elo]

I tried this for my two servers but messages still coming on one of them :-(

 

[aliquid]

I did some reading on the smb.conf file and was able to stop the messages by setting the following parameters in the Services->CIFS->Auxiliary parameters

netbios aliases =
netbios name = hostname

Where the netbios aliases setting is purposefully left blank and the netbios name is the actual hostname of each individual server. So in my exact case on my production box I have:
netbios aliases =
netbios name = ZAR

And on my (newly renamed) dev box I have
netbios aliases =
netbios name = ATOZ

This has fixed the message flood but it's still weird I had to add this only after the upgrade. All things considered it's obviously minor but it was a puzzlement that something in there was not respecting the system names.

Reading source code source3/lib/util.c shows that is_myname() does an "if (strncasecmp_m(nbt_name, s, strlen(nbt_name)) == 0)". Further, lib/util/charset/util_str.c function strncasecmp_m_handle() returns 0 on maximum length reached. And maximum length was the length of the netbios name checked against (i.e. strlen(nbt_name)).

In other words, getting packet from anything beginning with ZAR (e.g. ZARABETH) when "my name" equals ZAR gives the message.

This is obviously a bug.

But there is more to it I believe, because I have the same problem in a single-NAS environment so it seems the NAS is sending to itself messages that it ignores.

 

[meku]

I've been seeing this message in my logs for a while now on 9.3, the message is logged every minute.

 

[Elo]

Reading source code source3/lib/util.c shows that is_myname() does an "if (strncasecmp_m(nbt_name, s, strlen(nbt_name)) == 0)". Further, lib/util/charset/util_str.c function strncasecmp_m_handle() returns 0 on maximum length reached. And maximum length was the length of the netbios name checked against (i.e. strlen(nbt_name)).

In other words, getting packet from anything beginning with ZAR (e.g. ZARABETH) when "my name" equals ZAR gives the message.

This is obviously a bug.

But there is more to it I believe, because I have the same problem in a single-NAS environment so it seems the NAS is sending to itself messages that it ignores.

I renamed my CIFs to cater for this and the messages are no more coming. (After that I have applied two upgrades)