Re: Final 6.2.1 update causing LAN instability/sluggishness

vandermerwe · ‎2014-12-21

Ah yes, you can't access the GUI ( web interface).
Have you cleared your browser cache and tried a different browser?
Have you done an OS reinstall?
Do you have a backup?

You can install firmware using ssh or remote access but I'm still not confident enough to do that. There is someone on the forums who may be able to help you later.

nsne · ‎2014-12-21

@SimonCraddock and pinky2000: Inability to access the ReadyNAS web UI would seem to be a separate issue and belongs in a separate thread. In my experience, that can usually be solved by a simple reboot.

Another user, dsnpevl, has experienced the LAN stability issue on which this thread is focused. He has created a separate thread for his problem: viewtopic.php?f=65&t=79133

pinky2000 · ‎2014-12-21

Unfortunately a simple reboot doesn't fix the problem. We'll see with time if it's related to v6.2.1 or not. Really don't know how I can sort it out in themeantime...

dsnpevl · ‎2014-12-21

Having this issue too. Router hangs as soon as I connect RN516. After disconnecting, after a while the router comes back and all connections are restored. See: https://www.readynas.com/forum/viewtopi ... 65&t=79133.

The router gets a "Timeout during PPP negotiation" and "PPPoE error: Timeout" almost immediately as I connect the RN516.

21.12.14   17:23:04   PPPoE error: Timeout.
21.12.14   17:22:50   PPPoE error: Timeout.
21.12.14   17:22:36   PPPoE error: Timeout.                                                                          <- Disconnected.
21.12.14   17:22:22   PPPoE error: Timeout.                                                                         
21.12.14   17:22:08   PPPoE error: Timeout.
21.12.14   17:21:54   PPPoE error: Timeout.
21.12.14   17:21:40   PPPoE error: Timeout.
21.12.14   17:21:27   Timeout during PPP negotiation.                                                                <- Network connection lost.
21.12.14   17:21:26   Internet connection cleared.
21.12.14   17:21:26   IPv6 Internet connection was cleared; prefix no longer valid.                                  <- Conntected RN516 here.
21.12.14   17:18:23   Login to the FRITZ!Box user interface from the IP address 2003:973:1c64:1:cc7c:f730:fd77:a645.
21.12.14   17:15:19   No wireless LAN device registered any more: Reducing power consumption.
21.12.14   17:12:19   Wireless LAN transmission quality increased by reduced channel bandwidth.

dsnpevl · ‎2014-12-21

Did a OS reinstall of the OS 6.2.1 (final) and this seems to have fixed the issue for me. At least no more hangs in the router and the connection to Internet stays open for my PC and Wifi devices. And most importantly my website is back online. Because of the re-install, the bond that I had set on the two network cards is now gone and I connect through one NIC only now (eth0) again. So for me the root cause was a mismatch of network settings in the RN516 and the router. After the OS reinstall these were set back to default, I think. Espescially the bond between the two NICS I had, seems to throw a curveball. Still the RN516 should never disable a router to provide connections. It should just not have been reachable, if the IP addresses are incorrect.

Will run like this for a while, with only one NIC attached to the router. Will look some more into this after the holidays. Already spend 2 days on this issue, so I'm done for now. Happy holidays!

The OS reinstall for the RN516 is described on pages 55 and 56 of the ReadyNAS OS 6 Desktop Storage Systems Hardware Manual manual (April 2013, 202-11206-03). For other model look in the index and find your model and the "Boot menu". I used the option "OS reinstall". (Be careful not to select the previous item "Factory default", because that will erase all your data. Read the caution notion in the manual!).

pinky2000 · ‎2014-12-21

Didn't make it for me and still cannot access the web-GUI! I have dropped an email to the support. We'll see...

dsnpevl · ‎2014-12-21

Hmm, seems I'm not done yet either 😞

Moved the RN516 temporarily, so I could check the messages on the display. After the OS re-install it worked. But after shutdown and moving it back near the router, on restart, the same issue starts occuring. Looks like I am going to have to revert to the RC3 also, if I want to permantely fix this.

