What's new

Privacy Filter (Another IPSET Script)

  • 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!

@Wolfclaw got no interest in merging with ABS3 got my own blocker if anything ill merge with ublockr :D but for now this is a separate package that plays nice with both blockers, and to clarify got no plans of merging just saying if it ever made sense to merge then it would be with my own blocker.

@Routy the last couple of revisions on this script has been to secure those dnses that are blocked by ublockr or abs 3 to not be included in the privacy-filter cause that would be devastating if we started to block localhost or a localip, so the short answers is

its safe now :)

and yes this blocks the ips not the dns since in win10 telemetry is also hardcoded if dns doesnt resolve it uses ip. So privacy-filter and my other malware-filter provides different blocking methods then ublockr or abs 3

as for subscripions well i run ublock orgin also on my laptop my ublockr takes about 90% of the shirt ads out there but there is still those crafty ones that gets thru and as for adding new lists to ublockr well just read the documentations its all described in there.

as for this thread please keep it to privacy-filter so we dont cross talk on the threads :) hope this clears up everything :D
 
Last edited:
so to clarify for a dummy :) (sorry I am old and slow)
I don't need Entware installed?
copy contents first code window into file called firewall-start
copy second window into file called privacy-filter.list
winscp into router
put firewall-start into /jffs/scripts and set permissions to 0755
put privacy-filter.list into my chosen folder /jffs/configs/privacy-filter and set to 0755
edit path in firewall-start to /jffs/configs/privacy-filter and save.(instead of your opt var thingy that i couldn't find)
and I'm good after a reboot?
 
so to clarify for a dummy :) (sorry I am old and slow)
I don't need Entware installed?
copy contents first code window into file called firewall-start
copy second window into file called privacy-filter.list
winscp into router
put firewall-start into /jffs/scripts and set permissions to 0755
put privacy-filter.list into my chosen folder /jffs/configs/privacy-filter and set to 0755
edit path in firewall-start to /jffs/configs/privacy-filter and save.(instead of your opt var thingy that i couldn't find)
and I'm good after a reboot?
Yup you got it... but you don't need to reboot.... just put /jffs/scripts/firewall-start into the command line and hit return... it will run the script directly. And the path is where the script will read its files (it will create them there if they don't exist... no need to create them yourself) ..... you can just make the path /jffs/configs if you want to dump the list there.

Edit: maybe you want to keep them in one folder by "mkdir /jffs/configs/privacy-filter" at the command line then make the path /jffs/configs/privacy-filter , and dump your privacy-filter.list in there
 
Last edited:
And yes to answer you first question.... missed that :)

You dont need entware installed.
If you have it the telemetry IPs will be resolved by a package called hostip, if you dont have it the IPs will be resolved by doing a traceroute through a filter.
 
next version will have self populating lists if list is missing initially so users dont have to add a list, also thinking of doing everything in tmp if opt is missing.

working on it via my gitlab account.
 
Last edited:
next version will have self populating lists if list is missing initially so users dont have to add a list, also thinking of doing everything in tmp if opt is missing.
Doing things in tmp isn't a bad idea, just leave your privacy-filter.list and the main script in jffs. You dont lose anything because your IP lists are overwritten when the script is run anyway
 
yeah basically the list is useless once its entered into the ipset anyways so its just a matter of wear and tear of the ram thats why i want to keep the option for usb available
 
So this is my proposal for failover

Code:
check_path () {
if [ ! -d "$path" ]; then
     path='/tmp'
     echo "path is not found using $path using as failover"
     check_failover
else check_failover; fi }

check_failover () {
if [ ! -d "$path" ]; then
    echo "failed to set failover path"
    exit 1
else get_source; fi }
 
So this is my proposal for failover

Code:
check_path () {
if [ ! -d "$path" ]; then
     path='/tmp'
     echo "path is not found using $path using as failover"
     check_failover
else check_failover; fi }

check_failover () {
if [ ! -d "$path" ]; then
    echo "failed to set failover path"
    exit 1
else get_source; fi }

