WARNING: Network data corruption on RC5

[João Cardoso]

Hi,

There are evidences of network data corruption on RC5.

One such evidence is the empty Status page, but data corruption might occur while reading any file from the NAS.

All models (the DNS-321/323/320/320L/325) but the DNS-327L are affected.

Bill Rosenberg has found the culprit and you should take the necessary measures to avoid data loss/corruption on your box.

You can find and follow Bill's solution here

To apply it automatically, you have to:

1-install the Alt-F 'ethtool' package (Packages->Alt-F, if not yet installed select first the filesystem were to install)
2-create a "user boot script" that runs at boot time and executes the necessary command.

2-a) Go to Services->User, user Configure,

2-b) on the "Script to execute on powerup" specify a file name on the same filesystem where Alt-F packages were installed

  (such as /mnt/sda2/user.sh if Alt-F were installed in sda2, or /mnt/md0/user.sh if Alt-F were installed in md0, or /mnt/sda4... )

2-c) hit the "Edit" button and after the line

echo "Starting $0"

add the line

/Alt-F/usr/sbin/ethtool -K eth0 tso off

2-d) hit the Submit button.

2-e) After returning to the User Services page, hit the user StartNow button.

3-"Save Settings".

There is no need to reboot, although you want to do it to verify that the command is executed.

To verify that you have to ssh or telnet the box and login as the 'root' user, same password as the webUI, then issue the command

ethtool --show-offload eth0 | grep tcp-segmentation

which should be 'off'

This is the definitive fix and you MUST apply it.

João Cardoso

[Bill Rosenberg]

The script command will need the full path to ethtool to work:

/Alt-F/usr/sbin/ethtool -K eth0 tso off

/usr/sbin doesn't work either since I guess the /Alt-F path hasn't been mounted yet by aufs when this script is run.

[João Cardoso]

Thanks. I will change the instructions to install the script in the same filesystem where the Alt-F packages are installed,  as I don't want to encourage users to use the /Alt-F folder for *any* purpose.

As the last step of a filesystem discovery, the boot user script existence is checked and executed, so this way it will always work.

[Bill Rosenberg]

I don't think I'm understanding your last comment. I have Alt-F installed on /mnt/md0 and installed the script there as well, but unless I use the path in the ethtool command I get a "not found" error in the log when booting.

[João Cardoso]

Bill, do you mind reading this?

According to it "generic segmentation offload" also needs to be disabled?

I don't know how to check that, and I don't want to disable features just for precaution, as it might have unnecessary negative impact on performance (throughput can even be the same at expenses of an increase in cpu load, which will impair other box apps)

The IBM Knowledge center even recommends disabling scatter-gather, but all those docs might be outdated now or apply to specific hardware.

I have difficulties setting up a fast test environment to test this issue. I tested with linux NFS and SMB mounts and transferred ~5GB of data back and forth several times without any  issue (with TSO on). Only smbclient transfers shows an occasional file corruption.

My testbed is

1-mount a box share in a linux computer using NFS or SMB

2-copy a folder from the linux computer to the mount point

3-copy from the mount point to a new folder in the linux computer

4-compare sent and received folders using 'cmp' 

This is much faster that comparing in the box or calculating md5 or sha1 hashes. OS data caching shouldn't be a problem, as there are only 4GB RAM on the linux PC (have to further research this, invalidate cached data)

On Saturday, 9 July 2016 05:19:00 UTC+1, Bill Rosenberg wrote:

[João Cardoso]

On Saturday, 9 July 2016 16:41:48 UTC+1, Bill Rosenberg wrote:

I don't think I'm understanding your last comment. I have Alt-F installed on /mnt/md0 and installed the script there as well, but unless I use the path in the ethtool command I get a "not found" error in the log when booting.

Looking at the code now... and you are right.

The user initscript (that runs the user written boot script) runs early at boot time, and at that time a lock exists to prevent aufs to mount.

Fixing the instructions...

Thanks

[Norbert Horváth]