_frantic_ · ‎2014-12-21

I downgraded my RN312 from the "final Final" to 6.2.1 RC3.
This fixed the problem.

The RC3 release comes with ConnMan 1.25.
The final Final 6.2.1 came with ConnMan 1.27.

ConnMan 1.27 was released Saturday, December 13th, 2014.
With this version, the ConnMan daemon (connmand) on my RN312 took about 99.5 % CPU and it sent out a huge number of TX packets over eth0.

Wild guess: connmand 1.27 floods routers with tons of faulty traffic.
Perhaps it has not been tested adequate on the final Final 6.2.1.

vandermerwe · ‎2014-12-21

Not sure if this is related, seems similar:
viewtopic.php?f=64&t=77397

pinky2000 · ‎2014-12-21

Is it possible to downgrade the firmwware without accessing the GUI and without loosing data?

vandermerwe · ‎2014-12-21

Using ssh or remotely.
Perhaps contact support, especially if you are within 90 days of purchase.

nsne · ‎2014-12-21

_frantic_ wrote:
The RC3 release comes with ConnMan 1.25.
The final Final 6.2.1 came with ConnMan 1.27.

If reverting to RC3 has solved the issue for those of us with this issue, this ConnMan discrepancy would seem to be at the root of the problem. Maybe it doesn't play well with IPv6? Or a certain router chipset?

Hope the OS 6 devs are paying attention.

dsnpevl · ‎2014-12-21

Yes, _frantic_'s "wild guess" seems very plausible 🙂 And it would explain the symptoms I see.

I put a continuous ping on the router from my PC. With the RN connected, it cannot reach the router. As soon as you disconnect the RN, the router connection comes back.

But how do you downgrade to RC3?

I don't have a working connection to RN516 because as soon as it is connected to the router all connections disappear. So I cannot reach the admin interface, nor reach it over SSH. Any suggestions?

_frantic_ · ‎2014-12-21

@dsnpevl: I have connected both ReadyNAS and PC to a switch. The router is connected to the same switch. In this constellation, PC and ReadyNAS can talk to each other even when the router goes down.

Sent from my iPad using Tapatalk HD

dsnpevl · ‎2014-12-21

OK, seems you must definitely disable all portforwarding as well. Then I managed to re-install the OS and have the web admin and SSH connection back.
One other weird thing I noticed, is while I only connected on LAN1, the NIC for LAN2 also show up in the router. This seems to be related to an an observation made here:

mountaindude wrote:
After restarting connamn (or the entire NAS) I have THREE IPs responding to pings: 192.168.1.16, 192.168.17 and 192.168.106
What??

Anyway, I can now try some stuff to get it to work. Logged into SSH and followed this procedure to check for connman packages (command line version).

root@nas-XX-XX-XX:~# apt-cache showpkg connman
Package: connman
Versions:
1.27-netgear1 (/var/lib/apt/lists/apt.readynas.com_packages_readynasos_dists_6.2.1_main_binary-amd64_Packages) (/var/lib/dpkg/status)
 Description Language:
                 File: /var/lib/apt/lists/apt.readynas.com_packages_readynasos_dists_6.2.1_updates_binary-amd64_Packages
                  MD5: cb5a9cf686ae7cfd884a7a436fa64503

1.26-netgear1 (/var/lib/apt/lists/apt.readynas.com_packages_readynasos_dists_6.2.1_updates_binary-amd64_Packages)
 Description Language:
                 File: /var/lib/apt/lists/apt.readynas.com_packages_readynasos_dists_6.2.1_updates_binary-amd64_Packages
                  MD5: cb5a9cf686ae7cfd884a7a436fa64503

1.0-1.1+wheezy1+b1 (/var/lib/apt/lists/mirrors.kernel.org_debian_dists_wheezy_main_binary-amd64_Packages)
 Description Language:
                 File: /var/lib/apt/lists/apt.readynas.com_packages_readynasos_dists_6.2.1_updates_binary-amd64_Packages
                  MD5: cb5a9cf686ae7cfd884a7a436fa64503


