Slow file transfer on wifi

My laptop is Windows 7 Home Premium 64-bit. There is a WD My Book Live 2TB NAS device connected to a Linksys E2500 wifi router. The NAS has a public share which is mapped as X: on the laptop. When I do a 700MB speed test using the Totusoft LAN Speed Test utility from the laptop to X:, it completes successfully, giving me a 4MB/sec throughput. So far so good.

But when I go to a command prompt and do a copy x:\700mb.dat c:\ it takes a couple of minutes and I get a “The specified network name could not be found” error.

I tried doing the same thing using the Windows Explorer UI but that gives me the creeping green progress bar and it eventually errors out so I tried using the command prompt to isolate the problem more.

So I am confused. The speed test utility uses the smbd server on the NAS device to do the file read/write and it works fine so why does the same operation fail when using Windows utilities!

I ssh’ed into the NAS device and tailed the smbd.log and see that when the Windows file copy fails with that “specified network name not found” error, there is a “connection reset by peer” error in the log. So the Windows client (cmd.exe) is dropping the connection but the LAN speed test utility is able to sustain the connection for  700MB write and 700MB read! Why the difference?

What is going on here? What magic does the speed test utility do that Windows 7 does not do? How can I tune Windows so that the NAS device gives me a similar throughput as your utility?!

FYI the same NAS device, when accessed from a wired client, performs flawlessly. So I am not sure what component/pair is the issue here.

Thanks for any help

What type of wireless protocol are you using for the wireless signal? 

The router is a N router. The NIC is set to operate in b/g/n mode

I think a helpful post from another Forum member from earlier on this year may help…

http://community.wd.com/t5/My-Book-Live/WebDAV-Primer-Microsoft-vs-WD-My-Book-Live-etc/m-p/576975

It might be that Windows is getting confused, and has set up the connection as a WebDav connection, rather than a SMB connection.

No, that’s not it. As I mentioned, “I ssh’ed into the NAS device and tailed the smbd.log and see that when the Windows file copy fails with that “specified network name not found” error, there is a “connection reset by peer” error in the log”. So the Samba server on the MBL is indeed serving the file copy request, but it is getting a connection reset command from the client (Windows) side, not sure why.

Any other ideas? I am at my wits end. All other clients, wired and wireless, work fine with the MBL, just Windows 7 wifi has these issues.

I use Windows 7 wireless (Win 7 Home Premium on 5GHz Wireless), with no issues. Have you got congestion on your Wireless channel?

Suggest either using 5GHz (if your Router and Laptop support it), or changing your wireless channel to a less congested one. Use InSSIDer to help you monitor which channels are in use near you.

Alternatively, try a USB Wireless adaptor on your Windows 7 to see if its an issue with your wireless card. 

My router (Linksys E2500) is dual-band so it does support 2.5GHz and 5GHz but currently both of them have the same SSID so all clients pick the 2.5GHz band. I did run InSSIDer and it shows Channel 6 being used with no congestion (that I could tell, not sure I understand how to interpret the InSSIDer UI)

Besides, all other LAN wifi transfers on this Windows 7 laptop work perfectly fine and so does Internet access so I am really perplexed.

I did update the built-in Wifi adapter driver (RealTEK) but I am thinking that, for some reason, it doesn’t play nice with the MBL so I agree with your suggestion to try a USB wifi adapter. I have run out of things to try so I am hoping that works. Fingers crossed, will update this thread with results.

Keep the suggestions coming, thanks!

Sigh, that didn’t work either. I plugged in a USB Wifi N adapter, activated that and tried to copy  a 700MB file from MBL to C:. While this was going on, I opened up Task Manager > Network tab and saw that the utilization sho up to 50% and stayed there for a minute or so. Then it suddenly plummeted to zero and after another minute, the COPY command going on in the CMD.exe window errored out with “The specified network name could not be found”.

Why? Why? This is so frustrating. Note that when the do the same thing with the Totusoft Lan Speed Test utility (read/write a 700MB file), everything else staying the same, it works fine. That utiltity uses SMB too, everything else is the same, so why does that work and a regular file copy using Explorer/command prompt not work?

Help! Thanks

Finally got to the bottom of this. The magic setting that solved my problem turned out to be adding

    smb ports = 139

to the smb.conf file on the WD My Book Live NAS device (after ssh’ing into the device)

The default for this parameter is ports 139 (NetBIOS) and 445 (TCP). Not sure why the default value was causing such a severe performance degradation for file transfers and browsing but my guess is that the Windows 7 client was trying port 445 first, somehow losing the connection and was downgrading to port 139 and was unable to reconnect.

Hope this helps someone else.

Glad you solved your problem.  I’ve got mega low transfer speeds as well.  Are you able to tell me how you go about changing the smb ports to 139 ?

Is it supposed to be 139 or 445 ?  And how can you tell ?

Cheers.

Just FYI, even though the above user improved their situation by modifying the samba configuration, I’ll chime in and say it’s not a generally good idea.

By disabling port 445, he’s basically crippled CIFS, which all OS’s after Win2000 prefer.   Without CIFS, it’s using the antiquated NetBIOS over TCP file transport.

If you disable 445, I’m not even sure ANY other OS’s will work correctly other than Windows (which will fall back to 139 if it needs to.)

In fact, as soon as I tried the above, ALL of my Linux-based systems (including, I suspect, all of my media players) lost their connection to my NAS – and couldn’t get it back.

So, just take that as a warning before you start hacking your system.

But to answer your questions, as the OP said, he added that configuration line to /etc/samba/smb.conf

and restarted the Samba process.

If you don’t know how to do the above, then to put it bluntly, you have no business modifying the configs.

Thanks for your reply. Any other ideas on how to speed up my connection then?

I’ve got the MBL connected to my wireless N router with an Ethernet cable, but when I try and transfer files from my laptop (again wireless N) to the MBL it’s painfully slow.

Even just moving files within the MBL is slow.

Tony - I agree but I was at my wits end. I know my way with computers and believe me I was struggling with this for weeks. I tried just about everything I could to isolate the problem and this was the setting that finally got my throughput on Wifi to a respectable 4-5 MB/s (mega bytes/sec).

I don’t have any Linux devices in my environment so I haven’t noticed any side-effects of this change. So far so good. iOS devices work fine, Android works fine, Windows works fine, haven’t tried streaming using Roku yet.

If my theory about the default value for the smb.conf “smb ports” parameter (139, 445) is accurate (Windows clients try 445 first, somehow lose the connection after a while, attempt to reconnect to port 139 and fail and eventually time out), I guess what I can do to confirm the hypothesis is change the parameter to “smb ports = 445” and see what happens.

vanj131 wrote:

If my theory about the default value for the smb.conf “smb ports” parameter (139, 445) is accurate (Windows clients try 445 first, somehow lose the connection after a while, attempt to reconnect to port 139 and fail and eventually time out 

… you’re probably right…    But if I read the specs correctly, Windows (possibly other) clients actually open both ports 139 and 445 simultaneously.   If a response is received on port 445, the connection on the 139 TCP port receives a TCP RST and is closed.

I know, that’s what was so confusing. See my original post. With (139,445), the file transfer starts off fine so I am guessing it uses CIFS (445) and then after a couple of minutes (I am tailing the smbd logfile), I see “connection reset by peer” which indicates that the smbd server received a abrupt TCP RST packet from the Windows client. I am baffled as to why this would happen.

Looks like the Windows client starts to actually transfer data on port 139 and then kills its own connection? Very strange. Maybe there are some registry settings that control this behavior?