My tests yesterday showed that disabling TSO alone solved the problem, at least for me. My network throughput is about 5-10Mbytes/sec, so disabling tso, gso and scatter-gather had no further impact on it (so I am disabling everything that might be connected to the errors...).
I chose a folder on my Win7 PC with a few hundred small files (<10Mbyte), calculated an .md5 with Total Commander, copied everything to the NAS and checked the hash with Total Commander. I know it means that TC fetches the files back for the check through the network, but in my case these relatively small and few number of files were more than enough to produce many errors with TSO on (and zero errors with tso off after many repeated tests). I do not fully understand the tso bug yet (also I am a bit ashamed), but I feel that it is better to test many different sized smaller files than one huge.

[Bill Rosenberg]

We are definitely way out of my knowledge area now. I looked at that link but it seems to be the only one saying gso has to be disabled too. Others like this and this imply to me they are independent. In any case, disabling tso alone has been proven to make a difference based on my very basic test with the status page and the great work Norbert did. So personally I am going to just disable tso.

Do you think the true fix will require going back to an older kernel since RC4.1 didn't have this issue? I just use my 323 for file backups so any potential performance hit from having tso disabled is not a big deal to me.

[João Cardoso]

On Sunday, 10 July 2016 14:26:03 UTC+1, Bill Rosenberg wrote:

We are definitely way out of my knowledge area now. I looked at that link but it seems to be the only one saying gso has to be disabled too. Others like this and this imply to me they are independent. In any case, disabling tso alone has been proven to make a difference based on my very basic test with the status page and the great work Norbert did. So personally I am going to just disable tso.

Do you think the true fix will require going back to an older kernel since RC4.1 didn't have this issue?

No, the kernel was updated to support the DNS-327L, so future Alt-F releases will either have the bug fixed or TSO disabled by default.

Our box network driver has seen several fixes regarding tso, one of them explicitly referring data corruption, see the messages for the last kernel and the previous discussion that occurred.

The changes themselves are out of my comprehension, but the description is self-explanatory.

After my vacations I might try to backport the "net: mv643xx_eth: fix packet corruption with TSO and tiny unaligned packets." and "net: mv643xx_eth: Ensure proper data alignment in TSO TX path)" .

The 3.18.28 kernel we use has seen 8 fixes meanwhile, but none of them regarding tso. It is possible that a fix from a more recent kernel to be backported to 3.18, but that is uncertain.

I was never able to reproduce the status page issue on my linux computers. And file corruption is very, very rare to happens to me even when using several protocols, so I couldn't setup an efficient testbed for experimenting or confirming possible fixes. I have now transferred hundreds of GB.

I get one file that is consistently corrupted (on reading from the box), so might be the bug is data driven?

 

I just use my 323 for file backups so any potential performance hit from having tso disabled is not a big deal to me.

With tso disabled I experience a 10 to 15% lower throughput (from 13MBps to 11.5MBps on sustained NFS read transfers from the box).

[Bill Rosenberg]

Looking at the fix descriptions, I agree they seem related to our problem. When the status page was failing, I was seeing a packet with a 2-byte payload as corrupted in the Wireshark trace.

I will be happy to test any beta build you create with backported fixes. Until then have a good vacation.

[Gabriele Desinano]

Hi,  I flashed one DNS-323 and 3 DNS-325.

The DNS-323 upgrade form RC4.1 gone fine
The fisrt DNS-325 upgrade from RC4.1 gone fine too
The second DNS-325 upgrade gone fine, the same for the first reboot and after having selected the previoud ALT-F sistem directory for packages, the firmware backed to RC4.1
 Every new try to upgrade to the RC5.0 ended with message "invalid configuration". Impossible to save impossible to load an old configuration. After having removed the ALT-F packaged installation and reboot, then the firmware backed to RC5.
 Tried again to install ALT-F packages but again baked to RC4.1. Tried a lot of time with the same results.
The third DNS-325 upgrade returned to me the error about wrong firmware file (the same used for the previous 2)

 Downloaded again the firmware one, two three times and tried a lot of upgrades after reboot or switched off the DNS with the same error page about a sha1 error. Any time the sha1 read was different as I had read different files but they was always the same.
One time  I didn't get the error and the page was ready for the upgrade but I stopped the upgrade and tried again whit the same fiel and got error again and again. Thought it wasn't a problem about the file so I checked the system time and found it where wrong.
Paired the time then  I tried the upgrade and it gone right at the first try. Anyway it was due to a case because I tried to upload the firmware again through the RC5 firmware upgrade page and the same file and the other refused to upload because they  readed as wrong.
I think it is an internal problem in the calculation of the sha1 that everytime is different eccept for the time it works.