Reverse Depends:
  connman-dbg,connman 1.27-netgear1
  connman-dbg,connman 1.26-netgear1
Dependencies:
1.27-netgear1 - iptables (0 (null)) libc6 (2 2.15) libdbus-1-3 (2 1.1.1) libglib2.0-0 (2 2.31.8) libreadline6 (2 6.0) libxtables7 (0 (null)) dbus (0 (null)) lsb-base (0 (null)) bluez (0 (null)) wpasupplicant (0 (null))
1.26-netgear1 - iptables (0 (null)) libc6 (2 2.15) libdbus-1-3 (2 1.1.1) libglib2.0-0 (2 2.31.8) libreadline6 (2 6.0) libxtables7 (0 (null)) dbus (0 (null)) lsb-base (0 (null)) bluez (0 (null)) wpasupplicant (0 (null))
1.0-1.1+wheezy1+b1 - iptables (0 (null)) libc6 (2 2.9) libdbus-1-3 (2 1.1.1) libglib2.0-0 (2 2.28.0) libgnutls26 (2 2.12.17-0) libxtables7 (0 (null)) dbus (0 (null)) lsb-base (0 (null)) bluez (0 (null)) wpasupplicant (0 (null))
Provides:
1.27-netgear1 -
1.26-netgear1 -
1.0-1.1+wheezy1+b1 -
Reverse Provides:

So this means I can try to downgrade to the 1.26-netgear1 version, hoping it doesn't have the flaw of the 1.27.

root@nas-XX-XX-XX:~# sudo apt-get install connman=1.26-netgear1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Recommended packages:
  bluez wpasupplicant
