What's new

[R7800] RAE, cloudfront ??? Netgear snitch?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I have an idea - looking at the listing on Amazon for this router it says "Amazon Certified: Works with Alexa".
Perhaps this is the daemon that makes this possible. Maybe it's "Amazon Web Services-Internet Of Things"

As an aside - can i also chmod -x streamboost ?
 
I have an idea - looking at the listing on Amazon for this router it says "Amazon Certified: Works with Alexa".
Perhaps this is the daemon that makes this possible. Maybe it's "Amazon Web Services-Internet Of Things"

As an aside - can i also chmod -x streamboost ?
It is definitely "Amazon Web Services-Internet Of Things"
Maybe it is safe, but I don’t like by principle to have something that is collecting data, updating itself from internet (open door for hacks) and maybe communicating with Amazon, without my consent or understanding.
chmod -x and killing the process does not make the router unusable, so apparently not vital.

As for streamboost, I don’t know if it is required for WiFi or just an option. Not something I have been studying.
 
Re: Streamboost
"For StreamBoost to optimally operate, it needs to both send information about your network use and automatically receive updates from its cloud component."

Since the QOS database is way out of date and something I don't use I have wanted to stop this process from running at all.
The r7800s internal cron always resets the update process to run at 4:30 am no matter what you do.
The elegant use of making the script NOT executable is brilliant (thanks @kamoj).
I have marked it non executable and killed the process, will report back if anything goes south.

FYI-description of how Streamboost works. I don't want it collecting and sending 'anonymized' router usage info.
https://www.smallnetbuilder.com/lanwan/lanwan-features/32297-does-qualcomms-streamboost-really-work
 
Thank you for that link.

Nothing wrong with that, except that:
This program of reporting router data back to NETGEAR is voluntary
Is a lie with recent routers, as the web gui option is hidden and the reporting on by default..

It is not honest, and I don’t know why they started to hide that and not give the option to turn it off.
I suspect that they need those reports to identify a problem they have. I am thinking of the bad NAND problem because curiously it seems to affect only the recent models...
The fact they hid that shows they are not clear with that (fear of class action?)

 
Beens days for me (aws), and all is fine.
I also did the same trick to /sbin/traffic_meter
Even with traffic metering off, the bin is running (but not metering of course). Since I don’t use it, I totally disabled it (freeing a little bit of cpu and ram).
FWIW: It's been 10 days since i turned of streamboost buy making the script non-execute and no ill effects noticed.
 
Thanks for the tip about traffic_meter, I have just shut it off as well.

As a second step to the streamboost kill I have also:
chmod -x /usr/sbin/streamboost_status_monit
 
Last edited:
update FWIW:
It is now roughly a month with aws-iot[in /usr/sbin], streamboost[in /etc/init.d], traffic_meter[in /sbin] and streamboost_status_mon[in /usr/sbin] all disabled.
The running processes were killed and the executables were modified with chmod -x to be non-executable even if called.
The R7800 is running with no problems with these killed.
 
Any idea what /sbin/KC_BONJOUR and /sbin/KC_PRINT are doing?
I have multiple instances of those running after a reboot. I kill one of each (with the result of other instances of themselves), and router is working fine even after several days or weeks...
I’m thinking of disabling them as well...
 
Any idea what /sbin/KC_BONJOUR and /sbin/KC_PRINT are doing?
I have multiple instances of those running after a reboot. I kill one of each (with the result of other instances of themselves), and router is working fine even after several days or weeks...
I’m thinking of disabling them as well...
If I were to guess - they support a USB printer attached to the router.
Bonjour/mDNS is the apple discovery protocol for printers.
using strings against KC_BONJOUR basically confirms this as the multicast IP address for mDNS is in there among other confirming strings like 'Hewlett Packard' and 'ioctl printer failed'
Both likely not needed if you are not printing from the router.
I don't use the router for printing so I will disable these as well and report back.
 
I've been following this thread with great interest and now wish to have some clarification of the issue by those whose knowledge is beyond mine.

To summarize: there appears to be four ways to address the Router Analytics Data Collection problem.
This is evident in the the GUI -> Advanced -> Firmware Update page where the problem is that the "I disagree" button can't be checked.

Solution 1
In Kamoj Menus, Settings, Set some functions on/off, check " Block Netgear's 'calling home' to ngxcld domain"


Solution 2
To turn off in telnet:
root@HERMES:~$ nvram set agree_full_TC=0
root@HERMES:~$ nvram set agree_collect_TC=0
root@HERMES:~$ nvram commit

Also: the nvram variable: new_sold_board=1 apparently allows Netgear forces new routers to "phone home"!
You can change it:
nvram unset new_sold_board
nvram commit


Solution 3
Disable the reporting daemon:

chmod -x /usr/sbin/aws-iot
/etc/init.d/aws disable


Solution 4 (i.e., 3+)
chmod -x /usr/sbin/aws-iot
/etc/init.d/aws disable

chmod -x /etc/init.d/streamboost
/etc/init.d/streamboost disable

chmod -x /sbin/traffic_meter
/sbin/traffic_meter disable

chmod -x /usr/sbin/streamboost_status_monit
/usr/sbin/streamboost_status_monit disable