The trouble of the RC4.1 revived after the flas appens only to the second DNS-325.

I


Il giorno venerdì 8 luglio 2016 23:16:28 UTC+2, João Cardoso ha scritto:

Hi,

There are some evidences of network data corruption on RC5. The DNS-323 and possibly other models are affected.

The exact cause is still under investigation, but Bill Rosenberg has found the possible culprit.

This is all yet preliminary but you should take the necessary measures to avoid data loss/corruption on your box.

You can find and follow Bill's tentative solution here

If you want that to be applied automatically, you have to

1-install the Alt-F 'ethtool' package (Packages->Alt-F, if not yet installed select first the filesystem were to install)
2-create a "user boot script" that runs at boot time and executes the necessary command.

2-a) Go to Services->User, user Configure,

2-b) on the "Script to execute on powerup" specify a file name on the same filesystem where Alt-F packages were installed

  (such as /mnt/sda2/user.sh if Alt-F were installed in sda2, or /mnt/md0/user.sh if Alt-F were installed in md0, or /mnt/sda4... )

2-c) hit the "Edit" button and after the line

echo "Starting $0"

add the line

/Alt-F/usr/sbin/ethtool -K eth0 tso off

2-d) hit the Submit button.

2-e) After returning to the User Services page, hit the user StartNow button.

3-"Save Settings".

There is no need to reboot, although you want to do it to verify that the command is executed.

To verify that you have to ssh or telnet the box and login as the 'root' user, same password as the webUI, then issue the command

ethtool --show-offload eth0 | grep tcp-segmentation

which should be 'off'

This is *NOT* a definitive fix, so stay tuned.

Unfortunately (?) I will go for vacations next monday and I will not have access to my boxes until mid August, so the definitive solution has be found in this forum.

João Cardoso

[dchar...@gmail.com]

I can confirm this with a DNS-320 HW version A2 (using ALt+F RC5).

After I turned off the tcp segmenataion offload with /usr/sbin/ethtool -K eth0 tso off all my CRC problems are gone.

In fact the previously uploaded content's recheck showed no errors anymore, this means that the upload is usually good, only the DL direction is affected.

I also had a Status page blank error, which is also gone.

Regards,

Csaba

[Mark Townley]

Hi

What affects would you see with this issue?  I have witnessed the following and was wondering if it was down to this issue:

cant copy anything from nas drive to pc or to usb drive.

video anomaly's in the picture and sound when streaming media.

no status page

Is it safe to roll back to RC4 from 5?

[Bill Rosenberg]

I would say yes that all the issues you mention are due to the TX Segmentation Offload bug. It is easy to test this yourself by installing ethtool and trying the command listed at the the beginning of the thread. If it works you can follow the instructions so that it is run at every boot. Then you don't have to worry about downgrading.

[Norbert Horváth]

If you are already using RC5, try the ethtool tso-disabling command first. If file transfer or streaming does not produce errors and network speed is still acceptable, RC5 will be fine until a final bugfix.
You can go back to 4.1, but some of the already upgraded packages in Alt-F folder may not function properly with 4.1, you need to downgrade (uninstall) them, but no further tests had been done to find what will fail, because this mixed environment should not be used normally.

[Paulo Elifaz Andrielli]

Hi Mark,

Yes, you can rollback to previous RC. I did that on my DNS-323B1 (it was 5, I moved back to 4.1).

The only thing to consider during this downgrade is that the updated packages will stay in the latest version, but the kernel issue (videos being pixelated, error in file copying as reported here) were gone. Everything working fine now.

Please check a thread with title "[Alt-F] Special Reboot is not working on a DNS-323-rev-B1" about an issue with some folders, if you are not being able to downgrade it.

[]'s
Paulo
sent from Android

--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/alt-f.
For more options, visit https://groups.google.com/d/optout.

[Mark Townley]

I followed the instructions and it fixed the issue.  When streaming media it now does not seem to pixelate the image at random points or skip. 

Thank You

[Andrew Zaikin]

Disabling TSO solves issues at DNS-320L A2, but there is a minor bug at step 2-d.

Alt-f packages are installed at /sda4, but when I'm saving changes, it says only sda2 or md0 can be used

On Saturday, 9 July 2016 00:16:28 UTC+3, João Cardoso wrote:

