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.
but seeing the fancy chart is nice :-/
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.
This is a very cool project.
In my request :
I mentioned the Buffalo Airstation N300 as a good target because this device is only shipped with DD-WRT as standard and is widely available.
http://www.buffalotech.com/products/airstation-highpower-n300-open-source-dd-wrt-wireless-router
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.
I don't want to get too far ahead here, but...
I saw this feature request
https://discourse.pi-hole.net/t/request-option-to-send-logs-to-a-remote-logserver
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.
I just realized this is unlikely, since the web ui allows the customization of white/black lists 
You can also do this on the CLI. Actually, you can do anything via CLI and the web UI is really only a frontend.
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
just my two cents
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).
Ah ok. I agree with you, the WRT54GL is not suitable for this kind of task.
I personally use the Asus AC68U, which is around ~130€ on amazon.de at the moment. Maybe if enough others are interested as well, we can chip in together to get you the required hardware. Possibly there is also something more suitable available.
Another possibility to start would be to use a virtual machine to run, for example OpenWRT (https://wiki.openwrt.org/doc/howto/virtualbox). I am not familiar how far this approach would be limited, but for a first look at the firmware it seems feasible. Maybe other Firmwares can also be run in a VM, but I haven't tested this yet.
Oh, did I explicitly stated that "I" (as in me) will be doing it? 
This will be unsuitable. The VM will still run on a x86 base, making it considerably different from what will be run on some real hardware.
What about adding this to pfSense as well? I think having it as an addon that can be bootstrapped to modular router software/firmware would make adoption easier.
I also imagine with pfSense it would be a little simpler to get setup, since that is FreeBSD based (if memory serves).
1 Like
I'd think that the cheapest variation for such an experiment would be a TP-Link router as bunch of their cheapest ones are DD WRT capable.
i have a netgear R700 in use atm and would be willing to allow testing
I don't think there is any code right now that could be tested and the whole process of porting it to some other OS than the officially supported ones is still at the very beginning - maybe not even started.