The External Connector

The mini DIN connector on the back has a fairly standard pinout as shown below. Note it says 4800bps max for the DATA IN. I want to find out why!

In the service manual, I start by locating pin 1 on the DIN connector.

Internal Circuitry

Next I trace this to a pair of 2-1 muxes.

These muxes are operated together (that is, their control signal is the same signal). From my investigation, this is the mux pair that is activated when selecting the TNC operation for the radio. The right-most mux, IC114, selects between MIC IN audio from the mic port, through a series of filters, or the TNC port we’re interested in. The left-most mux, IC112, selects which TX generator chip we’re going to be using. The path I’ve highlighted in red is the TNC audio input path I’m trying to trace.

Transmission Modulation

Next the signal travels to the MICIN pin on a chip with designator IC109, and part number BK4811B.

This is where the magic of modulation happens, and where I ultimately found the reason for only supporting up to 4800bps. Scouring the web for a datasheet for this chip, I found a PDF I could download. Checking the relevant sections of the chip’s documentation, I found the culprit, screenshot below:

The audio path into the chip is shown in the blocks at the bottom. The bullet points 6 & 7 tell the details of why 9600bps isn’t usable. The low-pass and high-pass blocks cannot be bypassed on this chip, and the maximum achievable width is ~2.7k, which is not enough for 9600bps. You can turn off the compander and pre-emphasis, but there’s no way to expand the LPF->HPF network bandwidhth. To run 1200-4800bps you really only need ~1kHz, but 9600bps needs to have much more.

Wrapping Up

Now that I am satisfied that the radio can *not* in fact TX 9600bps (but can receive it, perhaps another analysis in another post to come), I will get on with getting DireWolf setup for APRS, and FlDigi for other fun digital modes.

The post Why the Alinco DR-735T can’t transmit at 9600bps appeared first on Jacob N Calvert.

The Problem

The standard installation procedure for Windows via USB for a good while has been to dd the installer ISO image onto a USB disk and load it up on your computer. This changed a little when UEFI and SecureBoot became the norm for consumer equipment. Now, it’s pretty common to have a EFI boot partition FAT32 formatted with the EFI/BOOT/BOOTX64.EFI and all associated installers in the same partition. A typical machine will boot up, read the EFI boot file and go on with it’s business. Here’s where the problem begins.

FAT32 and the install.wim

In recent versions of Windows 10, there’s a file named install.wim. This file contains the bulk of the ~5.4GB installation image, and is more than 4GB alone. Herein lies the problem! FAT32 formatted partitions can’t index a single file larger than 4GB (32 bits worth of bytes ya know?). This presents a large problem! How am I to install this OS when I can’t load the files onto a partition to load the installer?

OK, so now what? Doesn’t UEFI require a FAT32 formatted partition?

Well, as it turns out, UEFI doesn’t actually care what format the EFI files are in, so long as the firmware know how to read it. So I tried to pivot to another common format: NTFS.

Booting UEFI via an NTFS partition?

Indeed! But this didn’t prove so fruitful at first. You see, ASUSTek only saw fit to include a FAT32 driver for their EFI loader, so the NTFS drive with the Windows 10 installation files on it just was not recognized by the firmware.

Stuck!

At this point, I was frustrated and was asking all sorts of questions like:

• How does ASUS load their image? Are they mass cloning drives and not actually installing? (Probably)
• Does this mean there’s no hope for a clean install of Windows 10 for dear wife? (Seems so)
• Why would they only include a FAT32 driver? (Who knows!?)

After a long while of Google-Fu (ok, actually DuckDuckGo), I stumbled upon this wonderful saint of an engineer’s GitHub repo.

Solution: UEFI-NTFS

This repo contains the answer to my prayers. You can read all the details at the repo, but here’s the solution in a nutshell.

Create a drive with two partitions, one partition FAT32 formatted and loaded with the UEFI-NTFS EFI goodies from the linked repo.

The other partition is NTFS formatted, and contains the desired over-4GB files we want to use.

