4.1.7 Slow To Respond To SMB Network Discovery...

[WSJ]

http://samba.org/samba/history/samba-3.2.2.html:

"Fix freezing Windows Explorer on WinXP while browsing Samba shares.
This one led to timeouts during printing as well." (BUG #5617)

Well, that could be related (although it's not exactly the same issue).

[BikeHelmet]

Some more details:

1) The odd behaviour I experienced first occured after a Samba update.
2) Restarting Samba would cure it briefly. (perhaps 30-60 minutes)

Well - my ReadyNAS Duo (with 4.1.7 firmware) has

Code: Select all

name resolve order = "lmhosts host wins bcast"

So, that seems not the cause.

3) Previously my order was:

Code: Select all

wins lmhosts host bcast

I changed it to this to resolve it:

Code: Select all

wins bcast lmhosts host

Certain name resolve methods (WINS) were timing out for some reason. I assume there's an underlying bug/glitch in whatever version of Samba I had.

[WSJ]

Well, it would be interesting to know which Samba version is used in a ReadyNAS with RAIDiator 4.1.6.
And also the section "name resolve order" in /etc/samba/smb.conf should be compared with the one of RAIDiator 4.1.7.

Does anyone has a ReadyNAS with RAIDiator 4.1.6 and is willing to post his findings?

I assume that the Samba version is "3.0.34" (according to nmbd.log: I've noticed a change from "3.0.34" to "3.0.37" at the point in time when I've upgraded the firmware ...).

I've also noticed a change regarding the "Linux version" at the same time (according to system.log):
"2.6.17.8" -> "2.6.17.14"

And another change effects the "udhcp client":
"v0.9.8" -> "v1.14.3"

Can someone confirm / correct those assumptions?

[Milhouse]

I'm running 4.1.6 on an NV - I still don't think 4.1.7 is stable enough to warrant an upgrade, too many minor/niggling issues that need fixing or working around and taken collectively amount to a major issue/risk.

Code: Select all

nas1:/# uname -a
Linux nas1 2.6.17.8ReadyNAS #1 Tue Jun 9 13:59:28 PDT 2009 padre unknown
nas1:/# smbd --version
Version 3.0.34


From the logs:

Code: Select all

Jan 23 23:06:37 nas1 udhcpd: udhcp server (v0.9.8) started


[WSJ]

Thanks for the confirmation.

[IanSav]

Hi,

Are there any updates on this issue. More importantly, are there any fixes coming out soon?

Regards,
Ian.

[biggerbyte]

I have this problem too. 4.1.7 was terrible for me, so I found 4.1.6 online from Netgear and reverted back to 4.1.6.. All is good again.

[WSJ]

Did anyone filed an official bug report at Netgear, already?
Although Netgear employees are reading the forum postings, this is not equivalent to an official bug report.
Has anyone obtained a case number?

[IanSav]

Hi WSJ,

Did anyone filed an official bug report at Netgear, already?
Although Netgear employees are reading the forum postings, this is not equivalent to an official bug report.
Does anyone obtained a case number?

I haven't submitted an official bug report as Australian time zones don't map well with USA support times.

In the past such actions were unnecessary as staff here were quick to act and resolve bugs. It looks like Netgear no longer cares about its products. Overall the quality and timing of support has been declining for a while now. This is not like the good old days when Infrant never seemed to release a bad build to the public. If anything problematic ever did get out there was usually a patch within hours. It never took more than a few days for issues to be resolved. I remember when individual issues, like my problematic HP OfficeJet 9130, received individual attention on this forum with a patch being cut and made available for the very few others who also had issues with this multifunction printer. Contrast that with the current situation where there is a SMB problem affecting many, many users and we cant seem to get any traction for a fix.

If someone closer to the USA doesn't file a formal report and it appears that this is now required I will consider lodging one from Australia.

Regards,
Ian.

[WSJ]

"Your support request has been saved:
The reference number is 14577085, a representative will reply to you shortly."

I'll keep you in the loop.

PS: Linux users are facing the very same problems ... (and they propose to modify /etc/init.d/rc3 to restart samba after booting ReadyNAS)

[IanSav]

Hi WSJ,

Do you have any updates? Has opening a case with Netgear had any beneficial effect?

Regards,
Ian.

[WSJ]

Do you have any updates? Has opening a case with Netgear had any beneficial effect?

