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. ...
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.
Another data item in the memory creep saga - when the RBS originally restarted on its own this week because memory had climbed to 782MB, according to the logs it made 12 DHCP requests - and as reported, it came up with hop count blank. So maybe, hop count issues are related to DHCP issues:
Can't get DHCP info -> keep trying DHCP requests -> hop count stays blank until it gets its DHCP info......
Note the times of all these DHCP requests at the moment the RBS960 was restarting on its own:
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:01:32
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:01:42
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:01:52
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:03:19
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:03:29
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:03:35
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:03:47
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:05:08
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:05:56
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:06:26
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:06:41
[DHCP IP: (192.168.1.148)] to MAC address XX:XX:XX:XX:XX:XX, Wednesday, Jun 05,2024 03:06:56
