NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
RBS960 satellite memory creep again
Just started - noticed it early this morning. As it shows, it's been up for over 3 weeks. It will be interesting to see if it stops or if it ends up restarting or losing its connection via backhaul. ...
At 3:00:13 AM EDT approximately, the RBS960 on the first floor restarted after experiencing a memory creep for days. Memory used got to 782MB. I have included a zip file (via a dropbox link) with this summary along with all the supporting files mentioned in this report. Besides the memory creep/restart problem, you'll also read that there were problems getting the RBS to come back up properly connected on backhaul.
After the 3 AM restart, memory was back in a normal range - 340MB, but Hop Count was blank at 6:30 AM when I discovered it.
Also, all devices had disconnected from RBS by morning - smart plugs, and mobile devices.
I did 2 debug captures for 5 minutes, one with LAN-WAN packet capture, and one without. They are in this zip file.
Then I powered the RBS off for 2 minutes - and then powered it on. But the router admin page showed the Backhaul status as good, but not connected to the router (see attached screen shot). Hop Count is also blank after 15 minutes (see screen shot). So I powered the RBS960 down again, waited 2 minutes, and powered it up. This time, it shows the RBS hard wire connected to the third floor RBS, instead of the Router! Hop Count is still blank. The Orbi app shows the same thing. I tried a third time - power cycling the RBS960 - Hop Count is blank and nothing connects to it. So then, I turned off the offending RBS, then powered off the 3rd floor RBS, then powered up the offending RBS. It came up perfectly immediately! So this is another problem I have seen in the past - with 2 RBSs with wired backhaul, it can be very problematic restarting/power cycling one of them.
I then powered up the RBS that was working fine on the 3rd floor - came up fine. Both RBSs now have Hop Count 1, memory is at 341MB for both.
I also included in this zip file a Txt file of the debug page for the RBS960 showing the memory creep over the last several days, scraped every 10 minutes. This shows the memory creep over the last several days.
Dropbox link if anyone is interested:
This 3AM restart, was that on it's own or did you intervene?
Wondering if you should open up another support ticket for this particular issue. 🤔
No, it did it on its own - likely out of memory.
I added this info to my existing support ticket, as my original problem indicated memory creep issues among other problems. I had another support ticket open with similar issues, and they closed that one - I think they wanted this all lumped into one support ticket.
Thank you. Ok, sounds good.
Will be checking in on this as well.
In reviewing Don's debug files post satellite reboot....
Two of the files noted in my research show quite a large growth quickly.
firmware_log.txt had entries showing from 5:07AM - 6:46AM.
This file was 6,200 lines totaling approximately 450K in size (pre-zip - so that is the size within virtual memory).
Of those 6,200 lines, there were a group of approximately 20 lines repeated over and over.
led_event_log had entries with only a few lines with timestamps (this is normal). Total entries were 4,230 lines totally 180K in size (pre-zip). Of those 4,230 lines, approximately 4,000 were the same REPACD : GW IP[192.168.1.1] reachable via eth0 entry.
Just for informational purposes - the d2d /tmp/dal/d2d VSZ was 1548 (compared to 153m from the other satellite). We did not get a total size from the satellite that was > 700MB memory usage because we did not want to risk forcing a restart - we wanted to see when it would do it's own restart).
This shows that there are some other processes other than d2d /tmp/dal/d2d that is doing runaway writing/logging that if not causing memory usage, it is definitely using resources.