The following packages will be DOWNGRADED:
  connman
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 51 not upgraded.
Need to get 383 kB of archives.
After this operation, 4,096 B disk space will be freed.
Do you want to continue? [Y/n] Y
Get:1 http://apt.readynas.com/packages/readynasos/ 6.2.1/updates connman amd64 1.26-netgear1 [383 kB]
Fetched 383 kB in 1s (251 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
dpkg: warning: downgrading connman from 1.27-netgear1 to 1.26-netgear1
(Reading database ... 32568 files and directories currently installed.)
Preparing to replace connman 1.27-netgear1 (using .../connman_1.26-netgear1_amd64.deb) ...
Unpacking replacement connman ...
Setting up connman (1.26-netgear1) ...
insserv: warning: current stop runlevel(s) (empty) of script `connman' overrides LSB defaults (0 1 6).
insserv: can not symlink(../init.d/nut-server, ../rc2.d/S03nut-server): File exists
insserv: can not symlink(../init.d/forked-daapd, ../rc2.d/S05forked-daapd): File exists
insserv: can not symlink(../init.d/avahi-daemon, ../rc2.d/S04avahi-daemon): File exists
insserv: can not symlink(../init.d/dbus, ../rc2.d/S03dbus): File exists
insserv: can not symlink(../init.d/apache2, ../rc2.d/S02apache2): File exists
insserv: can not symlink(../init.d/lsyncd, ../rc2.d/S01lsyncd): File exists
insserv: can not symlink(../init.d/mdadm, ../rc2.d/S03mdadm): File exists
insserv: can not symlink(../init.d/connman, ../rc2.d/S04connman): File exists
insserv: can not symlink(../init.d/rsync, ../rc2.d/S03rsync): File exists
insserv: can not symlink(../init.d/cron, ../rc2.d/S03cron): File exists
insserv: can not symlink(../init.d/nut-server, ../rc3.d/S03nut-server): File exists
insserv: can not symlink(../init.d/forked-daapd, ../rc3.d/S05forked-daapd): File exists
insserv: can not symlink(../init.d/avahi-daemon, ../rc3.d/S04avahi-daemon): File exists
insserv: can not symlink(../init.d/dbus, ../rc3.d/S03dbus): File exists
insserv: can not symlink(../init.d/apache2, ../rc3.d/S02apache2): File exists
insserv: can not symlink(../init.d/lsyncd, ../rc3.d/S01lsyncd): File exists
insserv: can not symlink(../init.d/mdadm, ../rc3.d/S03mdadm): File exists
insserv: can not symlink(../init.d/connman, ../rc3.d/S04connman): File exists
insserv: can not symlink(../init.d/rsync, ../rc3.d/S03rsync): File exists
insserv: can not symlink(../init.d/cron, ../rc3.d/S03cron): File exists
insserv: can not symlink(../init.d/nut-server, ../rc4.d/S03nut-server): File exists
insserv: can not symlink(../init.d/forked-daapd, ../rc4.d/S05forked-daapd): File exists
insserv: can not symlink(../init.d/avahi-daemon, ../rc4.d/S04avahi-daemon): File exists
insserv: can not symlink(../init.d/dbus, ../rc4.d/S03dbus): File exists
insserv: can not symlink(../init.d/apache2, ../rc4.d/S02apache2): File exists
insserv: can not symlink(../init.d/lsyncd, ../rc4.d/S01lsyncd): File exists
insserv: can not symlink(../init.d/mdadm, ../rc4.d/S03mdadm): File exists
insserv: can not symlink(../init.d/connman, ../rc4.d/S04connman): File exists
insserv: can not symlink(../init.d/rsync, ../rc4.d/S03rsync): File exists
insserv: can not symlink(../init.d/cron, ../rc4.d/S03cron): File exists
insserv: can not symlink(../init.d/nut-server, ../rc5.d/S03nut-server): File exists
insserv: can not symlink(../init.d/forked-daapd, ../rc5.d/S05forked-daapd): File exists
insserv: can not symlink(../init.d/avahi-daemon, ../rc5.d/S04avahi-daemon): File exists
insserv: can not symlink(../init.d/dbus, ../rc5.d/S03dbus): File exists
insserv: can not symlink(../init.d/apache2, ../rc5.d/S02apache2): File exists
insserv: can not symlink(../init.d/lsyncd, ../rc5.d/S01lsyncd): File exists
insserv: can not symlink(../init.d/mdadm, ../rc5.d/S03mdadm): File exists
insserv: can not symlink(../init.d/connman, ../rc5.d/S04connman): File exists
insserv: can not symlink(../init.d/rsync, ../rc5.d/S03rsync): File exists
insserv: can not symlink(../init.d/cron, ../rc5.d/S03cron): File exists
[ ok ] Restarting connman (via systemctl): connman.service.

So now the big question: will it still work after restart. Since I have connection still, I used the web admin to restart. Will let you know how this goes.

dsnpevl · ‎2014-12-21

_frantic_ wrote:
@dsnpevl: I have connected both ReadyNAS and PC to a switch. The router is connected to the same switch. In this constellation, PC and ReadyNAS can talk to each other even when the router goes down.

Yes, tried that too, but for me when the RN516 is on, no matter where in the LAN, it disables the router anyway. Then the IP addresses no longer get resolved and I cannot access anything from my PC. I now have the PC on the switch and the switch on the router. The RN is directly on another port of the router.

Trying downgrading to 1.26 now.
Update1: first signs are promissing for the downgrade to connman 1.26 on final OS 6.1.2. Will try some shutdown/restart next to see if it keeps working. Also: the weird second listing of the LAN2 NIC in the router has disappeared now.
Update2: After shutdown and power-off and power-on, the connection still works. Will try restart from web admin next.
Update3: Takes a very long time to reboot. The web admin is telling me: "Connection lost. Connection could not be restored. Please reboot your device manually and try again". But actually, the RN was still rebooting (it says "booting..." in the front display). When you wait long enough, the connection comes back and no router issues. The web gui needs to learn to have a little patience...
Update4: Actually remebered the issues with the port forwarding, so I powered down the RN (again) and re-instated my port forwardings on the router. After restart the network stays alive and I can access from the web admin. Next I will shut down/power down and move the RN back to it's opertional posistion. If that works, the fix above has been proven sound, from my perspective.
Update5: I moved the RN back near the switch and restarted it. Connections are still working and my website fotografeer.nl is up-and-running again, finally. I consider the fix decribed above a success. Thanks to all for starting threads on this issue. And many thanks to _frantic_ for finding the root cause. Netgear should be forever in our debt for doing their work for them 🙂

So this fix works for me:
- Look for the installed versions of connman:

apt-cache showpkg connman

- Provided 1.26-netgear1 is listed, you can then downgrade from 1.27-netgear1 to 1.26-netgear1

sudo apt-get install connman=1.26-netgear1

- Details and full screen output above.

Enjoy your holidays and have a happy new year with many trouble-free OS updates!

nsne · ‎2014-12-21

Thanks to _frantic_ and dsnpvl for finding the cause and a solution.

Since I'd rather not have to mess with the terminal to have a functional, up-to-date ReadyNAS, I'd appreciate it if Netgear or the OS 6 developers could release a 6.2.1.1 or 6.2.2 update that corrects this issue.

dsnpevl wrote:
Netgear should be forever in our debt for doing their work for them 🙂

You say this in jest, but there's a certain amount of truth to it. If this had been implemented in the beta, we could have caught it before it went to final. Instead they made untested, fundamental changes between RC3 and GM, and we — or I should say you — got to spend hours on troubleshooting.

scravatt · ‎2014-12-21

I have 2 RN314s in 2 different houses. 1 Upgraded to 6.2.1 fine...no issues, rebooted several times..no problems at all. The other one is not so good. Updated 6.2.1 remotely fine, but it takes down my router and I can't access anything form any device on my network. Had a friend go to my house reboot my modem/router...locks up after a while. Had him reboot the RN314, came up fine but locked the router up.. unplugging it from the network fixes the problem; real disappointed in NETGEAR for this crappy release. I can't get to the house to fix it for a few weeks and hope I can access the UI to install the 6.2.1 RC3 or 6.2.0 versions....fingers crossed. I just don't have days to rebuild the whole thing...ugh!

Lesson learned...don't update firmware just because it says it's released...wait a few weeks and read the forums to see if people are having issues.

Hoping there will be an easy fix for everyone affected.

Teufl_at_Readyn · ‎2014-12-22

Same Problem with me. As soon as I connect my Readynas to the network the router can't be accesses properly. Furthermore, the internet connection breaks down. As soon as I disconnect the network cable from the NAS the router-interface reacts normal and internet gets reconnected.

If I connect to the NAS, the network-interface isn't shown either.

My NAS has a static IP and some Apps installed, where Owncloud, PHPmyadmin, and VPN-softether come to mind right now.

Update: Just read the propable solution to the problem. One question there, since I have no internet conection while my readynas is online, I can't downgrade, can I? May old packages still be stored?

Otherwise I will just have to downgrade and wait for a "proper" update...

mdgm-ntgr · ‎2014-12-22

Well you could downgrade to 6.2.0 or 6.2.1-RC3, but you would lose other changes since then.

dsnpevl · ‎2014-12-22

scravatt wrote:
Lesson learned...don't update firmware just because it says it's released...wait a few weeks and read the forums to see if people are having issues.

My thoughts exactly. Didn't have too many issues with upgrades before, since I bought the RN back in 2013, so we must give Netgear some credit. I was getting used to blindly accepting an update, as soon as it came out. But after this experience I will start following a policy that served me well over the years: "If it ain't broken, don't fix it". For me, Netgear needs to rewin my trust in the quality of the OS upgrades first. And judging by comments in this and other threads, I'm not alone in this. But then, if no one upgrades, how are we going to find the issues....?

The models RN 312 and higher are marketed as a "Business Desktop Series". Although I'm using a RN516 for "just" a hobby project (gone wild), I get very frustrated when my website on the RN goes down for the outside world. A lot of time and money has been spend to get the system to do what I want and creating the content. The web-site name is approached as somewhat of a brand-name. Any down-time leaves a bad impression to the outside world. If used in a business critical situation (with or without a website), you really cannot afford days of down-time. You would need (near to) 24/7 availablity.

Most of the time went into talking on this fourm, problem analysis, fixing and testing. Initially I even assumed the problem was with my router, as I had one break before. So a lot of time was spent with the ISP helpdesk, resulting in a new router being sent. In this case, the ISP had no part in the problem and the router was not at fault. I went as far as borrowing a same make and model router from a friend to verify if the problem was with the router. After several tests, we found the other router presented exactly the same issues, so that was ruled out as the root cause and made me turn my attention to the RN. The router also handles fixed telephony. So during two days I was not reachable on the fixed line. Not to pleased with that either.

scravatt wrote:
Hoping there will be an easy fix for everyone affected.

Yes, I my view, Netgear now needs to provide a fix for this ASAP. Similar comments have already been made in this thread. You can't have an ReadyNAS OS that freezes up routers and switches by flooding a network with packets (suspected root cause).

Guess it all depends on what you call an "easy fix". If you are not afraid to work on the command line via SSH (and risking voiding the warranty), it's just two commands and only takes 5 minutes and the problems are solved (at least for me they were on a stand-alone RN516). But, in good Netgear tradition, I make no guarantees nor warranties of any kind if you use the SSH command line. The risk is all yours 🙂

Having said that, this fix works for me:

- Look for the installed versions of connman:

apt-cache showpkg connman

- Provided 1.26-netgear1 is listed, you can then downgrade from 1.27-netgear1 to 1.26-netgear1

sudo apt-get install connman=1.26-netgear1

- Details and full screen output above.

MarcusF · ‎2014-12-22

First thanks to community for helping each other. Netgear are here too 🙂

We do want to track down what is causing. It does not seem to be a wide spread issue with 6.2.1 and command 1.27 (many are running it without issue), There is something specific to the users in this thread that we want to track down

From a related thread I seen
--Re: Release notes for 6.2.1
--Post by nsne » Sat Dec 20, 2014 1:45 pm
--As for apps in common, it looks like _frantic_ and I both have Logitech/UE Media Server installed.

Another common item I think I see is updating from RC3 to final.

@dsnpevl would you also use Logitech/UE media server?

dsnpevl · ‎2014-12-22

OptimusPrime wrote:
It does not seem to be a wide spread issue with 6.2.1 and command 1.27 (many are running it without issue)

Good to see Netgear involved! Just talked to a friend who has RN312 who upgraded to 6.2.1 final without any issues. That confirms your statement.

OptimusPrime wrote:
There is something specific to the users in this thread that we want to track down.

I suggest you first look to the differences between the connman packages 1.27-netgear1 and 1.26-netgear1. 1.27 doesn't work for me. 1.26 does. I believe that to be a better approach to come to the deeper underlying issue. Otherwise, we are just shooting in the dark for the root cause. The ball is your corner now.

OptimusPrime wrote:
@dsnpevl would you also use Logitech/UE media server?

No, don't have Logitech/UE media Server (using Plex).

I would look in the direction of IP problems. During research the ISP helpdesk made me set the router to factory settings. That cleared all the fixed IPs I had configured and at next reboot the RN got a different IP from DHCP. Seems to me, from that point on the BOND on eth0 and eth1 on RN didn't play well with the newly assigned IP address. The RN kept complaining about "Cannot connect discovery server" on the front display. Not sure what the discovery server is or why RN should contact it. But it might kick off the problem. Read in some other thread that the connman config got messed up, but not sure if that is related.

Common things I would look for first, based on the testing sofar:
- Is there a BOND set between eth0 and eth1 on RN?
- Is the router configured to always assign same IP to RN?
- Is NAT and/or port forwarding applied on the router towards RN?

Don't think that the installed apps are at the hart of the problem, but to rule things out, these are my installed apps.

_frantic_ · ‎2014-12-22

OptimusPrime wrote:
Another common item I think I see is updating from RC3 to final.

no, my RN312 was not on the beta. I updated from 6.2.0 to 6.2.1 (then down to 6.2.1 RC3).

One thing which might be in common is the usage of IPv4 and IPv6 in parallel.

dsnpevl · ‎2014-12-22

No, only upgraded from 6.2.0 (final) to 6.2.1 (final).