Konsulko Group
  • Home
  • Software
    • Edge AI
      • Edge AI Services
      • Konsulko Orca OS
    • Embedded Linux
    • Yocto Project
    • Security
    • Software Update
    • Automotive
    • RTOS and Bare Metal
  • Hardware
    • Electronics Design
    • Sensor Integration
    • Low Power
    • Wireless Communication
    • System Architecture
    • Manufacturing
  • Industries
    • Healthcare
    • Industrial and Heavy Equipment
    • Telecommunications Industry
    • Transportation Industry
  • About
    • Meet the Team
    • Careers
    • Resources
      • Embedded Systems Design
  • Showcase
  • Contact
  • Blogs & News
    • Technical Blog
    • News
  • Click to open the search input field Click to open the search input field Search
  • Menu Menu
Building a DIY SOHO router SIX MONTHS ON

Building a DIY SOHO router, 6 months on

October 28, 2019/by Tom Rini

Building a DIY SOHO router using the Yocto Project build system OpenEmbedded, 6 months on

A little more than six months ago, I posted part 4 of our series on making a SOHO router using the Yocto Project and OpenEmbedded. After 6 months of deployment, this is a good time to follow up on how the router has worked out in residential use.  The zeus code-name Yocto Project release was just announced, and that means that the release we started out with in part 1 is now close to being out of support.  That’s not a problem since we designed in support for moving to new software releases using Mender to deliver software updates.

One of the most important metrics in a project like this is, how does it perform?  From the standpoint of a family of 4 heavy internet users, it’s gone really well.  The WiFi range is only a little better than before, but that’s not really a function of the software.  Making everyone use Pi-hole has only resulted in a small number of places where I needed to override the blacklist and allow something in.  From an end-user point of view, this has worked as well as any off-the-shelf router.  From the administrator point of view, I’ve done scheduled maintenance during the day on a weekend, and it really did take only the 5 minutes I promised everyone rather than turning into one of those worst case scenarios where something broke and it takes an hour to fix it.  In fact, the update portion of the plan has gone exceedingly well.  While I didn’t make a post about moving to warrior from thud, I did that transition a while ago and it went smoothly.  Mender introduced a change that required attention be paid while migrating, but it was documented and went smoothly.  On the metadata side, the upgrade was as easy as one could hope.  A few of the bbappend files needed to be updated for a new version, and some of the changes I had made and pushed upstream as part of the original series were now just included, so they got dropped from my layer.

One of the things I touched on in the series was about using the update functionality to test development changes in a production environment.  The chance to do that came up with a systemd-networkd issue that was a problem in my local setup.  The upstream project requested people verify the problem exists with newer versions of systemd and a new enough version was available in what would become zeus.  So I made a quick weekend project of doing an update of my layers to build with a newer version of all of the metadata, removed the work-around, and flashed the image in place.  A quick reboot confirmed that the issue was indeed fixed, and then rather than commit to running an otherwise in-progress release I simply rebooted and automatically rolled back to my stable release.  With the network back up again, I updated the issue in upstream Bugzilla to let them know the problem was fixed.  After a bit longer, a few other people also confirmed it worked for them and now the issue is resolved.

In terms of the metadata itself, there have been a few clean-ups to what I did in my own layer with each release update I’ve done.  In the series I left out what hardware I was building on, and I also left out talking about using the linux–yocto recipe.  Since I first wrote the series linux-yocto has become easier to use, and I found this as part of reviewing my own changes like they were brand new with each upgrade.  I was setting some variables that initially didn’t have reasonable default values, and now they do and I don’t need to set them myself.  This in fact means that moving forward, rather than a version-specific kernel bbappend file, I can go with an always-used one to enable the additional kernel CONFIG options that I need for a time-based firewall.

I started out by mentioning that zeus has been released, and I’m working on migrating to it as I write this.  In fact, it’s so new that I’m doing my own little port of the meta-mender core layer to zeus for my needs. I expect that by the time I do my first update from one build of zeus to the next there will be an official update I’ll be able to use instead.  Looking forward, this was a great little project that also was a lot of fun.  The goals I set way back at the start have been met, and I’m happier with my network than I have been in a long time.  Of course, the list of features an off-the-shelf system provides is always growing, and there’s now monitoring and display items on my weekend project list now to keep up.  I foresee using and improving this setup for a long time to come.

author avatar
Tom Rini VP of Engineering
Tom has over 25 years experience in developing different parts of the Linux ecosystem, with the majority of that time focusing on embedded systems. He was an early PowerPC Linux developer, focusing on the area of handoff between firmware and kernel. He has been a key developer in the OpenEmbedded and Yocto projects, spending time on the OpenEmbedded Technical Steering Committee. He was a technical leader at MontaVista, Mentor Graphics, and Texas Instruments as well as playing key roles in the Embedded Alley Solutions team. Tom is currently the head custodian of Das U-Boot, a popular open source firmware.
See Full Bio

Related posts:

  1. Building a DIY SOHO router, 18 months later
  2. Custom Linux Distro for NVIDIA CUDA Devices
  3. Helping Yocto Project work with Python 3
  4. Migrating from Windows CE to Yocto-based Embedded Linux
Share this entry
  • Share on Facebook
  • Share on X
  • Share on WhatsApp
  • Share on Pinterest
  • Share on LinkedIn
  • Share on Tumblr
  • Share on Vk
  • Share on Reddit
  • Share by Mail

Recent Posts

  • Konsulko Group extends Edge AI practice on Jetson, joins NPN
  • Konsulko Group: The Year in Review 2025
  • Introducing Konsulko Orca OS, the Platform for the Edge
  • Cybersecurity on NVIDIA: Why Embedded Lags Enterprise Linux
  • Integration and troubleshooting: Sterling LWB+ radio module
Konsulko Logo

Helping companies around the world develop successful products, offering consulting, product engineering, support and capability building at every stage of the engagement.

Connect with us

Software

  • Edge AI
  • Konsulko Orca OS
  • Embedded Linux
  • Yocto Project
  • Security
  • Software Update
  • Automotive
  • RTOS and Bare Metal

Hardware

  • Electronics Design
  • Sensor Integration
  • Low Power
  • Wireless Communication
  • System Architecture
  • Manufacturing

Information Hub

  • Technical Blog
  • Company News
  • Press Releases
  • Showcase

Company

  • About Us
  • Contact Us
  • Meet the Team
  • Careers
© 2012-2026, Konsulko Group. All Rights Reserved
  • Privacy Policy
  • Cookie Settings
Link to: Konsulko Group sponsors OpenFest 2019 Link to: Konsulko Group sponsors OpenFest 2019 Konsulko Group sponsors OpenFest 2019OPEN FEST Link to: Hope to see you at the AGL booth at CES Link to: Hope to see you at the AGL booth at CES CES2020Hope to see you at the AGL booth at CES
Scroll to top Scroll to top Scroll to top