Hi,

There are some evidences of network data corruption on RC5. The DNS-323 and possibly other models are affected.

The exact cause is still under investigation, but Bill Rosenberg has found the possible culprit.

This is all yet preliminary but you should take the necessary measures to avoid data loss/corruption on your box.

You can find and follow Bill's tentative solution here

If you want that to be applied automatically, you have to

1-install the Alt-F 'ethtool' package (Packages->Alt-F, if not yet installed select first the filesystem were to install)
2-create a "user boot script" that runs at boot time and executes the necessary command.

2-a) Go to Services->User, user Configure,

2-b) on the "Script to execute on powerup" specify a file name on the same filesystem where Alt-F packages were installed

  (such as /mnt/sda2/user.sh if Alt-F were installed in sda2, or /mnt/md0/user.sh if Alt-F were installed in md0, or /mnt/sda4... )

2-c) hit the "Edit" button and after the line

echo "Starting $0"

add the line

/Alt-F/usr/sbin/ethtool -K eth0 tso off

2-d) hit the Submit button.

2-e) After returning to the User Services page, hit the user StartNow button.

3-"Save Settings".

There is no need to reboot, although you want to do it to verify that the command is executed.

To verify that you have to ssh or telnet the box and login as the 'root' user, same password as the webUI, then issue the command

ethtool --show-offload eth0 | grep tcp-segmentation

which should be 'off'

[Bill Rosenberg]

With the full path to ethtool listed in the instructions, I don't think it matters if the script is on the same filesystem as Alt-F. Try it and see.

[michael aramini]

ethtool -K eth0 tso off work for me, this solves my problem with the white status page on DNS-320 A+ RC5

[Gregory Didycz]

On Friday, July 8, 2016 at 5:16:28 PM UTC-4, João Cardoso wrote:

Hi,

There are some evidences of network data corruption on RC5. The DNS-323 and possibly other models are affected.

The exact cause is still under investigation, but Bill Rosenberg has found the possible culprit.

This is all yet preliminary but you should take the necessary measures to avoid data loss/corruption on your box.

You can find and follow Bill's tentative solution here

If you want that to be applied automatically, you have to

1-install the Alt-F 'ethtool' package (Packages->Alt-F, if not yet installed select first the filesystem were to install)
2-create a "user boot script" that runs at boot time and executes the necessary command.

2-a) Go to Services->User, user Configure,

2-b) on the "Script to execute on powerup" specify a file name on the same filesystem where Alt-F packages were installed

  (such as /mnt/sda2/user.sh if Alt-F were installed in sda2, or /mnt/md0/user.sh if Alt-F were installed in md0, or /mnt/sda4... )

2-c) hit the "Edit" button and after the line

echo "Starting $0"

add the line

/Alt-F/usr/sbin/ethtool -K eth0 tso off

2-d) hit the Submit button.

2-e) After returning to the User Services page, hit the user StartNow button.

3-"Save Settings".

There is no need to reboot, although you want to do it to verify that the command is executed.

To verify that you have to ssh or telnet the box and login as the 'root' user, same password as the webUI, then issue the command

ethtool --show-offload eth0 | grep tcp-segmentation

which should be 'off'

This is *NOT* a definitive fix, so stay tuned.

Unfortunately (?) I will go for vacations next monday and I will not have access to my boxes until mid August, so the definitive solution has be found in this forum.

João Cardoso

I can confirm that applying the hotfix solved both the Status page in http issue and the data corruption issue.

 

DNS323 A

 

[Wayno]

Thanks for the fix.  Also solved issue with status screen on DNS-321-A1.  I've been having tons of issues with small corruptions in the photos I have stored on the NAS (especially when I access through WiFi) and I expect this will also be resolved with the change.

[Paulo Elifaz Andrielli]

Hi,

I downgraded do RC4 without any problem. Just download it and flash it accordingly to your model.

Regarding family pictures.... Use Google Photos to store them as well. Unlimited space, if you choose a certain resolution there (cant recall which one, but its a good one).

[]'s
Paulo
sent from Android

Em 26/08/2016 09:11, "Edgard Edgard" <edgar...@gmail.com> escreveu:

Hi, I've just started using for first time my Dlink 320L that I bought recently and configured it as a RAID 1 system so my family pictures will be safe...