How very entware of you ;) it works but only as a one-shot deal. Once path is set as /tmp it will never test for /opt again.
 
if it works it works this will finally relieve me of the age old question "where do i put the list?" not its like meeh put it anywhere and if its not found it sorts out itself :D
 
if it works it works this will finally relieve me of the age old question "where do i put the list?" not its like meeh put it anywhere and if its not found it sorts out itself :D
how about set another variable say chkopt=opt/var/cache/privacy-filter then use, if [ -d $chkopt ] then path=$chkopt else path= /tmp blah blah blah ......
 
yeah thats one way to go about it, just has to be secure way to get it working.

Code:
sh test
path is not found using /tmp using as failover
test: line 18: get_source: not found

but my way does work :) i just tested the snipplet of

Code:
#!/bin/sh

path=/test

check_path () {
if [ ! -d "$path" ]; then
     path='/tmp'
     echo "path is not found using $path using as failover"
     check_failover
else check_failover; fi }

check_failover () {
if [ ! -d "$path" ]; then
    echo "failed to set failover path"
    exit 1
else get_source; fi }

check_path
 
yeah thats one way to go about it, just has to be secure way to get it working.

Code:
sh test
path is not found using /tmp using as failover
test: line 18: get_source: not found

but my way does work :) i just tested the snipplet of

Code:
#!/bin/sh

path=/test

check_path () {
if [ ! -d "$path" ]; then
     path='/tmp'
     echo "path is not found using $path using as failover"
     check_failover
else check_failover; fi }

check_failover () {
if [ ! -d "$path" ]; then
    echo "failed to set failover path"
    exit 1
else get_source; fi }

check_path

Hehe , I'm surprised you even tested it.. but as i mentioned before....now its stuck there. No biggie.

I think if you wanted to code specifically for entware it would be fairly easy to retest for that path and reset it, if available, when the script runs again. That would fit in with the rest of the script that uses hostip if entware if available. coding it for any other path a user might choose would be more difficult.
 
actually its not stuck there cause when the scripts reruns it checks the original path before setting failover :) thats the beauty of it

Code:
# sh test
path is not found using /tmp using as failover
test: line 18: get_source: not found
# sh test
path is not found using /tmp using as failover
test: line 18: get_source: not found
# sh test
path is not found using /tmp using as failover
test: line 18: get_source: not found
 
Last edited:
actually its not stuck there cause when the scripts reruns it checks the original path before setting failover :) thats the beauty of it
You're right of course... I'm so used to seeing paths as variables in scripts i was assuming it changed on the fly.... but path= /tmp is hardcoded of course and won't be altered. Duh.... out thunk meself
 
Revision 9 is up

Changelog
  • source checking
  • failover path
You may want to adjust your wget in case of connectivity issues.... don't know how much hammering it will get
 
yeah can do that in the next revision, doubt that gitlab will get that hammered but if its popular enough then its better to prepare for that right now
 
number 9 works well. got a few bad address may want to delete these or are they just for them to collect data?
thanks

traceroute: bad address 'adnexus.net'
traceroute: bad address 'adnxs.com'
traceroute: bad address 'a-msedge.net'
traceroute: bad address 'cdn.atdmt.com'
traceroute: bad address 'cds26.ams9.msecn.net'
traceroute: bad address 'compatexchange.cloudapp.net'
traceroute: bad address 'i1.services.social.microsoft.com.nsatc.net'
traceroute: bad address 'msftncsi.com'
traceroute: bad address 'oca.telemetry.microsoft.com.nsatc.net'
traceroute: bad address 'pricelist.skype.com'
traceroute: bad address 'telecommand.telemetry.microsoft.com.nsatc.net'
traceroute: bad address 'vortex-bn2.metron.live.com.nsatc.net'
traceroute: bad address 'vortex-cy2.metron.live.com.nsatc.net'
traceroute: bad address 'watson.telemetry.microsoft.com.nsatc.net'
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Staff online

Top