Starting a feature request to spread PiHole to routers.
Many users of powerful routers run modified firmware such as Tomato, MerlinWRT, DD-WRT or OpenWRT. Many of the supported routers have enough processing power available to run piHole and some testing has been done (see here Run PiHole directly on Asus-Merlin/DD-WRT Router - #5 by jonesaaronj). These firmwares use Entware-NG as a packet manager and software can be installed easily via the opkg commands. Self developed installer scripts are available under the link above, yet keeping up with the changes made to PiHole is crazy.
As jonesaaronj stated in his last comment all we need is:
A new installation target with the opt package dependencies needed
A variable to globally control where everything is installed, /etc vs /opt/etc vs /vffs/opt/etc or whatever
The configuration of the bridge which is really just a trivial one liner.
The webinterface can run on a different IP using a virtual interface on bridge0 and lighttp. This avoids confusion with the regular router web interface. The Pi would not be needed in this scenario.
Here are the steps I can think of that need to happen
Most routers don't have access to /etc or /var, usually everything is in /opt/etc and /opt/var. So we would need to update basic-install.sh, pihole, gravity.sh, and all the other scripts to use a variable for the base directory(/etc vs /opt/etc) which gets set in the install script for each distro.
I noticed that the install script uses whiplash. This is the only dependency I see that is not available in entware or optware. So, the install script needs a fallback to use if whiplash isn't there.
Everything above is just house keeping we need done to even get started. But it's a big job.
Once that is done then on to the router specific pieces.
Update basic-install.sh with a new block that checks for okpg(entware) just like it does for apt-get or rpm, and then build up that block with the required opkg commands and dependencies. This is also where we will set /opt/etc and /opt/var.
Add a step to setup the bridge.
/jffs/scripts/services-start
ifconfig br0:1 IP_NOT_IN_DNSMASQ_RANGE netmask 255.255.255.0 up
The dnsmasq config(01-pihole.conf) needs to be installed to /jffs/configs/dnsmasq.conf.add
Create another lighttpd config suitable for the router and install to /opt/etc/lighttpd/conf.d/
Ok, I just noticed that the install script also uses ip. Most optware uses older networking stacks. However, the networking is slightly different since we are just using a static ip in our bridge, so there will be lots of the networking code we won't need to call at all.
There are going to be lots of other little tweaks needed but really we can't get started on those until those first two main hurdles are cleared. Those both really need to be implemented and then tested to confirm no breakage.
I am very willing to work on this project and have the resources and skills to contribute. However I would really like the first two steps to be addressed before committing much energy to the rest.
I have some experience building my own OpenWRT (and working on LEDE) for my WAP's, so I can be of a little assistance in this.
Step 1 wouldn't be all that difficult, it's just a matter of breaking everything out to variables and enforcing that across all the scripts. Once basic-installer is fully sourceable and we have the setupVars locked in to what we'd like then we can have that for user configuration as well.
The whiptail is going to be something more difficult. Since the two install environments are rather opposite of each other, it may be that a fork is needed. I know that I can set up most of my build environment for WRT and handle the configuration either through shell scripting or through the UCI, it may be better to approach the config that way. (Best would be of course an opkg itself, but I'm not that well versed on the packaging requirements.)
It's a good point though, how to handle the install and any user interaction. My experience with the router based installs is that everything is handled via the web interface and there really isn't much to do via the console. A step in the right direction would be to have whiptail (or dialog), but most of what we ask for could be pulled via UCI calls, like the IP configuration and setting interfaces. The bulk of the installer is purely devoted to getting the route to the net and then setting the static IP, both of which should already be done in a router based install. We wouldn't be asking a user to set a static IP address on the router during the installation.
Well, I've only had experience with merlin and dd-wrt, but on both once optware was installed I always just ssh'ed over to the router and did everything on the command line. So, I imagine most users would be installing pihole by doing the same, sshing over and curling the bash script and running it in a terminal.
I agree with your point about the networking. A router only install would skip most/all of that.
I agree, installation should be handled via ssh. AFAIK users of such systems often have enough terminal experience to run an install script.
Just testet the installation of whiptail via pip on merlinwrt. Seems I can use whiptail in python but not in bash, am I missing something here?
About the static IP address: Why would we not want the user to select one?
I think a mayor advantage of the IP being different from the routers webinterface would be that even inexperienced users can edit Pi-Hole settings, without giving them access to the router itsself. So The routers will run two webservers, first the router webinterface (which is hardcoded in C) and the Pi-Hole Webinterface via lighttp.
Then it becomes a question of Pi-hole on DD-WRT or Pi-hole in DD-WRT. Most routers don't have the performance to run multiple webservers, and the complexity of multiple interfaces is going to be above what the inexperienced user would be able to do. It's hard enough to do for experienced users, and then trying to script the install of additional interfaces would be difficult. Just shelled into a C7 running OpenWRT and got ash on busybox. (And running uHTTPd) So to rewrite the entire script in pure busybox is going to be quite the undertaking.
I'm playing around with an Onion Omega 2+ that runs LEDE and it's nice, but would be dreadfully slow unless it was running the FTL interface. I couldn't imagine running PHP on a router...
I have thought about doing just a minimal install type thing with only gravity.sh, the dnsmasq config, and a cron job to update it. No fancy web page or metrics.
Well, I have a range of platforms to test on, the Onion, C7, C5 and an old WNDR3700v2, so target platforms aren't going to be an issue. Diginc, the maintainer of the Docker images has been able to get things running on Alpine, which is busybox, so we know that operationally things are going to be okay, it's just getting to that place and running an installer that doesn't break. We do things with bash that aren't really meant to happen, so it would be interesting to see what an installer on ash and busybox looks like.
I don't know if I would worry much about installing on things like ash or busybox. Most modern routers with optware have bash. I would think for this to happen we would want to deviate as little as possible from the way pihole works right now. Leave it up to the router owner to prepare the router with optware, install bash, know how to ssh into the router, and curl the install script to install.
If a DD-WRT + Pi-Hole build was made specifically for that device it wouldn't be inconceivable that Buffalo would start shipping it with that build. Having a device available with Pi-Hole built in would be the lowest barrier to entry. e.g. the reason why windows is more pervasive than linux is because it comes with most PCs.
I don't know whether this router will be fully capable though.
I agree with @jonesaaronj. A busy box implementation is not needed. Entware-NG provides all the necessary packages and can be easily installed (if not installed by default) on most (if not all) major router firmwares.
Including:
OpenWRT
DD-WRT
Tomato by Shibby
MerlinWRT (fork of the official Asus Firmware)
and many more (for the complete list see: https://github.com/Entware-ng/Entware-ng/wiki)
While a busybox installer seems more general, a entware-ng installer will be much less work, run on many, many different devices and will only require a managable amount of changes in the existing installer script.
With this and the new work being done on FTL I really hope they implement this in such a way that cleanly breaks the project into two parts. The dnsmasq networking stuff, and the web ui.
Then we could easily do partial installs on things like routers, or even PIs (the older ones like I have are rather anemic) that don't have a lot of horsepower, and ship the dnsmasq logs to where the web ui is running. Or leave off the web ui altogether.
Would love to see this and commented on the other thread but will put my two cents in here as well. i see this as being a lot bigger than a feature request imho it would end up be a fork from the main pihole project.
while many routers these days mine included have decent specs i dont honestly know if they would be able to support this in an on board way. further to that from my experience installing third party addons to DD-WRT it took me the better part of a day to get the last one i used running (side note i work with networks and electronics in my day job)
i know for 100% fact it will not be simply plug in external USB storage run command to install. this looks like it is going to cause a lot of headaches both in the install and day to day running of the software
A package for LEDE would really be appreciated.
I don't really need a web-UI, but in case it conflicts with the LEDE UI maybe another port should be selectable.
So as this request seems to interest a lot of people, I was wondering what the next steps are going to be?
Just curious if there are any serious considerations/plans going on right now.
Yes, we are interested, however we still (a) don't know which router would be best to start with (and most likely nobody of us will have one lying around).
I have recently received a Linksys WRT54GL running DD-WRT from a user, but this device might not be suitable for the task (it is quite old and there is no recent version of DD-WRT available for it).
