So I just got the email that my project proposal was accepted into the creator contest thing, and a mainboard for me to dev on is coming soon. Therefore, I wanted to start this thread to outline the project, its goals, list needed parts, solicit feedback and ideas, etc. And to reserve space for the final how-to writeup once it is done.
Thanks to Framework for helping to make this project happen years earlier than it would if I had to wait to upgrade my laptop’s mainboard first!
PROJECT RATIONALE: Commercially available consumer grade routers kind of suck. Much like traditional laptops, they are not reasily upgradeable, repairable, etc. All in one board combos of SOC, wifi radios, and nvram flash memory means for most users that a failure in one part, or a significant wifi standards upgrade comes out, or a security issue in the firmware of an old abandoned model is discovered, then the whole unit needs replaced at significant cost. Whereas, many Framework users will have upgraded their mainboards in the coming years, and will need something useful to do with the older (but perfectly capable of this task) mainboard.
CREATOR CONTEXT: I have a Netgear R7000P main router (Wifi 5 only) + an R7000 as a secondary AP ( both running the third party DD-WRT open source firmware ) + a separate Raspberry Pi functioning as NAS. I have done long range wifi projects to cover an entire 40 acre site, as well as create a broadband between link two sites nearly a mile apart with custom and off the shelf hardware buildups. While it is great to have DD-WRT on the routers as an option, there are some features that just are not coming to my routers, due to chip level and proprietary firmware blob limitations. WPA3 is the most glaring example of tech that I cannot get without a hardware upgrade. Also, the pre-compiled packages available in opkg are often out of date, compiled with odd options and strange incompatibilities, or sometimes badly feature crippled in the ARM environment. I have used Raspberry Pi’s of various generations to create ad hoc hotspots and aviation ADS-B receivers, so I am somewhat familiar with the hardware and driver requirements for getting this working with modern linux kernels. I have also done proof of concept USB wireless dongle APs connected to my current Framework laptop that passed packets to a wider LAN/WAN connection.
PROPOSED SOLUTION: Use a Framework mainboard and its associated well-supported CPU as the primary wired and wireless router for a small home or office network, complete with most of the necessary things from a commercially available consumer grade router. The goal will not be to make the highest performance router ever, but to develop recipes for maximal re-use of current gen (aka soon to be last gen) components that would likely be upgraded alongside a main board upgrade, with minimal new purchases.
The critical list of functions that the router and AP should handle elegantly include:
- WAN static IP, DHCP client, etc
- OpenVPN and/or WireGuard server
- OpenVPN and/or WireGuard client
- USB ethernet ports (at least 1, demonstrated 2-8 working in as a network bridge would be better)
- USB connected wifi dongles with infrastructure AP mode (at least 1, 2+ working in network bridge would be better)
- Bootable storage
- External storage
- SSH access for setup and control of the router
- DNS, with support for local domain / hostname list
- DHCP, with dynamic update of local DNS entries
- NAS for external storage with important protocols, such as CIFS (aka samba) and SFTP, allowing for general file backup and easily connecting modern media players such as Kodi
- 3d printable case design with sufficient room off of each side to host a reasonable amount of USB peripherals, optional cooling fans, etc
- NVM.e AX210 6E card working in AP mode (as a use for old Framework supplied cards)
- Parameterized OpenSCAD model file for the case design
- Federated network storage protocols such as DRBD, UnionFS, and/or similar
- ~25m long powered USB extension cable sets to spread out AP dongles and/or antennas
- IP or MAC based device sandboxing (denial of WAN access) on a permanent or scheduled basis
- Guest networks with access to WAN but not LAN
- Minimizing total power consumption, no fan necessary for normal routing loading, etc.
- Small touchscreen for display of system stats, “nice” reboots, etc.
METHOD: I plan to use arch linux, DE-less install, as the base for my recipe. Part of this is go with what you know, but I also firmly believe this is the best starting point for this use case. I will be implementing one feature at a time until I reach full functionality of the necessary features, then using it as my main home router after that.
PARTS USED IN THIS PROJECT:
- USB-PD power supply: I went with one from AliExpress, as I have the same one in service already and know it works with a (battery) Framework (battery less operation TBD) https://m.aliexpress.com/item/1005004237402278.html , USD$28
- USB 100w 2m type C to type C cable, https://m.aliexpress.com/item/1005003702052888.html , USD$7
- USB-C to USB-A 3.1 hubs, possibly multiple
- USB wired ethernet dongle(s)
- USB wifi dongle(s) with AP mode capability and appropriate linux driver, preferably capable of WPA3 and/or Wifi 6 at a minimum
- NVM.e SSD for onboard bootable storage : SK Hynix used PCIe 128GB SSD 2230 (yes I know the Mainboard wants 2280, but this was cheaper so I’ll fab a heatsink + adapter piece) from eBay, USD$17
- RAM module: 1x 4GB SK Hynix 260 pin SODIMM DDR4-3200, SK Hynix 4GB/2x4GB DDR4 3200 Laptop 260-Pin SODIMM 260-pin Laptop Memory RAM | eBay , USD$16
- NVM.e 2230 AX210 card from Framework Marketplace, USD$19
- Wifi antennas for AX210 from Framework Marketplace USD$14
- USB power meter: https://m.aliexpress.com/item/32854809579.html , USD$12
- USB Touchscreen
- External USB hard drives or SSD enclosures
- USB is not exactly the best connection method for devices that want to be low latency like network cards and wifi dongles, especially multiple devices on the same bus
- USB wifi dongles sometimes consume unreasonable amounts of wattage vs the ERP they put out
- Intel support for AX210 in general, proprietary blob firmware in Linux, but especially over-conservative interpretation of regulatory domains for AP mode. Research in progress on this.
- Purchase required items
- Receive mainboard
- Verify batteryless operation and USB-PD power supply operation, explore TDP and pass through power limits
- Stand up USB to wired internet peripherals
- Stand up USB to wireless AP internet peripherals
- Install and configure equivalent NAS
- Install and test firewall
- Move this into primary position on my home network
- Work on optional features one at a time
- Party like its 1999.
I welcome all of your input, feature request additions, best practice idea documents, etc.!