It corrupted lots of pictures!!! :-( and then I found this warning entrance in the forum. :-)

I want to use my Dlink as a home server but I can't trust it wont destroy my precious and family data.

Is there any solution that we can rely on? I don't want to go back to official firmware.

I think that if this data corruption didn't happen in previous releases it is related with this last from June 16, no?

Will it be safe to downgrade to a previous firmware version? 

Thanks in advance!

--
You received this message because you are subscribed to the Google Groups "Alt-F" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+unsubscribe@googlegroups.com.

[Norbert Horváth]

You can downgrade to 4.1 without any problem. But before deleting everything check if your photos are really corrupted, because sometimes the files are uploaded safely to the NAS and so they are not corrupt (and lost), but they became corrupted only when you try to watch them so they are downloaded to your computer. Try the ethtool fix under RC5 or downgrade to 4.1, both are safe.

Em 26/08/2016 09:11, "Edgard Edgard" <edgar...@gmail.com> escreveu:

Hi, I've just started using for first time my Dlink 320L that I bought recently and configured it as a RAID 1 system so my family pictures will be safe...

It corrupted lots of pictures!!! :-( and then I found this warning entrance in the forum. :-)

I want to use my Dlink as a home server but I can't trust it wont destroy my precious and family data.

Is there any solution that we can rely on? I don't want to go back to official firmware.

I think that if this data corruption didn't happen in previous releases it is related with this last from June 16, no?

Will it be safe to downgrade to a previous firmware version? 

Thanks in advance!

--
You received this message because you are subscribed to the Google Groups "Alt-F" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+un...@googlegroups.com.

[George Alibinisis]

I can confirm data corruption in -download- only. I sent a large .iso or .rar file to the DL320L and uploads without issues. When trying to download, copy, extract there are errrors! 

Solution: downgrade to RC4 and everything works again - various sample files are not corrupted.

Also the status window is blank and there are really slow speeds when transfering files.

BR,

George

[Tom Cadorette]

Just curious -- when will there be a definitive fix release for this issue, and the Status Update screen not properly displaying? I have read the fixes suggested here, and could probably do them without bricking my box, but I'd rather let the more capable folks actually fix the issue rather risk bricking. :)

Thanks, Tom

[Tom Cadorette]

Hey, I didn't break my box by applying the temp fix! :) Didn't realize how simple it was until I read through it.

I used to be a tech savvy guy a LOOOOONG time ago. If you don't use the knowledge, it does wither away.

Thanks for the temp fix, hoping to see the permanent definitive fix soon.

[João Cardoso]

On Monday, 5 September 2016 17:28:39 UTC+1, Tom Cadorette wrote:

Hey, I didn't break my box by applying the temp fix! :) Didn't realize how simple it was until I read through it.

I used to be a tech savvy guy a LOOOOONG time ago. If you don't use the knowledge, it does wither away.

Thanks for the temp fix, hoping to see the permanent definitive fix soon.

Hi,

The published fix in the first post is definitive, and it is pretty simple to apply, as you found out. I will review the post wording to make that clear.

As some have already notice, the issue reveals itself when the NAS *transmits* data, the data itself is correctly stored in the box.

Of course if you read a file from the NAS and there is corruption, and you then save the read file back to the NAS, the corrupted file will se saved.

The issue is rare, and I haven't been able to reproduce it myself on my boxes, but the potential for data loss exists, so the fix MUST be applied!

A word of caution: as the fix is stored on disk, it is applied only when the disk is detected and made accessible; if for some reason the disk is not available the fix will not be applied and data loss can occur on other disks existing on the box.

This is a kernel network driver issue that has plagued several other NAS and distributions, and the fix is always to use the 'ethtool' command.

There is a kernel fix for the issue, but it only applies to more recent kernels, so an Alt-F kernel upgrade is needed. Doing that requires a lot of work and testing, so it will not happen soon.

For disk-based linux distributions it is simple to automatically install the ethtool package and invoke it at startup, but for flash-based NAS it requires reflashing a new firmware.

[Tom Cadorette]

Excellent -- thank you so much! As soon as I can, I will Paypal funds to you again to keep supporting the project.

Tom

[A K]

Hi João,

It might be a good idea for the fix info to be prominently included in the readme file, for folks who may download the project but don't participate in the forum.

Thanks for all your work,

ApK