The machine firmware will ignore the NTFS partition on this drive and launch the EFI booter on the FAT32 partition. This EFI booter will in turn load an NTFS driver, hunt down the NTFS partition adjacent, and execute the /EFI/BOOT/BOOTX64.EFI from there, chainloading the Windows 10 installation.

It worked like a charm! Within minutes the Windows 10 installer was running, and I was a much happier camper, and dear wife has a much faster OS to use due to this new SSD.

The post Who knew installing Windows could be so hard? appeared first on Jacob N Calvert.

Here’s a breakdown: on the FT232R, the max speed I can set the adapter to is 3MHz. This has given me a transfer speed (loading via GDB) of around 3KB/s. Not too bad for small projects of only a few hundred KiB. But now my code size is approaching a ~5 MiB, the debug cycle was way too long… 5MiB @ 3KB/s = ~28mins to load… not good!

Still in my pursuit of a cheap JTAG debugger (I mean come on! It’s just a serial protocol!), I did buy something. The Adafruit FT232H breakout is exactly what I was looking for. At only $15 with Amazon Prime shipping, I was back to debugging at a reasonable speed in two days.

The FT232H breakout is about as barebones as it gets. The board breaks out untouched ACBUS0-ACBUS7 and ADBUS0-ADBUS7 to 0.10″ pitch headers. Since the FT232H has a single MPSSE channel, I can use this breakout to get faster JTAG speeds.

My configuration files from the previous post had to change a little to accommodate. I’ll break it down below in comments in the file because it’s a little bit cryptic.

#
# FTDI USB Hi-Speed to MPSSE Breakout from Adafruit
#
# This should work for any bare FT232H
#

# Setup driver type
adapter driver ftdi

# 30000 kHZ -> 30MHz
adapter speed 30000

# Using JTAG (also could be SWD)
transport select jtag

# Common PID for FT232H
ftdi_vid_pid 0x0403 0x6014

# Set sampling to allow higher clock speed
ftdi_tdo_sample_edge falling


# Layout
# On this breakout, the LEDs are on ACBUS8 and ACBUS9, can't assign them
# registers are <ACVALUE><ADVALUE> <ACCONFIG><ADCONFIG>
# so we set 0x0308 to mean only ACBUS nTRST and nSRST, ADBUS3 (TMS) asserted high
# and we set 0x000B to mean only AC3,AC2,AC0 outputs -> (TMS,TD0, TCK)
ftdi_layout_init 0x0308 0x000b

# Pins
# pin name      | func. |
# --------------|-------|
# ADBUS0        | TCK   |
# ADBUS1        | TDI   |
# ADBUS2        | TDO   |
# ADBUS3        | TMS   |
# ACBUS0        | nTRST |
# ACBUS1        | nSRST |
#---------------|-------|

# When data == oe -> pins are switched from output to input to give
# the tri state (L, H, Hi-Z) effect 
ftdi_layout_signal nTRST -data 0x0100 -oe 0x0100
ftdi_layout_signal nSRST -data 0x0200 -oe 0x0200

So now it is as simple as connecting the corresponding pins on this breakout to the RPi3, and running OpenOCD again.

With the increased throughput of this MPSSE-supported interface, I now get ~587KB/s. Much better! It only takes ~8s to load my image now.

The post Better JTAG on the Cheap with the FT232H appeared first on Jacob N Calvert.

I recently stumbled upon HypriotOS while looking for Docker-ready distributions for my Raspberry Pi 3B+. I flashed this onto and SD card and started playing around with it. It works incredibly well, but I noticed that it was built for armv7l which is a 32-bit implementation. Since the Raspberry Pi 3B+ has a 4x core Cortex-A53 which is 64 bit, I wanted to make use of the 64 bit processor! I’ve worked with Yocto before (in fact, my day job uses Yocto), so I decided I’d build my own. For more on containers, see my other blog posts on what it is, what it can be used for, and how to use it.

Process

Prerequisites

Yocto is a build, not a distribution, so it is quite resource intensive. I would suggest having at least 60GB free disk space, and a quad core machine at a minimum. You’ll also need a Linux installation, and the build essentials installed (git, gcc, etc.).

EDIT: Checking the disk usage after the builds shows around 55GB used. On a 2C4T Intel Core i5 it took about 2H to build.

