Upgraded from r41986 to r45563. Results:
No reset, auto-neg: SMB transfer speed varying sharply 25 - 90 Mbps (avg. ~52 Mpbs)
Reset via GUI, auto neg: SMB transfer speed 50 - 140 Mbps (avg. ~95 Mbps)
Reset via GUI, 100/full: SMB transfer speed stable ~95 Mbps
Back to r41986, reset, auto neg: SMB transfer speed ~250 Mbps mostly stable, small dips to 200 Mbps every 5 seconds or so.
After factory reset, I just disabled Wifi and enabled USB/NAS. No WAN, just one Windows 10 (2004) PC connected to LAN port. No other changes.
At this point, I doubt the issues are related to Samba, but I don't know how to dig deeper into the networking parts.
Hi everyone... I had some similar issues with samba connection from my old macbookpro (El Capitan) connecting on my HDD (NAS) connected on my R7000 with the last dd-wrt firmware updates, all of them, I can't get it work properly. Sharing files they was half missing and after disconnection I was unable to reconnect to it. The only way it was applying from dd-wrt GUI refreshing. Until I tried yesterday night to downgrade from the almost last version 45493 to last summer build kong Firmware: DD-WRT v3.0-r39960M kongac (06/08/19)
Samba on my OSX version turn back to work properly.. sharing files all visible and connection/disconnection without any issues.
Joined: 26 Mar 2013 Posts: 1856 Location: Hung Hom, Hong Kong
Posted: Tue Jan 26, 2021 13:32 Post subject:
One thing regarding the new kernel-mode Samba: after I copied a lot of MP3 files to a public writable share from Win 10, the Samba share would stop responding. The only solution was to re-start it. MiniDLNA was not affected.
I copied the music files by NET USE the share as a drive then ROBOCOPY. My Asus RT-N18U was still using build 45000, and it's a wired gigabit LAN connection. The files were stored on a Sandisk USB 3.0 flash drive, ext4 partition.
I didn't bother to do extensive testing though, but here were some strange log entries:
Jan 5 16:40:15 RT-N18U kern.err kernel: ksmbd: ksmbd_vfs_set_sd_xattr:1599: Failed to store XATTR sd :-95
Jan 5 22:25:33 RT-N18U kern.err kernel: ksmbd: ksmbd_conn_handler_loop:339: sock_read failed: -108
I suspect this socket (or USB?) error might happen to Transmission as well, for big files WRITEs. I think drive reading is fairly stable.
I am going to do the continuous, bulk copy again next build to check if it crashed kernel-mode Samba again....
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Changed the USB connection to the front port on my r7000.
This immediately boosted NAS throughput. With the CPU overclocked to 1200 MHz, idle CPU went from about 30% to 5%, boosting write transfer speed from 250 Mbps to 340 Mbps (on r41986).
(Without overclocking, CPU was about 15% idle before, so expected transfer speed boost will be proportionally less)
Example
On the r7000 router, setting switch port 1 to 100/full duplex (assuming default settings otherwise):
Code:
nvram set port1vlans='1 17 21'
nvram commit
Haven't done any further testing, but the ksmbd data integrity issue could be related to socket handling. Read something about data loss if the socket isn't read properly (in time). I'm just speculating and unable to confirm for now.
I've just reformatted an attached USB NAS to ext4, and have had perfect wifi transfers to and from the drive.
However, when the USB NAS is formatted exFat ... transfer of files is only sporadic until completely unable to write.
Although a reformat of the USB NAS to ext4 always solves the write issues, it doesn't help that the NAS can't be consistantly available to devices other than those that can write to ext4 (iPads, Mac, etc).
Unsure if there's a smb3 issue in dd-wrt concerning drives formatted in exFat?
Netgear R7000 ... dd-wrt build r45632 with either smb 2 or smb3 enabled = exfat file system identified as formattable (red format button) where the actual format process was not able to be completed. Several simultaneous attempts where USB NAS file system was still stuck in ext4 after format-commit-save-reboot process.
Although a reformat of the USB NAS to ext4 always solves the write issues, it doesn't help that the NAS can't be consistantly available to devices other than those that can write to ext4 (iPads, Mac, etc).
Samba "hides" the drive format by standardizing the access protocol. Unless you need to directly connect the USB drive to Windows, an ext4 format will work just fine using dd-wrt based NAS.
I have used NTFS and ext4 formats for my USB drives. Both work, but I'm sticking with ext4 as it is native to Linux.
On old kong builds, never had any samba issues neither need to change partition format on the external HDD (NAS) NTFS. I had other issues like wifi drops a few seconds ( 1 time in two days )but that is an other story
I'm testing this one since yesterday Firmware: DD-WRT v3.0-r40270M kongac (07/11/19)
Samba NAS connection works like olders kongs firmwares... none issues at all...
I'm hope new beta's releases will fix this sambas issues connectivity without change partition format.
P.S: The "Samba issue" only happens under OSX (El capitan and Catalina) using finder to connect to it. I've tried using ssh on terminal and is shows all files under Win10 works good... All this using last firmwares std betas...
Joined: 18 Mar 2014 Posts: 12879 Location: Netherlands
Posted: Thu Feb 04, 2021 17:02 Post subject:
L30Z3N wrote:
On old kong builds, never had any samba issues neither need to change partition format on the external HDD (NAS) NTFS. I had other issues like wifi drops a few seconds ( 1 time in two days )but that is an other story
I'm testing this one since yesterday Firmware: DD-WRT v3.0-r40270M kongac (07/11/19)
Samba NAS connection works like olders kongs firmwares... none issues at all...
I'm hope new beta's releases will fix this sambas issues connectivity without change partition format.
P.S: The "Samba issue" only happens under OSX (El capitan and Catalina) using finder to connect to it. I've tried using ssh on terminal and is shows all files under Win10 works good... All this using last firmwares std betas...
We seem to be talking about different things.
There is no discovery service for Linux/OSX running any more only wsdd for Windows discovery so Linux/OSX must use the IP address.
The only way around this is to implement Avahi (or the likes)
The other problems where ksmb does not always work especially not when using ntfs seem to be (almost) solved.
When using K4.4. build you probably have to set max protocol to 2.10 (as it is using antfs) for K4.9 you can probably use 3.11 when using Windows clients (for Linux/OSX probably still 2.10) K4.9 is using the new Paragon ntfs3 driver
Of course as @CandaMoose remarked you can just use ext4
But even then no discovery for Linux/OSX as far as I can tell.
On old kong builds, never had any samba issues neither need to change partition format on the external HDD (NAS) NTFS. I had other issues like wifi drops a few seconds ( 1 time in two days )but that is an other story
I'm testing this one since yesterday Firmware: DD-WRT v3.0-r40270M kongac (07/11/19)
Samba NAS connection works like olders kongs firmwares... none issues at all...
I'm hope new beta's releases will fix this sambas issues connectivity without change partition format.
P.S: The "Samba issue" only happens under OSX (El capitan and Catalina) using finder to connect to it. I've tried using ssh on terminal and is shows all files under Win10 works good... All this using last firmwares std betas...
We seem to be talking about different things.
There is no discovery service for Linux/OSX running any more only wsdd for Windows discovery so Linux/OSX must use the IP address.
The only way around this is to implement Avahi (or the likes)
The other problems where ksmb does not always work especially not when using ntfs seem to be (almost) solved.
When using K4.4. build you probably have to set max protocol to 2.10 (as it is using antfs) for K4.9 you can probably use 3.11 when using Windows clients (for Linux/OSX probably still 2.10) K4.9 is using the new Paragon ntfs3 driver
Of course as @CandaMoose remarked you can just use ext4
But even then no discovery for Linux/OSX as far as I can tell.
But things are changing more rapidly then the corona virus is mutating so never know what tomorrow brings
Thank you egc to replay and clarified. I will give a try then to last beta build to see if I can use it with my OS, trying to change different smb protocols.
ATM I'm using this version:
Router ModelNetgear R7000