[João Cardoso]

On Friday, 23 September 2016 04:13:03 UTC+1, A K wrote:

Hi João,

It might be a good idea for the fix info to be prominently included in the readme file, for folks who may download the project but don't participate in the forum.

Done. Thanks

[Richard Lehun]

Hi, its been a while for me in shell. The fillowing appears when I want to enter the hotfix. Where exactly should I insert it? Thanks RL

#!/bin/sh

# Script to execute as the root user at boot time.

# You can loose your data or make the system inaccessible

# if using the wrong commands. You have been warned!

 

exec >> /var/log/user.log 2>&1

case "$1" in

start)

echo "Starting $0"

;;

stop)

echo "Stopping $0"

;;

esac

On Friday, 8 July 2016 17:16:28 UTC-4, João Cardoso wrote:

Hi,

There are evidences of network data corruption on RC5.

One such evidence is the empty Status page, but data corruption might occur while reading any file from the NAS.

All models (the DNS-321/323/320/320L/325) but the DNS-327L are affected.

Bill Rosenberg has found the culprit and you should take the necessary measures to avoid data loss/corruption on your box.

You can find and follow Bill's solution here

To apply it automatically, you have to:

1-install the Alt-F 'ethtool' package (Packages->Alt-F, if not yet installed select first the filesystem were to install)
2-create a "user boot script" that runs at boot time and executes the necessary command.

2-a) Go to Services->User, user Configure,

2-b) on the "Script to execute on powerup" specify a file name on the same filesystem where Alt-F packages were installed

  (such as /mnt/sda2/user.sh if Alt-F were installed in sda2, or /mnt/md0/user.sh if Alt-F were installed in md0, or /mnt/sda4... )

2-c) hit the "Edit" button and after the line

echo "Starting $0"

add the line

/Alt-F/usr/sbin/ethtool -K eth0 tso off

2-d) hit the Submit button.

2-e) After returning to the User Services page, hit the user StartNow button.

3-"Save Settings".

There is no need to reboot, although you want to do it to verify that the command is executed.

To verify that you have to ssh or telnet the box and login as the 'root' user, same password as the webUI, then issue the command

ethtool --show-offload eth0 | grep tcp-segmentation

which should be 'off'

This is the definitive fix and you MUST apply it.

João Cardoso

[Gregory Didycz]

Hi Everyone,

We all know about this data corruption issue, and we know the fix. But as everyone can see the fix puts a big hit on xfer rates. When can we expect a fix that restores performance? I would be willing to beta test on a dns 323 rev a.

Sincerely,
Gregory

[Bill Rosenberg]

Richard, here is the exact content of my script:

#!/bin/sh

# Script to execute as the root user at boot time.
# You can loose your data or make the system inaccessible
# if using the wrong commands. You have been warned!
 
exec >> /var/log/user.log 2>&1

case "$1" in
 start)
  echo "Starting $0"

  /Alt-F/usr/sbin/ethtool -K eth0 tso off

  ;;
 stop)
  echo "Stopping $0"
  ;;
esac

On Tuesday, October 18, 2016 at 6:56:03 AM UTC-5, Richard Lehun wrote:

[João Cardoso]

On Tuesday, 18 October 2016 20:56:26 UTC+1, Gregory Didycz wrote:

Hi Everyone,

We all know about this data corruption issue, and we know the fix. But as everyone can see the fix puts a big hit on xfer rates. When can we expect a fix that restores performance?

Only a new Alt-F release, with a more recent kernel, will fix it.

I'm working on it, and successfully tested it on 323-rev-B/320L-rev-A boxes; the next will be the 327L-rev-A (those three boxes corresponds to the three SoC architectures that Alt-F currently supports).

When that is done I will put them into the Downloads Snapshot section (and you will receive a "news" warning on your Status page box)

 

I would be willing to beta test on a dns 323 rev a.

Thanks for the offer.