Project Setup

First, create a working directory and clone all the piece-parts we need to build.

mkdir rpi3bplus-build-yocto
cd rpi3bplus-build-yocto
git clone git://git.yoctoproject.org/poky
git clone git://git.openembedded.org/meta-openembedded
git clone git://git.yoctoproject.org/meta-raspberrypi
git clone git://git.yoctoproject.org/meta-virtualization 

Next create the project and add the base layers.

source poky/oe-init-build-env rpi64
bitbake-layers add-layer ../meta-raspberrypi
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-openembedded/meta-python
bitbake-layers add-layer ../meta-openembedded/meta-perl
bitbake-layers add-layer ../meta-openembedded/meta-networking
bitbake-layers add-layer ../meta-openembedded/meta-filesystems
bitbake-layers add-layer ../meta-virtualization

Edit the conf/local.conf file sections as needed:

MACHINE ??= "raspberrypi3-64"
CORE_IMAGE_EXTRA_INSTALL += "kernel-modules htop openssh iperf3 docker-ce bash ntp "

INHERIT += "extrausers"

EXTRA_USERS_PARAMS += " useradd pi; \
                       usermod  -p 'raspberry' pi; \
                       usermod  -a -G sudo pi; \
                       usermod -P root root; "

DISTRO_FEATURES_append = " virtualization"

Next we will build the image. This will take a while depending on how beefy your build machine is.

bitbake core-image-minimal
Parsing recipes: 100% |########################################################################################################################################################################################################| Time: 0:02:16
Parsing of 2540 .bb files complete (0 cached, 2540 parsed). 3827 targets, 140 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "raspberrypi3-64"
DISTRO               = "poky"
DISTRO_VERSION       = "3.0"
TUNE_FEATURES        = "aarch64 cortexa53 crc"
TARGET_FPU           = ""
meta                 
meta-poky            
meta-yocto-bsp       = "master:6bb4a252199cfd5d44ad7ab6fc4118c80a1aae92"
meta-raspberrypi     = "master:a0a5d3848e76b7f90ef8e42c56211da78db1c7ba"
meta-oe              
meta-python          
meta-perl            
meta-networking      
meta-filesystems     = "master:d9f3e6dbed8e5d96f2069280f0a566af89afb2fa"
meta-virtualization  = "master:5fb77ae4c4e1015e40257f9e59e16c497e30c53c"

After a couple of hours, you will have a completed, ready to flash SD Image at <build>/rpi3bplus-build-yocto/rpi64/tmp/deploy/images/raspberrypi3-64/core-image-minimal-raspberrypi3-64.rpi-sdimg which you can burn to an SD card with:

dd if=./core-image-minimal-raspberrypi3-64.rpi-sdimg of=/dev/sdX status=progress

Your image should boot up and docker will be running!

NOTE: You will manually have to set the date to pull from Docker registries over HTTPS because the certification validation will fail otherwise. We could add and configure NTP to fix the but… for another day. Use:

date "+%d-%m-%C%y %H:%M:%S" -s "2019-12-22 00:30:01"

There is one last thing you’ll want to do. You’ll want to use GParted or similar tool to enlarge your filesystem partition to take up the rest of your SD card so you will have some room for container images. You need to do this because the default SD Image builder script only provides enough space for the root filesystem and no more. In my configuration it ended up being ~300MB, so I expanded it take up the remaining ~59GB. See example below:

Results

As it turns out, I have a system that can build and run 64-bit Docker images and is pretty darn slim. Here’s a screenshot of htop running.. only 12 processes – not bad!

Some Metrics

The is the minimal image and it has 12 processes, with an incredibly low footprint. I loaded up an Ubuntu container and installed iperf3, then ran a test to my laptop. I was impressed to find the following result:

