I don't realy want to use the pi hole. Plus the router is good engoh to the job. I know the pi hole is realy good. just means I need to go out buy one and plus more cables. I like my set up to be clean.
Aslo I not sure 3m ethernet cable (POE) - cat6 can take the power of the router and the pi same time. I would plug the pi in the router USB port.
For the time being, I'm going to avoid dealing w/ the second example in that wiki, since it seems overly complex. And you weren't specific about which script you were interested in anyway.
The first script has several flaws.
1. It assumes the WAN is up by the time the script is executed in the startup script, which is normally NOT the case. The startup script is executed long before the WAN is established, and therefore anything that depends on the WAN being available will fail, like using wget to retrieve the URL.
2. It assumes dnsmasq is running. Sometimes it is, sometimes not, by the time the startup script is executed. And if it's not, and the router's execution of dnsmasq gets started *after* you make your changes, those changes will be overwritten!
3. The router should check that wget is available. I know it usually is, but you'd be surprised how many times something you assume to be available, ends up NOT being available. For example, nothing stops the developers from deciding one day to switch to curl rather than the more outdated wget. The developers implement the utilities *they* need, for *their* own reasons, NOT for the sake of script developers.
4. These days, you can't assume that http is available. A lot of sites are switching to https. And while I did verify that at least for the time being, the URL as specific w/ http works, it's still not good practice to make that assumption.
In short, the script, as written, is neither robust nor reliable. And therefore it should be rewritten to avoid confusion by users who expect it to work.
For a quick fix, you could add the following right after the shebang (#!/bin/sh) to actually force the script to wait for the WAN to be up and available.
while ! ping -qc1 -w3 184.108.40.206 > /dev/null 2>&1; do sleep 10; done
Do my router have JFFS Support? I cant seem to get it to work.
Tried this no luck
The steps to enable JFFS through the router web page are very specific. To avoid having to reset and reprogram your router, it's smart to make a backup here of your settings. If you follow these steps exactly, it should not lock up.
On the router web page click on Administration.
Scroll down until you see JFFS2 Support section.
Click Enable JFFS.
Wait couple seconds, then click Apply.
Wait again. Go back to the Enable JFFS section, and enable Clean JFFS.
Do not click "Save". Click Apply instead.
The router formats the available space.
Wait till you get the web-GUI back, then disable "Clean JFFS" again.
Reboot the router,
nvram set jffs_mounted=1
nvram set enable_jffs2=1
nvram set sys_enable_jffs2=1
nvram set clean_jffs2=1
nvram set sys_clean_jffs2=1
Make sure you're using the absolute latest release. I just updated the script. One of the early releases wasn't waiting for the WAN and DNSMasq to come up, so it could fail. I've since corrected that problem and updated the script.
I also added some code to allow serialization, in case a second instance got started at the same time as the current instance (not likely, but remotely possible given the script can be added to the scheduler (cron)). Also, I found some malformed domain names in the list (weird characters, domains w/ port numbers, etc.) and added code to remove them.
If the script is in /jffs/etc/config, it should autostart on every boot. Once the script completes, and assuming the syslog is enabled, you should be able to find the total blacklisted domains w/ the following shell command:
cat /var/log/messages | grep total
Also, look for any errors ...
cat /var/log/messages | grep error
I noticed that sometimes certain urls could not be retrieved reliably. Not clear why that's the case.