Solution 1 appears to be the simplest way to address the issue, while the others provide more sophisticated and
thorough measures, with Solution 4 adding on some additional measures that disable unnecessary functionality.
The question is what are the advangates and disadvantages (if any) for for moving beyond Solution 1?


LSM
 
It's my experience that only what you call Solution 4 *actually* solves the problem of these 'extra' processes.
That said, I don't know for certain how thorough Kamoj's option is.
Setting NVRAM options only works if the programs which use them respect them or are not upgraded to ignore them.
For me - solving means that the scripts never run, never taking resources from the router.
Granted the chmod -x must be done again with each firmware upgrade, but this is not a deal breaker for me.
The chmod -x itself does not stop any currently running processes, you must kill them or more easily - reboot the router.

Starting with the msg above yours in this thread, I have tested for the last nine days or so the removal of two more processes with great success. If you don't have a printer attached to the router directly then you can also:
chmod -x /sbin/KC_BONJOUR
chmod -x /sbin/KC_PRINT
 
It's my experience that only what you call Solution 4 *actually* solves the problem of these 'extra' processes.
That said, I don't know for certain how thorough Kamoj's option is.
Setting NVRAM options only works if the programs which use them respect them or are not upgraded to ignore them.
For me - solving means that the scripts never run, never taking resources from the router.
Granted the chmod -x must be done again with each firmware upgrade, but this is not a deal breaker for me.
The chmod -x itself does not stop any currently running processes, you must kill them or more easily - reboot the router.

Starting with the msg above yours in this thread, I have tested for the last nine days or so the removal of two more processes with great success. If you don't have a printer attached to the router directly then you can also:
chmod -x /sbin/KC_BONJOUR
chmod -x /sbin/KC_PRINT

To not have to deal with this at each firmware update, I have a script called from /mnt/USB/autorun/scripts/post-mount.sh:
Code:
[ -x /sbin/KC_BONJOUR ] && chmod -x /sbin/KC_BONJOUR
[ -x /sbin/KC_PRINT ] && chmod -x /sbin/KC_PRINT
ps | grep -F '/sbin/KC_' | awk '{print $1}' | xargs kill 2>/dev/null
[ "$(grep -F 'config set new_sold_board=1' /etc/init.d/boot)" ] && { sed -i 's/\/bin\/config set new_sold_board=1/\/bin\/config unset new_sold_board/' /etc/init.d/boot; config unset new_sold_board; }
[ -x /usr/sbin/aws-iot ] && { chmod -x /usr/sbin/aws-iot; /etc/init.d/aws disable; }
[ -x /sbin/traffic-meter ] && { /etc/init.d/traffic-meter stop; chmod -x /sbin/traffic-meter; ps|grep -F '/sbin/traffic-meter'|awk '{print $1}'|xargs kill 2>/dev/null; }
 
Not sure what I'm doing wrong but entering
Code:
chmod -x /usr/sbin/streamboost_status_monit
and then
Code:
root@R7800:~$ /usr/sbin/streamboost_status_monit disable
I get
Code:
-ash: /usr/sbin/streamboost_status_monit: Permission denied
 
With the first command, you make it no no longer executable.
So the second command is not allowed.
I think is no longer needed to disable, if it isn't executable, but if you do want to do it, you should first make it executable again, then disable it, and finally remove the execute permissions.
 
Thanks to NetBytes, HELLO_wORLD, and, especially R. Gerrits!

Your answers have provided an excellent explanation of this issue, including both how to resolve things and what those actions do. This will assist everyone who wishes to carry out these very useful tweaks.

LSM
 
To not have to deal with this at each firmware update, I have a script called from /mnt/USB/autorun/scripts/post-mount.sh:
Code:
[ -x /sbin/KC_BONJOUR ] && chmod -x /sbin/KC_BONJOUR
[ -x /sbin/KC_PRINT ] && chmod -x /sbin/KC_PRINT
ps | grep -F '/sbin/KC_' | awk '{print $1}' | xargs kill 2>/dev/null
[ "$(grep -F 'config set new_sold_board=1' /etc/init.d/boot)" ] && { sed -i 's/\/bin\/config set new_sold_board=1/\/bin\/config unset new_sold_board/' /etc/init.d/boot; config unset new_sold_board; }
[ -x /usr/sbin/aws-iot ] && { chmod -x /usr/sbin/aws-iot; /etc/init.d/aws disable; }
[ -x /sbin/traffic-meter ] && { /etc/init.d/traffic-meter stop; chmod -x /sbin/traffic-meter; ps|grep -F '/sbin/traffic-meter'|awk '{print $1}'|xargs kill 2>/dev/null; }

I also followed your suggestion for adding the code to post-mount.sh
But today I noticed traffic-meter was still running. After some checking, I found out that you have a typo. the correct command to stop traffic-meter would be:
Code:
[ -x /sbin/traffic-meter ] && { /etc/init.d/traffic_meter stop; chmod -x /sbin/traffic-meter; ps|grep -F '/sbin/traffic-meter'|awk '{print $1}'|xargs kill 2>/dev/null; }
(the init script is with an underscore instead of a hyphen)
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top