[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.13  sec   116 MBytes  96.0 Mbits/sec    9             sender
[  5]   0.00-10.13  sec   113 MBytes  93.8 Mbits/sec                  receiver

Even running that test, the load on the Pi was:

root@raspberrypi3-64:~# cat /proc/loadavg 
0.05 0.22 0.19 1/141 2125
root@raspberrypi3-64:~# 

Downloads

The post Building a Customized Linux Image for Raspberry Pi with Yocto + Docker Support appeared first on Jacob N Calvert.

Everything, and I mean everything is “smart” these days. Everyone has heard of the Internet of Things, and we are living through the emergence of some incredibly revolutionary connectivity. Some pretty cool and useful concepts have come out of it, admittedly, but there’s also some drawbacks.

I really enjoy the idea of having smart outlets that I can command with my voice, and there are outlets-a-plenty on Amazon, but can I trust them? I’ve decided to use my engineering skills to put a one of these outlets to the test.

Project Plan

Test Subject

I purchased a pack of Etekcity Smart Plugs which claim to be Alexa-enabled, and feature energy monitoring.

Test Plan

I want to test many aspects about the smart plug, so I laid out a test plan of tests I want to run.

• Record the network traffic coming and going from the device (couldn’t complete, see below)
• Pop open the device, see what hardware is under the hood
• Write some custom firmware for the device

Project Execution

Preparation

These devices generally work in the following way:

1. Connect to the device while it’s acting as an Access Point (AP)
2. Configure the device via a proprietary app
3. Device transitions from AP to Station Mode and connects to your local network
4. User connects Alexa/Google/etc services to device

When I started to look at the app for these devices, I decided against installing and using it per the user documentation. Here’s why.

The app for setting up the plug required the following permissions:

• Camera
• Contacts
• Location
• Call logs
• Phone
• Storage
• way, way more.

See the screenshot below for the full list.

So right off the bat, I decided to not install this app, simply because it had way, way too many permission oddities.

Opening the Device Up

I unpackaged these units and immediately noticed that there’s nary a screw anywhere. Upon closer inspection, you could see a thin line where the unit was clamshelled together. I grabbed my tools (a skinny flat-head screwdriver and a 3D printer sharpened spatula) and started poking for the release tabs.

After prodding the device for a few moments, I heard the distinctive “pop” of a plastic catch tab unclasping. I was able to raise up the edge of the clamshell and began working my way around the unit. Within seconds, the unit was open and the guts were exposed.

Jackpot!

The first thing I noticed was that the WiFi module is labeled as an ESP01! Very fortuitous for me since there is so much open source goodness out there the ESP8266 and ESP8285. Next up is figuring out how to flash this device. Others I’ve looked at hid the traces for the TX, RX, and GPIO0 on the backside, so after the module was soldered on, it was pretty much inaccessible. Not so, with this guy! There were test points on the PCB, perfectly labeled for everything I needed: TX, RX, GPIO0, 5V and GND.

I tacked on some temporary wires as shown in the photo and connected to my laptop via a USB-TTL Serial cable. My cable is a 3.3V logic cable with 5V on the VCC wire, so I powered the chip from my cable as well.

I opened picocom and set the baud rate to 115200, and voila! I had terminal output. Regrettably, I didn’t capture the terminal output, but it mentioned some version numbers, the ESP SDK version, and had the classic boot up text from the ESP01.

On the less fortuitous side, I couldn’t see any other chips (like the one used for energy monitoring), so I suppose they are on the opposite side of the PCB, which is molded into the shell.

Flashing the Device

I had all the right inputs, but would it flash? The answer was yes! I fired up the Arduino IDE and wrote a simple Hello, World app, and performed the flashing procedure: pull GPIO0 low, apply power, let GPIO0 float, begin flashing.

Without any fuss and to my surprise, the unit flashed without delay. I now had a working smart plug unit that I could flash very easily! I wrote up some custom firmware that allowed over-the-air (OTA) updates and removed my temp wires.

Custom Firmware

After a few iterations of writing “probing” apps and loading it onto the device, I figured out that the pinout from the ESP01 was the following (irrelavent pins ignored):

Of these pins, I knew how to use most right away. It was those energy monitoring pins I couldn’t figure out. Since I didn’t know how to understand the output, and I didn’t know what IC was generating the output, I couldn’t really make use of it. I noted a few characteristics about the signals however:

1. The signal on P12 stayed constant in time. I measured the low and high pulse duration, and they were the same (within 1 uS).
2. The signal on P13 was constant low when the relay was inactive, and toggled when there was a device connected and the relay was active.

From these observations, I made the assumption that P12 was the voltage pin, and P13 must be current or power. I also made the assumption that the signal must be a 50% DC signal which varies in frequency only. Using a pin change interrupt I was able to verify this assumption.

Now that I understood the signal profile, I needed to understand how to convert it to something usable. I had to do a lot of Googling around, but I stumbled upon a forum which showed many of these cheap WiFi outlets use a Chinese chip HLW8012. There’s only a Chinese language datasheet available for the HLW8012 on the web, but again, a little Googling revealed this guy’s website which is in English! He had a ton of useful information on his website, and it corroborated the signals I was observing, so I again made the assumption that this is the right chip.

Using the formulas outline on the last website I found, I was able to turn the P12 signal pulse width into a voltage, and verify that it was pretty darn close using my Kill-a-Watt. ( I highly recommend these little devices, they are super useful if you like to tinker). I got values that were ± 0.75% and so I concluded this was the right chip. Next was determining if the P13 pulse was a power or current. Since it stopped with the opening of the relay and started with the closing of the relay, it could have been both. From the previous website, the poster noted that the HL8012 chip had two outputs, CF and CF1. One of the inputs (SEL) made one output switch between voltage and current, and the other was always power. There was my answer! If the output on P12 was constant regardless of load, and I’d been able to get a voltage from the readings which was fairly accurate, then the other has to be power. Converting the P13 pulse to power also jived with my Kill-a-Watt’s readings (although with a little worse accuracy, it is ± 3% by my best estimation).

First Release

When I had identified how to operate all the parts of this little device, I set about writing a firmware load which enabled all the uses I desired. I ended up with the following feature-set in my first release:

• Alexa integration via Phillips Hue emulation
• Over-the-Air updates for touch-free updating
• Web Interface
  • Device Control
  • Device debug information
  • Device Energy Monitoring graphs
• LED indication for device state
• Button interface for manual on/off

Wrapping Up

I only accomplished 2 of my 3 stated goals, but I did have a ton of fun doing it! At the end of the day, I’ve got two functional smart outlets with energy monitoring which have custom firmware. By virtue of using custom firmware, I can control what is needed to control the device as well, so no shady apps with too many permissions. I liked these so much, and they were so easy to customize, I have decided to ordered 4 more for around the house!

The post Hacking a Smart Outlet appeared first on Jacob N Calvert.

Most of the time if you want to add a USB interface to your project, you’ll have to get an FTDI chip, or one of those similarly operating knockoffs. But those chips require additional external circuitry that you may not want to fool with (I know I don’t). This Hackaday blog post introduces a neat little chip, the CH330. This is a barebones chip which takes power, ground, D+, D- and renders a TX/RX pair on the other side for your project. A couple of problems arise however. All the data sheets you can find as of this time are in Chinese, but Google translate does an okay job of translating them. Also, I couldn’t find them for sale yet on AliExpress, which is where I expect to see them first. Go over to the Hackaday article for all the juicy details about this new-to-market chip and how you can incorporate it into your next design.

The post There’s a new USB-UART chip in town appeared first on Jacob N Calvert.

I’ve purchased a Creality Ender 3 printer from Amazon in the past month or so. I grabbed the printer, along with a roll of grey AmazonBasics PLA, and decided to try my hand at 3D printing. My “all-in” budget was around $250, shipped.

Now this printer is unique in several ways. It has a heated print bed, which is a nice upgrade. It features SD card printing, as well as a USB interface. The most unique aspect however, is that it comes as a DIY kit! That’s right, the unit flat-packed “Ikea-style” and you put it together yourself. I’ll admit, it made me a bit nervous because everything has to be “just-right” to print successfully. I’m happy to say that things went swimmingly!

The installation manual is mostly diagrams, but they are very well done. I spent about 3.5 to 4 hours putting it together one Sunday afternoon, and printed a Benchy Boat that evening!

I’ve been tweaking the settings in Cura (the slicer they recommend) and I have only one issue remaining, that appears to be related to Cura and not the printer. I am very happy overall and will post more of my prints when I get them going!

The post Into the 3D printer game I went! appeared first on Jacob N Calvert.

PCB and Parts are here!

The printed boards from OSHPARK arrived recently and so did the components. Below is a list of the components I selected for this board.

Prototype PCB from OSHPARK

Check out the images of the PCB OSHPARK made for me.

Prototype PCB

Some Corrections

I started to build the pedal circuit and realized I did not need 100mF caps everywhere. I re-simulated the circuit with 100uF caps, and it works just fine. I started with a huge cap value just as a placeholder and never updated the schematic.

Prototype One

For the first build, I soldered the components on and just left fly wires hanging off. I did this so I could pump signals into it and test the circuit response. See the prototype one below.

Prototype One

I didn’t save my oscilloscope captures.. I will remember next time! The good news is that from 20Hz to 8kHz there was a good solid amplification with minimal change of the input signal. Driving the input harder resulted in soft-clipping, but it was very minimal and still showed a solid gain performance. As predicted in the previous post, there was an amplification of around 2-3x the input signal, resulting in a noticeable volume increase.

Prototype Two

The second prototype is the “final product.” I stuck the circuits + inputs/outputs in the enclosure I purchased. It made for a nice looking product at the end of the day.

I am very happy with the results! It works and sounds great!

Restrospective

So, the question must be asked, did I complete my stated list from the previous post? The list is below as a reminder.

1. Take an AC signal around 300mV pk-pk and boost it by some multiple
   1. Check! It takes an input signal and boosts it by 2-3x
2. The boosted signal should not be muddled or distorted/clipped in any way
   1. Aside from the soft clipping when driving the input stage hard, yes!
3. The output signal should model the input signal, with the only difference being the amplitude
   1. Check!
4. It should run on +9V (either a battery or a standard guitar pedal wall-wart)
   1. Check!
5. It should have an adjustable output gain
   1. Check!
6. It should have a bypass capability
   1. Check!
7. It should not load the input source too much
   1. Check! Simulation showed less than 10mA sink.
8. It should have enough power to drive the output easily
   1. Check! It drives my amp input just fine!

In retrospect, I completed my requirements. But no retrospective is complete without some lessons learned and a demo!

Lessons Learned

1. I need to think about power input filtering on my next design. My 1Spot brand wall wart induces a high pitch whistle into the output stage that a 9V battery does not. It does this on every pedal I own, so this may be more of a power supply issue, but it might be solved with some input filtering. The whistle is barely noticeable, but in a very quiet room, I hear it.
2. More time needs to be spent on laying out the physical interface. I just sort of hacked this one together, but a more complex project could have been difficult.
3. Use quieter switches. I bought cheap DPDT switches, and they’re pretty loud engaging/disengaging. Listen for them on the demo.

Demos

Clean Boost Example

This example shows the clean boost aspect of the pedal. It simply boosts the volume of the signal.

Overdrive Boost

This example shows the pedal driving an amp harder into overdrive and getting a nice crunchy result.

Wrap-Up

All in all, I had a great time building this pedal, and I’ll continue making more pedals in the future! Stay tuned for the next project!

Thanks for reading!

The post Build Your Own: Clean Boost Guitar Pedal Part 2 appeared first on Jacob N Calvert.

• Talk about our proposed network architecture
• Set up our interfaces
• Set up a DHCP server and define our subnets
• Define some subnet ranges for our devices
• Set up some DHCP reservations
• Set up a DNS cache server
• Set up some basic iptables rules and forwarding

What you must have before this point

You need a Linux machine with two NICs, updated and ready to go.(I’ll be using 64bit Debian Jesse)

The Network Architecture

Most likely, unless you have a particularly different setup, you have a modem connected to a combo router/wireless access point, or perhaps a modem+router+WAP all-in-one unit. See the images below for a diagram of this:

Typical All-In-One Home LAN

Typical Modem+Router/WAP/Switch Home LAN

The units in the red boxes usually handle the following things and not much more:

• Routing
• DHCP
• DNS
• Firewall

It’s likely a small system-on-a-chip (SoC) and is configured with a web GUI. The architecture we are proposing is a little different. We want to replace that router part (the part inside the red box) with our Linux machine. We’ll let the Linux kernel do our packet switching, and let a few services handle DHCP, DNS, and the Firewall.

Note: this will require that you have a separate modem with an Ethernet interface.

Our IP network will have the following properties:

Let’s set up the interfaces

First, let’s see our two NICs and find out what the system calls them:

machine:/# ls /sys/class/net
	eth0  eth1  lo
machine:/#

So we now know our interfaces are named eth0 and eth1. Let’s designate eth0 as the WAN or Internet side of our machine, and designate eth1 as the LAN side of the interface.
Edit the /etc/network/interfaces to set up our WAN side to get and IP address from the ISP and our LAN side to have a static IP on our subnet.
The file should look similar to:

	source /etc/network/interfaces.d/*

	# The loopback network interface
	auto lo
	iface lo inet loopback

	# The WAN network interface
	allow-hotplug eth0
	iface eth0 inet dhcp

	# The LAN network interface
	allow-hotplug eth1
	iface eth1 inet static
		address 192.168.0.1
		netmask 255.255.252.0

Once you save this file and restart the network service, you should be able to see your interfaces using the tool ifconfig.
Now, plug in the WAN side to your router and let’s get on the internet!

Setting up DHCP

Since we want our Linux machine to hand out IP addresses on our LAN side, we need to install a DHCP server. Use your package manager to install isc-dhcp-server:

	apt-get install isc-dhcp-server

Now we need to tell the DHCP server what to do. Edit the DHCP configuration file (likely in /etc/dhcp/dhcpd.conf)

	option domain-name-servers              172.16.0.1;
	option routers                          172.16.0.1;
	default-lease-time                      600;
	max-lease-time                          7200;
	ddns-update-style none;

	subnet 192.168.0.0 netmask 255.255.252.0
	{
		option broadcast-address 192.168.3.255;
		allow unknown-clients;	
		pool {
			    range 192.168.1.0 192.168.1.255;

		}
	



	}

This will instruct the DHCP server to hand out addresses on the LAN in the range 192.168.1.0/24.
Restart the DHCP service to have these changes take effect. You should now be able to plug your laptop into the LAN port on your Linux machine and get an IP address via DHCP.
Now that we have some addresses assigned for DHCP use, let’s assign some DHCP reservations. Editing the same config file, add this:

host my-laptop {
		hardware ethernet aa:bb:cc:dd:ee:ff;
        fixed-address 192.168.2.0;
}

The ‘hardware ethernet’ line should contain the MAC address of your laptop, and the ‘fixed-address’ line should be the address you want to give that machine each time it requests one. Another restart will cause these new changes to take effect.

DNS Cache server

This is the easy part!

	apt-get install bind9

Done! That’s all for a basic configuration.

Forwarding and Firewall

Now we have a machine which can hand out IP addresses, but it can’t actually forward any traffic yet! First thing’s first, let’s enable forwarding.
Edit /etc/sysctl.conf and change the line regarding IPv4 forwarding to

net.ipv4.ip_forward = 1

Then, to make these changes active, issue a ‘sysctl -p’
Now we can forward traffic, let’s create some iptables rules to keep us straight. Two things to note here,

1. iptables rules must be re-enabled after each reboot
2. iptables can be dangerous! always backup your configuration

Because iptables are not persistent between reboots, we’ll use a script! Let’s first create a file in /etc/network/ called ‘iptables-rules’. In this script, place the following iptables rules:

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]


-A POSTROUTING -o eth0 -j MASQUERADE

COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]



# accept all loopback
-A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT

# accept all pings
-A INPUT -p icmp -j ACCEPT

# accept all established connections
-A INPUT -m state --state ESTABLISHED -j ACCEPT

# enable traceroute rejections to get sent out
-A INPUT -p udp -m udp --dport 33434:33523 -j REJECT --reject-with icmp-port-unreachable

# DNS from LAN
-A INPUT -i eth1 -p tcp --dport 53 -j ACCEPT
-A INPUT -i eth1 -p udp --dport 53 -j ACCEPT

# SSH from LAN
-A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT

# DHCP from LAN
-A INPUT -i eth1 -p udp --dport 67:68 -j ACCEPT


# forward packets along established/related connections
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# forward from LAN to WAN 
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth1 -o tun0 -j ACCEPT

# drop all other forwarded traffic
-A FORWARD -j DROP


# drop all other inbound traffic
-A INPUT -j DROP


COMMIT

The comments for each section describe what that particular rule accomplishes. Now, let’s make the script which will restore these rules on startup. Create an executable file in /etc/network/if-pre-up.d called iptables-restore-rules. In that file, insert this:

#!/bin/sh
iptables-restore < /etc/network/iptables-rules

The location of this script, ensures that it will be executed *prior to* the network interfaces coming up, therefore protecting us from the internet!

Wrap up

Now we have a basic Linux router which can serve IP addresses, route packets between interfaces, and has a basic level of firewalling from the internet. In the next post, we’ll do some more iptables stuff, and talk about OpenVPN and how we can use policy based routing to route some traffic through a VPN and some around it.
As always, thanks for reading!

The post Build Your Own Router – Part 2 appeared first on Jacob N Calvert.

• Why would you build a router to improve your privacy?
• What are the basic skills needed for building your own router?
• What hardware is needed?
• What software is needed?
• What does all this effort buy me?

I’ll address these questions and more as I walk through my approach to this ever-increasing issue of degrading privacy online.
So let’s get to it!

I see HTTPS on all the popular websites… that’s not private?

Well, sort of. Once your machine has established an HTTPS connection to say Facebook’s servers, the data between the two of you is encrypted. But, that Domain Name Server (DNS) request your computer made to find out Facebook’s IP address was not encrypted at all. The same goes for your bank, your pharmacy, your children’s school website, and more.
So, we want to improve our privacy by making our traffic less visible. How do we do that? A VPN of course!
Many people, especially those who work from home frequently, are already familiar with VPNs. You fire up your businesses VPN client, log in, and *BOOM*, it looks like you’re sitting in your office! There’s your shared network drives, the PLM tools work and so on. This technology can also be used to enhance your web privacy.
Let me explain.
You have a VPN provider, who has 500+ servers all around the world. When you connect to this VPN service, your traffic looks like it comes from one of those servers instead of your home ISP connection. Thousands of other users have traffic exiting from that node as well. Your traffic all mixed in with other traffic — it’d be really hard to track you based on that. Plus, you have the added benefit of being able to change exit nodes practically any time (that is, if your VPN provider allows.)

So great! I just need to run a VPN on my laptop when I want to more secure!

Well, sort of, again. We have one hole, and there may be more that I’m unaware of, which can leak your private IP address to the world when using a web browser. Check out the page here about WebRTC leaking your IP address. Even when you’re actively running a VPN client on your local machine, the protocol can ask, “Hey what’s your IP address?” and your machine will willingly hand it out. Mozilla Firefox will let you disable this feature altogether, but Chrome will not. There are tweaks you can make and plugins you can get, but we have a better solution!
Enter our hero: VPN at the router!! 
Rather than running your VPN client at the machine, running it at the router makes your machine completely oblivious to the fact that a tunnel is running at all.

So I need to buy a router that supports VPN clients?

Well, you could! But they could be expensive and it’s more fun (and educational!) to build it ourselves!
By home-making a router, we can accomplish many things, the least of which is the actual routing of our home network. Not only can we have stricter control over what (and who) comes in and out of our network, but we can also offer other services like local DNS caching, more DHCP options (like NetBoot or PXE), and last but certainly not least, a VPN client.

So now we know why we would like to build our own router, but what skills will I need?

At the very least, the person building their own router needs to understand the basics of the following items:

• IPv4 – the internet protocol
• Subnetworking
• DHCP
• DNS
• iptables

Not on the list but absolutely essential to this endeavor is a strong background in Linux (at the helm of the CLI). All the networking and services will be configured in and hosted on a Linux distro of your choosing.
I think this is enough for one post! Check back soon for part two! I’ll come back and link it here, and it will be up on the blog page!
Thanks for reading!

The post Build Your Own Router – Part 1 appeared first on Jacob N Calvert.