Minimal Pi i2pd Install by Pinroot

Take it away Pinroot!

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits. Bookmark the permalink.

19 Responses to Minimal Pi i2pd Install by Pinroot

  1. E.M.Smith says:

    While waiting for Pinroot to put up a comment with his “what I learned doing i2pd on a minimal sized Pi”, I’m going to put a link and pointer here to fixing another “problem”.

    Thanks to Pottering and others being unable to do simple systems administration tasks, like edit the /etc/resolve.conf file, You know like telling it what your nameserver is by typing “nameserver n.n.n.n” like:

    ems@XU4uDevuan3:~$ cat /etc/resolv.conf

    ’cause, you know, that’s just soooo hard…

    So “they” have layered all sorts of Auto-Magic Things From Admin Hell on top of each other to “fix” what wasn’t broken. As a result, you can edit /etc/resolv.conf, but it will be inexplicably overwritten by God Only Knows what (and God, despite my technical requests / tickets, has not talked to me personally about it…).

    But I’m not the only one having such issues.

    Well, since many of those thing run as “root” you can’t even use typical permissions things to stop the overwriting. But there is a way. Something I knew about 40 years ago, but never used, and needed a reminder… The IMMUTABLE attribute:


    For anyone looking at this post in the future with a similar problem, the solution that I ended up using was to change the dns settings to the servers that I wanted, then write-protect the resolv.conf file with

    chattr +i /etc/resolv.conf

    as root.

    Also, if you want to un-write-protect it, you can run

    chattr -i /etc/resolv.conf

    again, as root, otherwise, it won’t work

    Worked a champ. I now have a normal old /etc/resolv.conf file that listens to me ;-) and only me.

    I, too, had this issues of not having “Network Manager” installed, so no telling what I was fighting with:

    Use your favorite text editor to open /etc/NetworkManager/NetworkManager.conf as a root user.

    Add the line dns=none in the [main] section.

    Either reboot your system or restart NetworkManager.

    NM should no longer overwrite your resolv.conf!

    (This stops NM from forcing its own DNS settings, so your settings specified in resolv.conf will be used.)


    Unfortunately, I don’t have networkmanager on my system

    I have a very nice advert blocking DNS server inside my perimeter that doesn’t tattle to the Telephone Company about what sites I do a DNS lookup for, nor really leak much of anything to them. (Telcos are all essentially spys for the government on demand and have been for decades, though lately they have begun selling information too, along with having poor slow DNS lookups…)

    So I’m now once again free to do whatever DNS lookups I want using my own DNS servers and without that whole ‘tacking, recording, selling, spying’ “Feature” of Telco DNS…

  2. Taz says:

    Have never found a perfect solution to the DNS problem, but using a router forcing DNS over TLS, and 24/7 VPN proxies (privoxy), along with a handful of OpenWRT minirouters can go a long way.

    Those minirouters can absolutely confine DNS lookups to specific servers and they are very cheap.

    All that double NAT horseshit is just scary talk…..

    You should have your wifi completely isolated anyway. IEEE has NEVER been able to release a good wifi standard. Their continued failures should give everyone pause.

  3. E.M.Smith says:

    I’ve not (yet) gotten to the encrypted DNS link. On my “someday” list. I do point my (Pi M2) DNS server (behind a NAT router) at a few fairly trusted DNS servers. (Not Google nor Cloudflare… and definitely not my Telco). Then as it is cached with a long cache time, it’s basically “one and done” for a few days… I don’t really care if some DNS server on the other side of the planet knows that I did ONE lookup of or whatever.

    But still, yes, someone really “spying on the wire” will see a DNS Lookup to far far away go by and could inspect the packet.

    So at some point I want to do the encrypted DNS lookup conversion on the little guy. (For now I’m still fighting all the folks trying to force DNS to NOT go to my router but go off to their information laundry… Telco DHCP, Browsers with built in DNS, Linux “automagical tools”, etc.

    Then also on my someday list is to discover if someone is doing DNS over i2p, then I can point my little i2p router at the i2p DNS server via i2p, and then provide the lookups to the “clear” side inside my network. Hopefully a fully encrypted and anon DNS lookup… but we’ll see.

    I forget just what it was now, but I had one software product complain that my Machine-ID was zero length. ( I tend to nuke it…). Had to replace it with 32 zeros to make that thing happy… So now my “nuke Machine-ID” is ‘echo “00000000000000000000000000000000” > /etc/machine-id’

    ems@XU4uDevuan3:~$ ls -l /etc/machine-id 
    -rw-r--r-- 1 root root 33 Apr  4 05:02 /etc/machine-id
    ems@XU4uDevuan3:~$ cat /etc/machine-id 

    So much spying, so little time…

    Since my TV/Guest Network uses the Telco DNS for all the crap stuffed into the TV internet feeds, I figure that will load up so much crap in any wire snoops as to make them bored fast. ;-)

    It probably is time for me to do the encrypted DNS link over VPN though… if for no other reason that to get skill at it.

  4. E.M.Smith says:

    Oh, and per WiFi:

    I have 4 WiFi networks running. One of them isolates to “only the internet” for TV & Guests, and one is “my lab only” where almost all the time equipment is off. In all cases the power was turned down to where it just barely works from the other end of the house. The only one that’s really an issue is the House Net, and that goes to sleep at night… I also have the router configured to limit who can connect and a few more things ;-)

    With a really good antenna you can whack on it, but I know my neighbors… I also gave the networks names like mafia-central and undercover-cop just to make it fun ;-o

    So essentially, IF they are a good hacker (neighbors are not) AND get a high end antenna designed for long range, AND are not scared off by funny names AND have the time and inclination AND run the needed software (air snort, etc.) to inspect packets and find MAC addresses AND know how to set a MAC address AND work during specific hours… then they might get in… And discover I’m posting an article citing an India Times link as I’m damn boring ;-)

    Work sites, that’s another matter… I’d not want to be head of security at a major corp these days. Way too much vulnerable wifi running around. I’m presently specifying and soon setting up a WifI / Router / IDS / Security Appliance. Cost to make it reasonably secure? About $3000. (about half each hardware / software).

    Will be doing similar basic things like login limited to specific MAC address / machine names / login credentials / etc/ but along with full IPS / IDS auto reporting gear. Any attempts that fail sound an alarm for immediate action / inspection of threat. Then it becomes hacker vs hacker…

    Can’t really justify that level for home. Someone wants to hack my LG TV, I’m not going to lose sleep over it (we use the Roku plugged into it anyway and not the ‘smarts’ in the TV) or if they want to discover my lab gear is all shut off except for a few hours once a week when I’m watching like a hawk my router connected table… well, that might be fun ;-)

    Oh, and I’ve periodically audited the connection logs in the 2 routers. Nothing. Near as I can tell, nobody even trying. There’s also a lot softer targets in the neighborhood…

  5. E.M.Smith says:

    Hey, it doesn’t look all that hard at all, and it is already in PiHole:

    But this part’s not so good s he had issues using a Pi M1 B+ which is what one of my servers is…

    … and voila! The upstream DNS requests sent from your Pi-hole will be encrypted using TLS.

    As mentioned earlier, DNS-over-TLS is not a perfect solution to your privacy concerns. No matter how you protect your DNS traffic, the name of the websites that you visit will still be visible in the SNI of your HTTPS traffic, allowing your ISP (and any other intermediary) to view it. DoT somewhat protects integrity by preventing intermediaries from manipulating your DNS requests or their responses. However, you are still trusting the upstream DNS server- in our case, Quad9 and Cloudflare- to provide the correct responses.

    Another option to secure DNS traffic is DNS-over-HTTPS. I chose DoT because the cloudflared program would not work on my Raspberry Pi 1 Model B+.
    DoH has the advantage of being harder to block or detect, because the DNS traffic is encapsulated inside of HTTPS traffic destined for port 443. This is also a slight disadvantage due to the additional traffic overhead of the HTTPS headers, which makes DoH somewhat slower than DoT.

    OTOH I’m not using Cloudflare, so maybe it doesn’t matter…

    I think I’ll try to make one of them go later this week…

  6. E.M.Smith says:

    I’m definitely going to do that PiHole DNS hack. Essentially it consists of installing the “unbound” DNS server and pointing PiHole (and all the PiHole features…) at it as the next upstream DNS server.

    Unbound is a validating, recursive, and caching DNS resolver product from NLnet Labs. It is distributed free of charge in open-source form under the BSD license.

    Caching resolver with prefetching of popular items before they expire
    DNS over TLS forwarding and server, with domain-validation
    DNS over HTTPS

    Query Name Minimization
    Aggressive Use of DNSSEC-Validated Cache
    Authority zones, for a local copy of the root zone

    DNSSEC validating

    EDNS Client Subnet
    Unbound has supplanted the Berkeley Internet Name Daemon (BIND) as the default, base-system name server in FreeBSD and OpenBSD, where it is perceived as smaller, more modern, and more secure for most applications.

    Since the OpenBSD folks are THE most A.R. folks in the world about security, their endorsement is pretty much golden.

    Consider me sold. I’ll be installing this on the PiHole when time permits, first. Then also on every other system I’ve got (that will point to the PiHole as their upstream…)

  7. E.M.Smith says:

    I just did a test install and configure of “Unbound” on the Odroid XU4. It still just looks upstream to the Raspberry Pi Pihole for DNS resolution, but is a proof of ability / concept (and added cache layer):

    root@XU4uDevuan3:/etc/unbound# nslookup
    Non-authoritative answer:

    On my first try I had exactly ONE misconfiguration:

    root@XU4uDevuan3:/etc/unbound# unbound-checkconf
    /etc/unbound/unbound.conf:916: error: forward name override, there must be one name for one forward-zone
    read /etc/unbound/unbound.conf failed: 1 errors in configuration file
    root@XU4uDevuan3:/etc/unbound# !vi
    vi unbound.conf
    root@XU4uDevuan3:/etc/unbound# unbound-checkconf
    unbound-checkconf: no errors in /etc/unbound/unbound.conf

    I’d not realized each name needed a new “forward-zone” declaration… OK, moving on…

    At some future time I’ll write all this up. I’ve got a few polish bits I want to get done too, before I do a write up. That is, I don’t just want it to work, but have some decent configuration choices ;-)

    The config file is very long and for a lot of it I just blindly accepted the defaults or I made very minor changes. I also did not do one of the things I really want to do: Set it up as an authoritative server (with root server hints file download and with MY internal hidden domain names in use for my hidden IP ranges AND with the nice way it has for letting you BLOCK anyone not listed as in that domain from using it.)

    I turned on a test network, but want to make a more complete and rational set. It states the defaults as #comments, so you can see my one addition of letting anything in use this server:

     # control which clients are allowed to make (recursive) queries
            # to this server. Specify classless netblocks with /size and action.
            # By default everything is refused, except for localhost.
            # Choose deny (drop message), refuse (polite error reply),
            # allow (recursive ok), allow_setrd (recursive ok, rd bit is forced on),
            # allow_snoop (recursive and nonrecursive ok)
            # deny_non_local (drop queries unless can be answered from local-data)
            # refuse_non_local (like deny_non_local but polite error reply).
            # access-control: refuse
            # access-control: allow
            # access-control: ::0/0 refuse
            # access-control: ::1 allow
            # access-control: ::ffff: allow
             access-control: allow

    All in all, I’m quit impressed with it (so far…). Now I just need to add it to the Pi Hole server…

  8. Pinroot says:

    Running i2pd on a Raspberry Pi Zero

    (Sorry to be late to my own post.)
    I originally got the idea for this after hearing about all of the different ‘alternative internet’ things that are out there today. FreeNet, TOR, i2p and several others, along with projects like FreedomBox and similar options (I’m excluding things like the Fediverse because they exist on the the clearnet, although they will probably work on the ‘invisible’ internet). I finally decided to work with i2p because: 1) Something about it appealed to me and 2) EM was also working with it, and documenting it, so I had someone I could follow and ask for help if necessary.

    I decided to use a Raspberry Pi Zero because that’s one of the cheapest SBCs (Single Board Computer) I know of that might be up to the task. I don’t follow the SBC world that closely, so this is the lowest end SBC that I’m currently aware of (not including things like Arduino which, AFAIK, can’t run something like i2p). I wasn’t sure that it would actually work, based on the specs for the Zero, so this was mostly a “proof of concept” thing as much as anything. My philosophy has always been sort of like “the least amount of x to accomplish y” where “x” is hardware, software, labor, you name it.

    The Zero goes for about $10 US ( In addition to the Zero, you’ll also need, at a minimum, a heat sink for the CPU, and some type of ventilated case. I bought a kit from Amazon for ~$27 US, which had a lot of the things you’ll need, minus the power supply, uSD card and keyboard. Specifically, you’ll need the following:

    Raspberry Pi Zero
    Heat sink
    USB power supply
    Wireless Keyboard (USB or Bluetooth)
    Dongle to connect to USB keyboard
    uSD card (4 gig minimum)
    HDMI to mini HDMI adapter

    In the end, this will be a stand alone headless system, so you won’t need the keyboard, keyboard dongle or HDMI adapter when you’re done. It will also be command line only, so there will be no windows or desktop manager.

    For the Linux distro, I chose DietPi ( It’s based on Raspian, but it’s supposed to be optimized for a variety of SBCs. They also have a variety of packages that are supposed to be optimized for different purposes, so if you want to run a VPN, there are packages optimized for that, if you want to run a TOR router, there are packages optimized for that, and so on. Unfortunately, there was nothing for running an i2p router, so I was on my own, but that’s not an issue, as the standard apt-get install packagename works just fine. It does use systemd, which I’m not happy about, but I can live with it for now. You can try a different distro if you like, and most of this “how-to” should still work. Side note: installing and configuring Linux will be “difficult” part of all of this.

    After downloading, unzip the archive. It should go from ~180M to ~1G (great compression). You’ll then need to burn the image to your uSD card. I’m currently using a MacBook Air, so I used balenEtcher ( (Sidenote: I can open a terminal on the Mac, but I can’t get the dd command to work). There are versions of etcher for all the major OSs (Windows, MacOS and Linux), so this looks like the easiest option. After writing the image to the uSD card, you can put it in the Zero and boot it up.

    My first MM/LL (Mistake Made/Lesson Learned): After writing the image to the uSD card, I manually repartitioned it. I had a 32G card and I think the image takes up 4G (although it could be less). I repartitioned the card to use the full 32G, minus a swap partition I set up. Turns out, all of this was totally unnecessary. On the first boot up, DietPi apparently runs a script that looks at the card size and repartitions the card to use all of it, minus a swap partition. The only real down side is that the initial boot seems to take forever and you might think that it’s locked up when it’s really not. This may have been covered in the docs, which I didn’t bother to read. Also, this may not happen, depending on the distro you’re using, and you’ll have to do it manually. YMMV.

    Eventually, you’ll get a login prompt. The system comes with two accounts: “root” and “dietpi”. The password for both accounts is “dietpi”. It is recommended that you change the passwords as soon as possible. When you login, you are presented with a MOTD (Message Of The Day) that displays some of the system specs, along with a list of useful commands (which are basically scripts to do certain things).

    The first thing you’ll want to do is set up wireless. There is no ethernet port on the Zero, so wifi is necessary. This is pretty straightforward. With dietpi, there is a configuration script that will allow you to configure most of the things you’ll need to get the system up and running (the same is true of other distros). Once this is set up, you’ll want to do a system update, so, as root, do:

    apt-get update
    when that’s done, do:
    apt-get upgrade

    After upgrading, you’ll want to use the configuration script to configure your keyboard. DietPi is based on Raspbian, which uses a UK keyboard, so you’ll want to set it to a US keyboard if you’re in the states (text is the same on both, but various characters are mapped differently, which is confusing if you’re using the wrong keyboard mapping).

    Once the keyboard is configured, you’ll need to set the date and time. Again, use the configuration script to do this. You should also give your system a static IP address, which will make it easier to find it on the network. You can do this with the configuration script. Finally, you’ll want to install and enable an ssh server. DietPi offers two options for this: Openssh and something called DropBear. I selected DropBear, because it was smaller and lighter, with a bit less overhead.

    During configuration, the system will reboot several times. When you finally have things configured to your liking, you can disconnect the keyboard and monitor and, from another computer, ssh into your RPi Zero. If you’re using Linux or MacOS, you can do this from the command line. If you’re using Windows, you’ll probably want to use Putty. Once you’ve successfully logged into the Zero, about all that is left is to install i2pd. As root, do:

    apt-get install i2pd

    After the installation is complete, i2pd will automatically start. There are two configuration files for i2pd, located in /etc/i2pd. One is named i2pd.conf and the other is named tunnels.conf. For most situations, the default configuration will work, but you may want to go in and tweak some settings, especially the amount of bandwidth you want to share. When I edit configuration files, I always make a back-up of the original config file, just in case something breaks. I usually just copy the original config file and give it a new extension like this: cp i2pd.conf i2pd.conf.orig. Now, if I break something, I just cp i2pd.conf.orig i2pd.conf and I’ve got my original config file back.

    One thing you’ll probably want to change in i2pd.conf is the loglevel. The default setting is “info”, but there is a lot of info, and your log file (located in /var/log/i2pd/i2pd.log) will get very large very fast. I set mine to loglevel = error which will only log errors, which will give you a much smaller file.

    There is a web console that you can use from a remote machine to monitor the status of your new router. To access it remotely, you’ll need to do, from the command line (or via putty) the following:

    ssh -NL 7070:localhost:7070

    Then, on the same machine, open a browser and enter in the address bar. You should see the web console from your Zero on your local machine. Check the network status; if it says “Firewalled”, then you will not get very many transit tunnels (which are tunnels using your router to get to other machines). In my case, I sometimes get one or two transit tunnels, but mostly zero. After doing some searching, I found that I needed to move it from behind the firewall that was enabled on my router. The easiest thing to do in this case (for me anyway) was to put the Zero on the DMZ, which exposed it directly to the internet. Doing this may vary from router to router, but in my case, I located the DMZ configuration on my router, and added the static IP address I had assigned to the Zero earlier to the DMZ. I had to restart i2pd, but once I did, the transit tunnels started increasing, by a lot. The max I’ve had is a little over 800, but they typically run around 400-500.

    To shutdown i2pd gracefully, you can go to the web console and do it from there. Or, if you prefer, you can do it from the command line. ssh into the Zero and as root do:

    systemctl stop i2pd

    It can take up to 10 minutes for i2pd to shutdown, depending on how many transit tunnels you have routed through your machine. Once it’s stopped, you can make whatever changes you need (to the config files or whatever). Once you’ve made any changes you wanted to make, restart i2pd with:

    systemctl start i2pd

    and i2pd will restart. You want to stop i2pd gracefully to keep from being put on a ‘blacklist’ of routers that abruptly stop, which will break any transit tunnels using your router.

    My system has been up and running continuously for 14 days, and I’m using roughly 110M out of the roughly 480M available on the Zero and so far, I’ve used no swap space. Overall cpu usage for i2pd runs around 35%-55% although it can spike up to ~90% at times, depending on the number of transit tunnels using the router. The cpu temperature runs around 120F to 130F, again depending on transit tunnel usage. The clock speed is 1 GHZ, and as far as I can tell, it hasn’t had to throttle back any. So, as a proof of concept, I’m pretty happy, and it’s actually running much better than I had expected.

    More documentation regarding the config files can be found here:

    Hopefully this has been useful for anyone considering setting up an i2pd router on inexpensive hardware. I have typed most of this from memory, so I apologize for anything I might have omitted. As I said above, if you can install and configure Linux, setting up i2pd will be simple. If anyone has any questions, I’ll do my best to try to answer them, but just know that I’m still learning this myself and may not have the answers (I’ve still got a lot of questions myself). Best of luck!!

  9. E.M.Smith says:


    You can’t be “late” to your own event, you just were letting the audience warm-up happen ;-)

    I think the Arduino class is called “microcontrollers”. They are computers, but of the very limited kind. 4 bit, 8 bit, 16 bit and only now with the IoT push, more 32 bit with memory in the KB to low MB range and CPU clock cycles in the kHz to very low MHz. I/O entirely through pins. No GPU / FPU.

    You can run Linux on many (most?) of them, but you won’t run FireFox… or likely even LXDE / XFCE type desktops. It might run i2pd on the bigger ones, but frankly, by the time to add all the stuff needed to talk to the chip and make it “go” and talk to ethernet, your price will have gone beyond the Pi Zero. I think you likely hit the optimal price point device already.

    As an Arm v6 single core device, that’s presently about the smallest performance SBC on the market. There are older v5 designs and some 16 bit isa chips / boards were made, but to the best of my knowledge, none are still sold (other than perhaps as repair units for embedded systems in the field). As the microcontroller market is moving to 32 Bit, it is catching up, but not exceeding…

    I am also a “minimalist” and enjoy the challenge of “doing the most with the least” (kind of like Haiku…). One thing I’ve not gotten a round to: Putting Linux on a microcontroller:

    μClinux is a variation of the Linux kernel, previously maintained as a fork, that targets microcontrollers without a memory management unit (MMU).[1] It was integrated into the mainline kernel as of 2.5.46;[2] the project continues to develop patches and tools for microcontrollers. The homepage lists Linux kernel releases for 2.0, 2.4 and 2.6 (all of which are end-of-life in mainline).

    The letters “μC” are for “microcontroller”: the name is pronounced “you-see-Linux”, rather than pronouncing the letter mu as in Greek.

    Just if you were looking for a challenge in the ever-smaller space ;-0

    IF you like converting things to other uses, there’s a lot of these kicking around in common devices and you can likely find a few dozen in any yard sale or the junk pile after Christmas upgrades:

    Greg Ungerer (who originally ported μClinux to the Motorola ColdFire family of processors) continued to maintain and actively push core μClinux support into the 2.6 series Linux kernels. In this regard, μClinux is essentially no longer a separate fork of Linux.

    μClinux had support for many architectures, and forms the basis of many products, like network routers, security cameras, DVD or MP3 players, VoIP phone or gateways, scanners, and card readers.

    But like I said, the “rest of system” cost to get it talking Ethernet and terminal interface will almost certainly be higher than a Pi Zero.

    Shopping list if you do decide to go hunting in the ever smaller land:

    Supported architectures
    The current list includes:

    Altera Nios/Nios II
    Amber (open FPGA core)
    ARM ARM7TDMI, ARM Cortex-M3/M4/M7, ARM Cortex-R
    Lattice Mico32
    NXP 680×0 (Motorola/Freescale 680×0)
    Hitachi H8
    Hyperstone E1/E2 (called hyLinux)
    Intel i960
    NXP ColdFire (Motorola/Freescale ColdFire)
    NEC V850E
    Xilinx MicroBlaze

    Note that systems with an MMU are not on this list. They can run other Linux releases. Also note that there is an Arduino IDE for Linux that lets you develop code on your desktop Linux and then export it to the dinky little Arduino controller. But that’s a whole ‘nother thing…

    Gee… you were “following” me and now I’m following you ;-) Law of Mutual Superiority at work!

    Well, I can see one thing I need to do. I didn’t set up ssh on my Pine64 A+ installation… I can’t get into it without plugging / unplugging HDMI ./ KB / Mouse… I also left it DHCP so I’d have to log into my router to find out what address it is at…

    FWIW, I think DietPi is a downstream port of Debian (as is Raspbian) and not downstream of Raspbian. They are both so close to Debian (with additions / overlays) that the difference is not important. OTOH, Raspbian is V6 and Diet Pi on a single core V6 chip might be easier to do starting from Raspbian as I don’t know of many other v6 Debian, so I could be all wrong on that.

    Your performance and resource usage numbers are rather impressive. The Java version soaks up a whole lot more machine for a lot less activity. I think you have inspired me to set this up on my old Raspberry Pi 1 B+ board. I’ve got Devuan on it, so the OS part is done. It had been my Squid Proxy / DNS server for years but is now idle as I moved that up to a Pi M2 board. As it is “dinky hardware” and v6 I was thinking maybe it was EOL time for the little guy… Now I’m thinking maybe not ;-)

    It is slower at 700 MHz, but you are not hammering your 1 GHz anyway so that ought to be fine. Memory looks OK. No swap means I don’t have to deal with attaching some swap device and / or configuring zram… Hmmm….. Maybe after I’ve finished my “unbound” rollout (or as part of it?) I can make that little guy useful again.

    I’m also once again getting the itch for a WiFi based Zero. The Pi Zero W I think it is. One of them in a tiny package with battery and set up for access from a laptop would let you put an i2p router in a mints tin that you could take to places like the local library or coffee shop and let it run while you read / have coffee… It could also provide things like secure DNS and SQUID proxy service to your laptop… (Basically the Dongle Pi project brought up to date…)

    The idea being (as I move to more Dark Net supported participation) to have a little protective appliance in a tin that provides me with Identity Isolation from the actual WiFi login, VPN and secure DNS services, a SQUID proxy to the internet, etc. Well, as I’m doing more i2p, I’ll want / need that too. As the original Dongle Pi was a Pi Model 1 B+, the Zero ought to be more than enough. It runs headless anyway… and the Zero W has WiFi built in so no $15 dongle needed. Oh Dear, I think I’m talking myself into it ;-)

    I’ve used Diet Pi, and it is very easy to do for folks “starting out”. Compared to the stuff involved in getting Devuan Beowulf on a board it is MUCH easier. For “Noobs” those packages of pre-made appliance layouts can be a great help. I’m more a “done it long hand forever” guy so they are convenient to me until they get in the way of what I already know how to do by editing config files… OTOH, SystemD has already blown a lot of that ‘prior skill’ for me anyway… I think Diet Pi was one of the first non-Raspian OSs I ran on the Pi Model 1 B+ back when I first started using them ;-)

    Well, thanks for the write-up. I don’t know how many other folks will want to make one of these, but you may get some questions. OTOH the write-up is pretty clear.

  10. Pinroot says:

    I haven’t really kept up with the Arduino machines. I bought one about five years ago (maybe longer) and played with it a bit, but overall, it seemed that for a few more dollars, you could get a RPi which had ethernet, usb and 40 pin GPIO, so to me, it seemed a no brainer. I’ll have to give them another look and see what they have available.

    I’ve heard of μClinux but never really looked into it. With all of the minimal microcontrollers that are out there, who knows, it might be worth looking into? The Wiki article you linked to shows an old iPod booting it up; I’ve got an old iPod laying around somewhere. I could try to install it, but have no idea what I would use it for.

    I’ve got an old RPi B1 board I ran across not too long ago. I think it only has 256 M RAM, so I think I would definitely need some swap space to run anything on it. I’ve been wanting to set up a Pi-Hole and will probably eventually repurpose the Zero for that after I get the RPi M3 running i2pd. I’m not sure what I’ll do with the B1, but it should be good for something that isn’t too cpu intensive.

    You owe it to yourself to get a Zero :) I’m really impressed at what it can do for its small size. Definitely worth the few $$ it costs.

    Oh, one thing I forgot to mention regarding i2pd, there are a lot of resources on Reddit, it turns out. It seems that every time I would search for something, I would get several useful links to Reddit. So keep that in mind when looking for help.

  11. E.M.Smith says:


    That “for a few $ More you get a Pi with [list of stuff]” is what I meant by “it would cost more to add the stuff”. The Arduino is good for things like controlling a robot arm, or a thermostat, but once you add stuff like ethernet et. al. it is not only dramatically under performing but over priced too!

    IF I had an old iPod I’d do it just to say “I’ve got a linux in my pocket” ;-)

    I’ve got the 500 MB one. What I’d do with 250 MB is pretty simple. I’d use it for a headless DNS server / Squid server. The 500 MB one (when NOT running a windowing system) has plenty of memory left over doing that. So take it to CLI install level. Add “squid” and “unbound”, configure and be done.

    Anything headless, really. It is LXDE / XFCE and the graphical apps (FireFox, Cromium, Gimp, LibreOffice) that suck up the memory. Headless no graphics and you don’t need the other 250 MB. Also note that v6 codes are much less memory intensive than aarch64 V8 codes. What runs OK in 512 MB on my Pi Model 1 B+ needs about 1.5 GB on the Odroid v8 64 Bit …

    I’m pretty much emotionally committed to buying a Pi Zero next time I put an order in somewhere. (As it stands now I’d likely spend as much on shipping as on the device unless I bundle it in a package buy…)

  12. Pinroot says:

    Well, I just checked the Zero and memory usage is way up. 195M/478M, I think the other day it was 120M or less. And the buffers are about full, I can flush them, but I don’t know about the other, or why it’s happening now after 15 days or so. Still, not a deal breaker, all things considered, but I am curious.

  13. E.M.Smith says:

    Probably total usage for tunnels and things have to time out to be released. Give it until slack time then check…

  14. Pinroot says:

    Yeah, I’m hoping it’s something like that. Otherwise, I’ll eventually have to do a graceful shutdown and reboot. I’ll keep an eye on it and see how it goes.

  15. Pinroot says:

    Well, another oddment today. Went to ssh in, no problem, MOTD shows cpu temp to be a little high, but tolerable. Went to run ‘htop’ and nothing happened on screen, looks like it might be running in the background, but not displaying anything. Finally ctl-c and get back to a prompt. Same with ‘top’, it looked like anything which continually refreshed/updated the screen couldn’t or it wasn’t showing up. ‘free’ showed about the same memory amounts ‘used/total’ as the day before, so no problems there. I found a short one-liner to pipe the output from ‘ps’ (plus a whole bunch of switches) through ‘head’ to get the 10 most cpu intensive programs, and nothing looked out of place. Found out the cpu was throttled back to 700MHz, but couldn’t figure out why.

    Checked in later and the web console showed that I was offline, apparently because of clock skew. I remember reading something in the i2pd docs about that, so I guess I need to look further into it. In the meantime, I rebooted it, and will be keeping an eye on it. Still 19 days or so before problems showed up, not bad. I had thought about doing a graceful shutdown earlier, but hoped it would clear up on its own. Lesson learned.

  16. E.M.Smith says:


    I think you will find that OS releases in armel set the CPU governor for the Pi Model 1 which is at 700 MHz. They don’t know if you will be on one of them or on successor boards with higher clock rates, and sometimes just did the original armel build and then never went back to revisit details on other boards, just did a “boot it, it worked? Ok ship it.” cycle.

    I ran into something similar with, IIRC, Raspbian. As it runs across several boards, the clock is set low on some. I put it in an article long long ago… IIRC my Pi M3 was running at under 1 GHz not 1.2 or 1.3 due to the clock being set appropriate for the original Pi M2 boards 900 MHz. Pi Foundation loves to say “You can run the same OS on all the Pi boards”, but that “has issues”…

    Make Your Raspberry Pi M3 Run 2 x As Fast – at the advertized rate…

    Looks like it was limiting at 600 MHz…

    There’s also a tendency for the Pi Foundation to clock boards slow to prevent heat limiting and potential heat damage as they sell boards devoid of heat sinks… They figure, I guess, that if you are clueful enough to know you NEED heat extraction you will also be clueful enough to reset the governor and max speed.

    Did you ever have htop running over the ssh link? I.e. was this known aberrant behaviour or just not known to work?

    IF you have clock skew, then somebody isn’t checking in with a time source. An up and running OS ought to be adjusting time. I’d check the clock config. Looks like instead of ntp constantly adjusting, DietPi does it once / day (or DID 7 years ago, maybe fixed now or maybe legacy issue):

    ntpd setup
    Post by Gord_W » Sat Nov 28, 2015 2:40 pm


    I would like to get the clock on the rpi set so that it doesn’t drift. I’m using the rpi for a timing application over a wide temperature range and just having the clock updated once per day with a cron job is not going to cut it as the drift is significant.

    So I would like to have ntp running all the time.

    If I run nptd from the command line, it starts and runs.

    I’ve edited the ntp.config file to allow for logs to be created
    # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
    driftfile /var/lib/ntp/ntp.drift
    My rpi is headless and I’m using ssh.

    So my problems and questions and remember that I am a beginner here:

    1) What is the best way to start ntp at boot and set the clock?
    2) Can I just remove the ntp lines in the daily cron job and not break anything else?
    Any other pointers that I may be missing?

    Gordon Williams

    User avatarFourdee
    Site Admin
    Posts: 2779
    Joined: Tue Feb 06, 2007 1:36 pm
    Re: ntpd setup
    Post by Fourdee » Sat Nov 28, 2015 2:59 pm

    Hi Gordon,

    DietPi runs ntpd during boot and once daily. We use the ntpd -gq flag to quit ntpd when its obtained the time, saving resources.

    I’ll need to update DietPi code to allow for a constant running ntpd. I will create a option in dietpi.txt that will allow for both options.

    ntpd runs as root, so there is no chance of file permission issues.

    So I’d guess they they put in an OPTION for constant time checking / drift adjustment, but not made it the standard mode.

    Which is a bit of an issue. Things need to be on the same time page.

    Sidebar on DNS:

    I think I’ve got my PiHole talking to ‘unbound’ talking to upstream DNS all with DNSSEC (that does credential checking on DNS requests to prove they are valid, but doesn’t hide the request). Only problem is that the “test case” site in an article reference doesn’t seem to be there anymore (threw me for a while…). Log file looks OK, but I’m not sure what it is supposed to look like ;-)

    I’m working on using TLS or HTTPS to wrap the requests to upstream next.

    So I’ve hardened my DNS against Man-in-the-middle and spoofing, but not yet got it totally hidden from prying eyes (though it is no longer going to the Telco… nor to Google…). This config also caches heavily AND can be set to not do forwarding at all, but just ask for Source Of Authority and go get the record there (again reducing information leakage).

    Once I figure out the encrypted tunnel options and get that going, and figure out a way to test it all, I’ll write it up.

    Installing ‘unbound’ is trivial. Setting up the config is easy for straight use, a bit confusing for the security & privacy settings (partly as it looks like those changed over time and the help pages at various sites are often out of date…).

    Pointing the Pi-Hole at ‘unbound’ is also trivial. It’s in the DNS heading of the admin web page, you just uncheck all the “usual” upstream providers and on the right side of the panel, put in your machine and port number: or whatever you set in the ‘unbound.conf’ file.

    So your PiHole still filters a lot of adverts and crap, and if you point at a ‘filter malware’ upstream a lot of that gets blocked as well. Then washing all that through DNSSEC and wrapping it in (TLS or HTTPS) both assures you are getting the right responses AND nobody else is tracking them, and configured to cache root / server info and walk the tree, ‘unbound’ gets it from the Source Of Authority and not some intermediary forwarding “track me” server…

    I think that about as hardened as I can get it. Though there are other hardening options in ‘unbound’ that I’m still figuring out…

    Overall I find it a pretty good package of stuff.

    This one does DoH, DNS over HTTPS via Cloudflare. I’m not real keen on Cloudflare for 2 reasons.

    1) They used despite it having a load of legacy issues from other uses for years.

    Prior usage of the IP address
    Technology websites noted that by using as the IP address for its service, Cloudflare exposed misconfigurations in existing setups that violated Internet standards (such as RFC1918). was not a reserved IP address, yet was abused by many existing routers (mostly those sold by Cisco Systems) and companies for hosting login pages to private networks, exit pages or other purposes, rendering the proper routing of impossible on those systems. Additionally, is blocked on many networks and by multiple ISPs because the simplicity of the address means that it was previously often used inappropriately for testing purposes and not legitimate use. These previous uses have led to a huge influx of garbage data to Cloudflare’s servers.

    While a lot of that is cleaned up now, not all of it will be.

    2) Several times I’ve had Cloudflare responses blocking me from valid sites I wanted to visit.

    But it is a good ‘how to’ (maybe…). I just want to use a different source upstream.

    This one describes “unbound” over TLS:

    More generic encrypting DNS articles:

    So I’m digging through that stuff and related working up a simple config for My Private Networks that keeps them private (authoritative for me) while doing recursive DNS from root servers to Source Of Authority servers (i.e. no using forwarding servers when possible) and doing it all with DNSSEC (certificate authentication) and inside some encrypting tunnel (TLS or HTTPS).

    Yeah, a mouthful…

    So far I have the Pi Hole definitely pointed at “unbound” using DNSSEC and I’m pretty sure I have “unbound” doing DNSSEC to an ad and malware blocking upstream (belt AND suspenders ;-) forwarding server. I’m not sure if my “start at root” option is doing anything at all yet.

    Still to do: Prove it / test it / validate my belief. Wrap it in TLS or HTTPS. Learn how to cleanly adjust from “use forwarding upstream” to “root servers to source of authority only”.

    Maybe it needs to be a couple of articles, one leap at a time ;-)

  17. E.M.Smith says:

    Well, I think it is working. I finally figured out the “dig” output.

    I don’t know who thought “dig” was a good idea, but I really like “whois” and “nslookup” a lot better. It took me a while to realize I was looking for “what wasn’t there”. The “Answer Section” is missing in the sigfail test case…

    [ ok ] Restarting DNS server: unbound.
    root@devuan:/var/log/unbound# dig # -p 5335
    ; <> DiG 9.11.5-P4-5.1+deb10u3-Debian <>
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21997
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ; EDNS: version: 0, flags:; udp: 1472
    ;			IN	A
    ;; ANSWER SECTION:		3600	IN	A
    ;; Query time: 798 msec
    ;; SERVER:
    ;; WHEN: Wed Apr 21 21:15:14 UTC 2021
    ;; MSG SIZE  rcvd: 56
    root@devuan:/var/log/unbound# dig @ -p 5335
    ; <> DiG 9.11.5-P4-5.1+deb10u3-Debian <> @ -p 5335
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63885
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    ; EDNS: version: 0, flags:; udp: 1472
    ;	IN	A
    ;; Query time: 4909 msec
    ;; SERVER:
    ;; WHEN: Wed Apr 21 21:16:42 UTC 2021
    ;; MSG SIZE  rcvd: 57
    root@devuan:/var/log/unbound# dig @ -p 5335
    ; <> DiG 9.11.5-P4-5.1+deb10u3-Debian <> @ -p 5335
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51618
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ; EDNS: version: 0, flags:; udp: 1472
    ;	IN	A
    ;; ANSWER SECTION: 3600 IN	A
    ;; Query time: 186 msec
    ;; SERVER:
    ;; WHEN: Wed Apr 21 21:17:27 UTC 2021
    ;; MSG SIZE  rcvd: 71

    So “whatever”. I’ve got Pi to “unbound” working. Then “unbound” lookups are working and the ‘fail’ test case returns nothing as the DNSSEC doesn’t get what it wants. Looking at the log file was very useful (verbosity=2) for debugging. I had to turn on some of the “hardening” options…

    At this point I think all that is left is “put it in an encrypted tunnel”. But, as usual, “we’ll see”… I probably ought to write up what I’ve got so far, as just PiHole to “unbound” to either recursive DNS server or root servers with DNSSEC is a security improvement.

    I had to paste in the captured text above ON the Pi Model 1 with the Epiphany browser. Nice little browser and worked well, but with the Pi Model 1 (single core armel 700 MHz on a good day 500 MB memory) already doing squid proxy, DNS server, PiHole filtering and who knows what else including 2 terminal sessions for me (one doing a tail -f of the unbound log file…) it was a struggle.

    Browser was good, but typeahead was horrible. Type 4 char, wait 1 2 3 then type 4 more…

    So I finished these details on the Pentium-4 single core box…

    Poor little Pi Model 1 had to roll everything it could to SWAP. Now, browser and terminal sessions ended, htop running: it is 243 MB memory used, 494 MB on swap. Looks like a lot of the OS is “optional” for basic operation and only needs to be available if needed ;-)

    OK, I’m off to read up on “unbound” via TLS / HTTPS. TLS hides it OK, HTTPS hides it better but slower. Decisions decisions…

  18. Pinroot says:

    The Zero had been running at 1GHz, up until yesterday, when I saw that it was throttled down to 700MHz, but never could figure out why it was throttled back. And htop and top have always worked over ssh, so I don’t know why I got no output yesterday, but I suspect all of the problems were related. The way memory usage spiked makes me wonder if there was a memory leak that just got worse and worse. I’ll keep an eye on that and see what happens.

    I’ll look at dietpi.txt to see if there’s a way to make ntp run more than once a day (if I can find the file). If not, hopefully I can edit the cron job that runs it and maybe update it 4 or 6 times a day. I checked the i2pd docs and there was nothing about clock skew, but there was a mention in a faq that said it won’t run if the time isn’t right, so maybe a little drift is all it takes to shut down the router. Something else to look into.

    Re DNS – That’s a lot for me to digest lol. At least I know now where I need to work on my understanding of something more than basic DNS. Thanks for the info dump!

  19. E.M.Smith says:

    Well, I’ve converted my 2nd DNS Server to be a PiHole ad filter behind “unbound”, doing recusion from root servers, and9 with caching plus DNSSEC validation. I think I understand ig enough to write up now….

    Did a first stab at DoT or DoH encryption. It will take a while longer….

    So my DNS traffic can still be seen on the wire, but no longer on telco servers nor Google. Plus spoofing blocked and speed is very nice.

    Time to call it a night.

Comments are closed.