I own  five boxes, 323-rev-AB/320L-rev-A/325-rev-A/327-rev-A (only one was bough by myself), so what I really need is testers for the 323-rev-C,321-rev-A/320-rev-A (or if you own one of those that don't use anymore and live in Europe, you could donate it :-)

[Richard Lehun]

Thanks Bill, I have implemented the change as you specify. RL

On Oct 18, 2016, at 16:01, Bill Rosenberg <bill_ro...@hotmail.com> wrote:

Here is the exact content of my script:

--
You received this message because you are subscribed to a topic in the Google Groups "Alt-F" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/alt-f/cFQ6SzsK0ss/unsubscribe.
To unsubscribe from this group and all its topics, send an email to alt-f+un...@googlegroups.com.

[Gregory Didycz]

Thanks for the update João Cardoso

--
You received this message because you are subscribed to a topic in the Google Groups "Alt-F" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/alt-f/cFQ6SzsK0ss/unsubscribe.

To unsubscribe from this group and all its topics, send an email to alt-f+unsubscribe@googlegroups.com.

[Nemesio Garcia]

Hi,

I want to try this solution, but I'm unable to get pass step 1. How do I install the 'ethtool' package? When I go to Packages->Alt-F, I don't see the 'ethtool' package (see attached). I would rather try this solution first before attempting to downgrade. Please help, as some of my photos seem to have gotten corrupted because of this.

Thanks in advance!

[Joao Cardoso]

On Nov 1, 2016 4:33 AM, "Nemesio Garcia" <ngarc...@gmail.com> wrote:
>
> Hi,
>
> I want to try this solution, but I'm unable to get pass step 1. How do I install the 'ethtool' package? When I go to Packages->Alt-F, I don't see the 'ethtool' package (see attached).

That page seems to affected by the "blank status page " issue (a consequence of the network data corruption).

You have to use the command line, ssh/telnet the box and login as the 'root' user, same pass as the webui, and issue the command 'ipkg install ethtool'

> I would rather try this solution first before attempting to downgrade. Please help, as some of my photos seem to have gotten corrupted because of this.

The data is safe on disk, only when reading it the corruption silently attacks.

> --

> You received this message because you are subscribed to the Google Groups "Alt-F" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+un...@googlegroups.com.

[Nemesio Garcia]

Thanks for the prompt response, but I ended up downgrading to 4.1 instead, as my dns323 was very stable with that build. I also validated that all my corrupted photos are good now (I had to remove/re-add them to my photo editing application).

Cheers!

[Rafal B]

Hi,
My bootscript.sh is as follow:

exec >> /var/log/user.log 2>&1

case "$1" in
    start)
        echo "Starting $0"

/Alt-F/usr/sbin/ethtool -K eth0 tso off

        ;;
    stop)
        echo "Stopping $0"
        ;;
esac

When D-Link is booted there is no /var/log/user.log file created and of course command /Alt-F/usr/sbin/ethtool -K eth0 tso off is not executed.
When I add the line sleep 60 before /Alt-F/usr/sbin/ethtool -K eth0 tso off result is exactly the same.
When I start the script manually from GUI by pressing StartNow button  it is running properly: command /Alt-F/usr/sbin/ethtool -K eth0 tso off is completed after 60 seconds of delay but in the log file there is only the line "Starting /usr/bin/bootscript.sh" - I have to press StopNow button in order to see in the log file the line "Stopping /usr/bin/bootscript.sh"
Question: why /usr/bin/bootscript.sh is not launched at boot time?

[João Cardoso]

Short answer: the user boot script should be stored in the same filesystem where Alt-F disk-installed packages are installed, see the instructions:

2-b) on the "Script to execute on powerup" specify a file name on the same filesystem where Alt-F packages were installed

Long answer: there is no default file name or filesystem for the user boot script, it's completely user/system dependant, each user specifies its name and where it is stored (on which disk and filesystem)

Its pathname is stored in flash memory, and whenever a filesystem is mounted it is checked to see if the user script exists there, and if it is, it is executed.

As this fix depends on the existence of a disk-installed package, ethtool, that can also exists on any filesystem, the script can only be executed correctly after the filesystem where the Alt-F folder resides is discovered.

Alt-F itself is stored in flash memory, not on disk; only "add-ons" (as D-Link calls it) are installed on disk, and each user can have different setups, so the "add-ons" can be at /mnt/sda2, or /mnt/sda3, or /mnt/md0, or /mnt/MyData, etc.

D-Link solves this by creating a small hidden partition on disk, without telling you anything about it, and using it for its own purpose. That's the sda4 or sdb4 partition that users often found when they start using Alt-F.

[Rafal B]

