NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
IanSav
Nov 30, 2010Apprentice
4.1.7 Slow To Respond To SMB Network Discovery...
Hi,
Since upgrading my DUO to 4.1.7 I have noticed that the DUO is *very* slow to respond SMB/SAMBA network share enumeration requests. It may take up to about a minute for the DUO to provide its list of shares. The problem happens *every* time the DUO is asked to list its shares and not just for the first request. This was not an issue under 4.1.6. (I never ran any of the betas and upgraded from 4.1.6 production directly to 4.1.7 production. There were no obvious issues with the upgrade.)
On a client PC this results in about a minute of waiting before the DUO responds with a share list. This is long but not particularly problematic. On the other hand, to my media players this response is *so* long that the media player times out and is no longer able to find the DUO. This is *very* problematic.
This is only happening on my DUO with 4.1.7. The same DUO with 4.1.6 was fine and my NVX with 4.2.15 is also fine.
Is it possible to get a patch to repair this issue? Is there anything I can do to restore the previously snappy performance? Is it safe/possible to revert to 4.1.6?
Regards,
Ian.
Since upgrading my DUO to 4.1.7 I have noticed that the DUO is *very* slow to respond SMB/SAMBA network share enumeration requests. It may take up to about a minute for the DUO to provide its list of shares. The problem happens *every* time the DUO is asked to list its shares and not just for the first request. This was not an issue under 4.1.6. (I never ran any of the betas and upgraded from 4.1.6 production directly to 4.1.7 production. There were no obvious issues with the upgrade.)
On a client PC this results in about a minute of waiting before the DUO responds with a share list. This is long but not particularly problematic. On the other hand, to my media players this response is *so* long that the media player times out and is no longer able to find the DUO. This is *very* problematic.
This is only happening on my DUO with 4.1.7. The same DUO with 4.1.6 was fine and my NVX with 4.2.15 is also fine.
Is it possible to get a patch to repair this issue? Is there anything I can do to restore the previously snappy performance? Is it safe/possible to revert to 4.1.6?
Regards,
Ian.
179 Replies
Replies have been turned off for this discussion
- WSJTutor
IanSav wrote: 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. :roll: - WSJTutorI've just reproduced the issue, again.
In smbd.log I've found the following entries (created during the relevant time frame):[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):
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:
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 - knefasAspirantI 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).
- WSJTutorGood point - well, it seems that 4.1.7 has numberous bugs
- IanSavApprenticeHi WSJ,
WSJ wrote: Good point - well, it seems that 4.1.7 has numberous bugs
And still no reaction or action from Netgear. :(
Regards,
Ian. - WSJTutorWell, maybe it would help if really everybody who is effected by the bugs would submit a support message.
The more customers are reporting problems, the harder it will be to ignore them.
And: it spoils the (internal) statistics ... (and might also have a negative impact on manager's KPIs ...). - Exo1AspirantStill no action/reaction? :evil:
- WSJTutorUnfortunately not ...
- biggerbyte1AspirantWell, I mentioned earlier that going back to 4.1.6 fixed the issues we are seeing with 4.1.7. I thought all was well, and it is for the most part. But suddenly now I keep getting these emails telling me that there is a firmware update, version 4.1.7, that is available. I used to never get this when I had a firmware update available. The message appears to be sent from/by the NAS. It is every few days, and it is soooooo annoying.
Any ideas? - MilhouseTutor
biggerbyte wrote: Well, I mentioned earlier that going back to 4.1.6 fixed the issues we are seeing with 4.1.7. I thought all was well, and it is for the most part. But suddenly now I keep getting these emails telling me that there is a firmware update, version 4.1.7, that is available. I used to never get this when I had a firmware update available. The message appears to be sent from/by the NAS. It is every few days, and it is soooooo annoying.
Any ideas?
Always been working that way, either you didn't automatic update checks enabled or it was somehow broken but is now fixed with your new 4.1.6 install. To stop the emails, try the following:
System -> Update -> Settings
Uncheck "Automatically check for updates"
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!