BBB IoT image with Pi-Hole: Success, but may have to remove connman and nodejs

[neutrinos4all]

I was redirected here from your Twitter account maintainer to post my experience installing pi-hole on a BBB with a freshly-flashed IoT image (version information below). Hopefully this will help someone else in the future.

What I'm using

• element14 BeagleBone Black rev. C, connected via ethernet to router
  
• Asus NT-66R router
• Debian 8.6 ("Jessie") IoT image, retrieved from here.

What happened
After flashing the IoT image to onboard eMMC and installing pi-hole successfully, I had no DNS connectivity: could ping IPs, but not visit websites by URL from any machine on the LAN. What's more, dnsmasq was not running. I determined that connman was binding to port 53 rather than dnsmasq, thereby preventing dnsmasq from resolving DNS requests for pi-hole (confirm using command lsof +M -nPi :53 to see the services bound to that port). Uninstalling connman and restarting the network service allowed dnsmasq to run, fixing the DNS problem. Web browsing was immediately restored across the LAN.

Upon installation, the web interface was inaccessible via browser. Running the same lsof command, but now for port 80, indicated node.js was sitting on it. This is problematic because pi-hole uses lighttpd to serve the content of the web interface--which of course requires port 80. Node.js is installed with this IoT image to facilitate BoneScript, among other things, and because we're using this BBB for a different purpose we don't really need it. Uninstalling and purging nodejs will also uninstall bonescript, as well as some software needed for the Cloud9 IDE (again, not needed if using your BBB for this type of project). Restarting lighttpd immediately restored the web interface.

As a note, remember you can always reboot the BBB if restarting these sevices for some reason doesn't bring them back up.

Additional information
If you would like to see a more detailed walkthrough, please see my blog post here that discusses my method and some reasoning behind it. Feedback would be greatly appreciated, especially if I got anything wrong.

[Robert Nelson]

On Wed, Jan 4, 2017 at 4:52 PM, neutrinos4all <neutri...@gmail.com> wrote:
> I was redirected here from your Twitter account maintainer to post my
> experience installing pi-hole on a BBB with a freshly-flashed IoT image
> (version information below). Hopefully this will help someone else in the
> future.
>
> What I'm using
>
> element14 BeagleBone Black rev. C, connected via ethernet to router
> Asus NT-66R router
> Debian 8.6 ("Jessie") IoT image, retrieved from here.
>
> What happened
> After flashing the IoT image to onboard eMMC and installing pi-hole
> successfully, I had no DNS connectivity: could ping IPs, but not visit
> websites by URL from any machine on the LAN. What's more, dnsmasq was not
> running. I determined that connman was binding to port 53 rather than
> dnsmasq, thereby preventing dnsmasq from resolving DNS requests for pi-hole
> (confirm using command lsof +M -nPi :53 to see the services bound to that
> port). Uninstalling connman and restarting the network service allowed
> dnsmasq to run, fixing the DNS problem. Web browsing was immediately
> restored across the LAN.

Depending what is hooked up wifi/ethernet/etc, we dynamically
enable/disable conman's dnsproxy option:

So instead of purging connman, you do below:

sudo systemctl stop connman.service
sudo sed -i -e 's:connmand -n:connmand -n --nodnsproxy:g'
/lib/systemd/system/connman.service
sudo systemctl daemon-reload
sudo systemctl start connman.service

Then dnsmasq will fire up just fine, and you can still use connman for
managing your connections (connman makes wifi easier)..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[neutrinos4all]

Ah, hmm that's interesting. Thanks for the tip.

By "makes wifi easier," you mean that it makes managing wifi connections easier yeah?

Also, since one of connman's advertised strengths is its light resource use, just wondering: is it a substantial savings over something like network manager?

[Robert Nelson]

On Wed, Jan 4, 2017 at 8:08 PM, neutrinos4all <neutri...@gmail.com> wrote:
> Ah, hmm that's interesting. Thanks for the tip.
>
> By "makes wifi easier," you mean that it makes managing wifi connections
> easier yeah?

Specially from the command line:

sudo connmanctl

#connmanctl> enable wifi
#connmanctl> scan wifi
#connmanctl> services
#connmanctl> agent on
#connmanctl> connect wifi_*_managed_psk
#connmanctl> quit

(no playing with wpa_passphase, etc...)

> Also, since one of connman's advertised strengths is its light resource use,
> just wondering: is it a substantial savings over something like network
> manager?

Well, if nmcli was cut out of the debian network-manager, then connman
vs nmcli would be a wash..

But since network-manager (in debian) brings in a lot of gtk3
dependices, it's not worth it unless you want a gtk3 based desktop.

Since we went for qt (qt's always had a eglfs layer so sgx graphics
could be used), there's a small gui for connman (CMST)

https://github.com/andrew-bibb/cmst/wiki/Screenshots

[neutrinos4all]

That was very helpful / super informative, thanks!