So far: no. Initially the support guy seem not to have taken a deeper look onto the referenced forum posting, even.
Final statement: "I will consult with my colleagues and then contact you once I've updated information".
So, let's wait and see.

[WSJ]

I've just reproduced the issue, again.
In smbd.log I've found the following entries (created during the relevant time frame):

Code: Select all

[2011/02/14 18:45:24, 0] lib/util_sock.c:get_peer_addr(1334)
  getpeername failed. Error was Transport endpoint is not connected
[2011/02/14 18:45:24, 0] lib/util_sock.c:get_peer_addr(1334)
  getpeername failed. Error was Transport endpoint is not connected
[2011/02/14 18:45:24, 0] lib/util_sock.c:write_data(562)
  write_data: write failure in writing to client 0.0.0.0. Error Connection reset by peer
[2011/02/14 18:45:24, 0] lib/util_sock.c:send_smb(871)
  Error writing 4 bytes to client. -1. (Connection reset by peer)
[2011/02/14 18:45:51, 2] auth/auth.c:check_ntlm_password(309)
  check_ntlm_password:  authentication for user [xxx] -> [xxx] -> [xxx] succeeded
[2011/02/14 18:46:24, 0] lib/util_sock.c:get_peer_addr(1334)
  getpeername failed. Error was Transport endpoint is not connected
[2011/02/14 18:46:24, 0] lib/util_sock.c:write_data(562)
  write_data: write failure in writing to client 192.168.2.115. Error Connection reset by peer
[2011/02/14 18:46:24, 0] lib/util_sock.c:send_smb(871)
  Error writing 4 bytes to client. -1. (Connection reset by peer)
[2011/02/14 18:46:50, 2] auth/auth.c:check_ntlm_password(309)
  check_ntlm_password:  authentication for user [xxx] -> [xxx] -> [xxx] succeeded
[2011/02/14 18:47:30, 0] smbd/server.c:main(942)
  smbd version 3.0.37 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2009
[2011/02/14 18:47:47, 2] auth/auth.c:check_ntlm_password(309)
  check_ntlm_password:  authentication for user [xxx] -> [xxx] -> [xxx] succeeded


Remarkable: the "lib/util_sock.c" error entries.
18:45:24 - 18:46:50: 86 seconds waiting time. That's how long it took for the SMB network discovery.
([xxx] - I've replaced the actual username by 'xxx', '192.168.2.115' is the IP address of the PC requesting the share from the NAS)

At 18:47 I've stopped and restarted the CIFS service, see daemon.log (same in system.log):

Code: Select all

Feb 14 18:47:08 NAS avahi-daemon[694]: Got SIGHUP, reloading.
Feb 14 18:47:08 NAS avahi-daemon[694]: Service group file /etc/avahi/services/cifs.service vanished, removing services.
Feb 14 18:47:09 NAS smbd[3061]: PAM pam_putenv: delete non-existent entry; KRB5CCNAME
Feb 14 18:47:31 NAS avahi-daemon[694]: Got SIGHUP, reloading.
Feb 14 18:47:31 NAS avahi-daemon[694]: Loading service file /etc/avahi/services/cifs.service.
Feb 14 18:47:32 NAS avahi-daemon[694]: Service "NAS (CIFS)" (/etc/avahi/services/cifs.service) successfully established.
Feb 14 18:47:59 NAS smbd[3189]: PAM pam_putenv: delete non-existent entry; KRB5CCNAME


After that, access to the shares worked - and in smbd.log there are no more "lib/util_sock.c" error entries.
("NAS" is the hostname of my ReadyNAS Duo)

network_settings.log does not show any network problems:

Code: Select all

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx 
          inet addr:192.168.2.100  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:7936  Metric:1
          RX packets:4992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2886 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2049130 (1.9 MiB)  TX bytes:3491373 (3.3 MiB)
          Interrupt:41

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:38918 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38918 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2697778 (2.5 MiB)  TX bytes:2697778 (2.5 MiB)

JUMBO_FRAMES_eth0=1
SPEED_DUPLEX_eth0=AUTO_NEGOTIATION


[knefas]

I have a feeling this might be related to something more general than samba, as I have the same problem (very slow to mount) on nfs shares (also reported on http://www.readynas.com/forum/viewtopic.php?f=17&t=47624), and restarting the nfs daemon seems to fix it (at least temporarily).

[WSJ]

Good point - well, it seems that 4.1.7 has numberous bugs