Thank you for pointing me to the correct direction. Its a pity I was a little bind "blind" not seeing important point 2-b)
Now when startup script is called from Alt-F location everything is working like a charm.

[Валерий Головин]

DNS-320 A2. Откатился на 0.1RC4.1

суббота, 9 июля 2016 г., 0:16:28 UTC+3 пользователь João Cardoso написал:

Hi,

There are evidences of network data corruption on RC5.

One such evidence is the empty Status page, but data corruption might occur while reading any file from the NAS.

All models (the DNS-321/323/320/320L/325) but the DNS-327L are affected.

Bill Rosenberg has found the culprit and you should take the necessary measures to avoid data loss/corruption on your box.

You can find and follow Bill's solution here

To apply it automatically, you have to:

1-install the Alt-F 'ethtool' package (Packages->Alt-F, if not yet installed select first the filesystem were to install)
2-create a "user boot script" that runs at boot time and executes the necessary command.

2-a) Go to Services->User, user Configure,

2-b) on the "Script to execute on powerup" specify a file name on the same filesystem where Alt-F packages were installed

  (such as /mnt/sda2/user.sh if Alt-F were installed in sda2, or /mnt/md0/user.sh if Alt-F were installed in md0, or /mnt/sda4... )

2-c) hit the "Edit" button and after the line

echo "Starting $0"

add the line

/Alt-F/usr/sbin/ethtool -K eth0 tso off

[Lordy]

Alt-F is greatly appreciated and breathed new life into my DNS323. In fact I'll make a contribution today.

However I do feel that if a candidate release on a Nas box is causing network corruption , it should be removed. (EDIT: or replaced with fully patched version)

At the very least I think the README should be updated to include a warning. ( https://kent.dl.sourceforge.net/project/alt-f/Releases/0.1RC5/README-0.1RC5.txt )

Its great the issue has been found, that's what RC's are for, but as Alt-F has been RC for over 3 years, and fairly stable in the past, 

I tend to trust it a little too much.

Luckily the corruption was on download , not upload, and only spoiled my streaming experience introducing green blocks on almost everything I watched. I had mistakenly blamed the Raspberry Pi hardware which I also changed around the same time!

I only found this fix by accident , after re-reading the post about fan controller issues.

Having said that, I really do appreciate the many hours of hard work so I'm off to make my contribution ...

Andy

[A K]

Andy, 

I completely agree with you.  Even aside from the corruption issue, this seems to be a major change involving lots of packages, which seems odd for an RC level bump, especially given João's otherwise conservative version history,  I didn't mention this myself only because this seems to be a hacker/enthusiast type of project, and since everyone else seems ok with it, I figured João know's his audience.   But I'm happy that I saw the issue reports before trying RC5, so I'm happily staying on 4.1.

On Tuesday, February 21, 2017 at 9:11:05 AM UTC-5, Lordy wrote:

Alt-F is greatly appreciated and breathed new life into my DNS323. In fact I'll make a contribution today.

However I do feel that if a candidate release on a Nas box is causing network corruption , it should be removed.

At the very least I think the README should be updated to include a warning. ( https://kent.dl.sourceforge.net/project/alt-f/Releases/0.1RC5/README-0.1RC5.txt )

Its great the issue has been found, that's what RC's are for, but as Alt-F has been RC for over 3 years, and fairly stable in the past, 

I tend to trust it a little too much.

Luckily the corruption was on download , not upload, and only spoiled my streaming experience introducing green blocks on almost everything I watched. I had mistakenly blamed the Raspberry Pi hardware which I also changed around the same time!

I only found this fix my accident , after re-reading the post about fan controller issues.

[JK Wilcox]

As "A K" said,

First of all,  I and hope Everybody , we are all eternally and infinitely grateful to João,

But as A K said, that little tiny thing is what still has me using ALT-F v4.1

Now I was thinking of changing the HDDs and I am wishing if there would be some update to version 5 to start with new firmware when changing the HDDs of my dns-323.

Thousands of thanks João. Really appreciate all your hard work.

Greetings JK Wilcox

[João Cardoso]

Thanks for your words

I have flashed and tested RC6 on all my devices, including my home backup box, and everything looks OK. I will download a snapshot of it in a couple of days.

For doing a final RC6 (or 1.0 ? or 2017? or 3.14? or 2.71? or "This is it"?) release I will wait for user's feedback on devices that I don't own.