If you copy a directory on a RN104 share from one share to another so that it is reading and writing simultaneous, the connection to the NAS terminates. It does not matter if you have a direct connection or switch between NAS and PC. I have checked that the MTU is OK. If you use NFS, WebDAV or FTP to directory is copied without issues. So I assume there is a bug in the smb configuration of the RN104.
Certainly yes. The problem occurs only with jumbo packets. According to the specification of the RN104 can Jumbo packets, but with SMB there is an bug. I my understanding the reason of a public beta is to find and eliminate this kind of bugs.
Nessi, when you tried it without jumbo frames, the jumbo frames were disabled on the RN104 and your laptop, correct? I see the information in your signature, however it doesn't clarify whether or not you're running jumbo frames on the Samsung r700. Also, out of curiosity can you get me the full model number for the r700 so we can possibly check the samsung website and see exactly which network adapter it shipped with? I'm also assuming that since you mention the GS108ev2 that this is all being done over a wired connection.
edit: Also, did this configuration and transfer work prior to 6.1.6 rc10?
Hi Grievous, I noticed it first with 6.1.6 RC3, maybe that it has been around longer.
Jumbo frames was disabled on RN104 and laptop when it was OK. When I checked with 4086 or 9014 (on both sides) I got the issue.
I checked with GS108ev2 , an older Allnet switch and direct connected (NAS – laptop) by 2m cat6 cable. Ping was always OK with jumbo frames enabled. (Sorry in german, its WIN7/64, german installation) C:\>ping rn104 -f -l 8972 Ping wird ausgeführt für rn104 [192.168.2.10] mit 8972 Bytes Daten: Antwort von 192.168.2.10: Bytes=8972 Zeit<1ms TTL=64 Antwort von 192.168.2.10: Bytes=8972 Zeit<1ms TTL=64 .. Ping-Statistik für 192.168.2.10: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms C:\>ping rn104 -f -l 8973 Ping wird ausgeführt für rn104 [192.168.2.10] mit 8973 Bytes Daten: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt. Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt. .. Ping-Statistik für 192.168.2.10: Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),
The NIC in the Samsung NP-R700 is a Marvell Yukon 88E8055 PCI-E Gigabit Ethernet Controller. Driver 11.45.4.3 from 23.03.2012.
When I use CrystalDiskMark 3.0.3 x64 , 100MB file, on a iSCSI drive I get Sequential Read / Sequential Write 76Mb/s / 54Mb/s jumbo 9000 enabled, 57Mb/s / 25Mb/s without jumbo. So it is a big difference and I would like to use jumbo frames.
No change with RC13. Steps to reproduce: copy bigger file from one share on RN104 to another share.
Here from a cmd windows, hope it helps: 1. DIR of the share, you see the file sizes 2. Copy of a small file, 54 kB . -> OK 3. Copy of a bigger file 384 Mb -> fails. Cannot access the file, another process is using it.
---- C:\>dir "\\RN104\Install\Microsoft\Office2010 Microsoft Home Use Program" Datenträger in Laufwerk \\RN104\Install: ist Install Volumeseriennummer: 10A6-16F2 Verzeichnis von \\RN104\Install\Microsoft\Office2010 Microsoft Home Use Program 30.12.2013 11:19 <DIR> . 30.12.2013 11:23 <DIR> .. 06.11.2010 08:13 54.309 Kaufbestätigung Office2010 und Key.pdf 29.06.2011 13:06 384.824.304 officesuite2010sp1-kb2460049-x86-fullfile-de-de (1).exe
C:\>copy "\\RN104\Install\Microsoft\Office2010 Microsoft Home Use Program\Kaufbestätigung Office2010 und Key.pdf" \\RN104\test 1 Datei(en) kopiert.
C:\>copy "\\RN104\Install\Microsoft\Office2010 Microsoft Home Use Program\officesuite2010sp1-kb2460049-x86-fullfile-de-de (1).exe" \\RN104\test Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. 0 Datei(en) kopiert.
Can you do that copy just using copy and paste(ctrl+c and ctrl+v) shortcuts from windows explorer? And were your failed copies always from the command line? Also, just which version of windows are you using?
Can you do that copy just using copy and paste(ctrl+c and ctrl+v) shortcuts from windows explorer? And were your failed copies always from the command line? Also, just which version of windows are you using?
It makes no difference whether I use cmd, copy and paste or drag and drop the file. I also disabled AV software (on NAS and on PC) to be sure, but it’s the same. If I map the same share using NFS it’s OK.
: SMB -> stop responding net use K: \\192.168.2.10\test /PERSISTENT:NO /user:##### ########
: NFS -> OK : mount -o nolock -u: ##### -P: ######## 192.168.2.10:/data/test J:
My initrd.log: [2013/12/26 16:16:40] Factory default initiated by Frontview! [2013/12/26 16:17:08] Defaulting to X-RAID2 mode, RAID level 5 [2013/12/26 16:17:36] Factory default initiated on ReadyNASOS 6.1.5. [2014/01/04 05:15:40] Updated from ReadyNASOS 6.1.5 to 6.1.6. [2014/01/04 12:53:40] Updated from ReadyNASOS 6.1.6 to 6.1.5. [2014/01/04 13:10:31] Updated from ReadyNASOS 6.1.5 to 6.1.6. [2014/01/08 03:07:34] Updated from ReadyNASOS 6.1.6 to 6.1.6. [2014/01/09 00:53:21] Updated from ReadyNASOS 6.1.6 to 6.1.6. [2014/01/10 00:34:14] Updated from ReadyNASOS 6.1.6 to 6.1.6. [2014/01/15 03:58:09] Updated from ReadyNASOS 6.1.6 to 6.1.6. [2014/01/16 11:25:02] Updated from ReadyNASOS 6.1.6 to 6.1.6. [2014/01/22 05:11:06] Updated from ReadyNASOS 6.1.6 to 6.1.6. [2014/01/28 00:39:36] Updated from ReadyNASOS 6.1.6 to 6.1.6.
I tried to disable and enable SMB by frontview but it did not work. After killing both instances of smbd I enabled it again by frontview and it’s running again now without consuming all CPU resources.
