I won't say it's done, because it's not done. But, I can see the end from here

#nixwrt running on real hardware getting real internet traffic from a real ISP and routing to a local network

#diff-b2672dbec125801aecf42552931f00442ad5aa8d71ef085fd16e39c509573874L3" rel="nofollow">https://github.com/telent/nixwrt/commit/e0217999f6fde51698f66ef48dd83d67a4544e16#diff-b2672dbec125801aecf42552931f00442ad5aa8d71ef085fd16e39c509573874L3

#nixwrt on qemu is sending dhcp and all the gubbins to a second qemu process that I booted using a System-Rescue iso image.

This is probably an achievement. I say "probably" because I can't actually see the output from the system-rescue vm because it doesn't work properly with -serial stdio. But the packets are flowing ...

Nov 21 17:56:45 dnsmasq-dhcp[120]: 13935373 client MAC address: 52:54:00:12:34:56

Nov 21 17:56:45 dnsmasq-dhcp[120]: 13935373 client provides name: sysrescue

Nov 21 17:56:45 dnsmasq-dhcp[120]: 13935373 DHCPSOLICIT(eth1) 00:04:dc:c5:43:08:80:09:95:31:b5:c5:75:68:d8:5f:2e:2e

Nov 21 17:56:45 dnsmasq-dhcp[120]: 13935373 DHCPREPLY(eth1) 2001:8b0:de3a:40dc::f0dc

00:04:dc:c5:43:08:80:09:95:31:b5:c5:75:68:d8:5f:2e:2e sysrescue

Did a giant #nixwrt WIP commit, because I have now changed so many things at once I have given up on the prospect of it making any sense in my head.

But it's on a branch. When I get to the end of this journey (l2tp connection to my ISP and all the IPv6 prefix faff) I will ... probably print the diff and use four colours of magic marker to decide which bits to commit in what order to create some meaningful narrative

https://github.com/telent/nixwrt/compare/services-wip don't look

Comparing main...services-wip · telent/nixwrt

Build images for embedded MIPS SoCs using NixPkgs (experimental) -...


it is possible that NixWRT is doing a lot more compilation than it needs to (even given that there is no MIPS binary cache) because of I-didn't-understand-how-overlays-work when I wrote the overlay for it.

For example, where I wrote coreutils = super.coreutils.overrideAttrs (o: { doCheck = false } ) that changes the build system coreutils as well as the mips coreutils, so everything x86-64 that depends on coreutils is getting built from source instead of pulled from cache.

Leastways, that's how I now think it works. ICBW this time too

#nixpkgs #nixwrt

I am extremely happy that after far too long fighting build systems, I have managed to make #nixwrt compile the 80211 subsystem and ralink wifi drivers from linux 5.8.something via the linux-backports project, and the resulting modules do actually load into the 5.4.64 kernel on the target device

I resorted to turning config options on and off randomly at a few points - there is plenty of cleanup yet to do before this can be merged into main


Upgrade to kernel v5.4 by telent · Pull Request #12 · telent/nixwrt

WIP: I am rearranging the kernel significantly. The plan is split...


Well, I have a #nixwrt kernel build that boots and finds its root fs and console device - and perhaps even its ethernet device (dmesg checks out, haven't tried to actually test) so this would be a good time to push some changes upstream


Upgrade to kernel v5.4 by telent · Pull Request #12 · telent/nixwrt

WIP: I am rearranging the kernel significantly. The plan is split...


Linux version 5.4.64 (nixbld@nixwrt.builder) (gcc version 9.3.0 (GCC)) <a href="https://terse.telent.net/tags/1" class="mention hashtag" rel="tag">#<span>1</span></a> Tue Sep 15 13:33:49 UTC 2020

Pausing here for a brief "woohoo!"

It doesn't mount the root fs yet, maybe (it suddenly occurs to me literally as I write this toot) because I forgot to build the phram target. And then the next big task is to build wireless modules from linux-backports. And maybe, y'know, actually commit some stuff to git?

#nixwrt #mips #nixpkgs #WhoSaysSentencesCantStartWithConjunctions

TFW when you set out to benchmark something you've previously observed is inexplicably slow, and ... it's no slower than the other thing you're comparing it against

#nixwrt wireless performance on this gl-mt300a (MediaTek MT7620A SoC) is about ~ 14Mb/s according to iperf3, which is probably slower than I should expect but is on par with the 2.4GHz network on the gl-ar750 downstairs running the vendor's OpenWRT

  • The LZMA decompression code in u-boot doesn't understand the LZMA compression performed by xz, so to get #nixwrt to generate images that work I have to build the "legacy" lzma (from 2008). Upgrading nixpkgs caused its buiild to fail with "RPATH ... contains a forbidden reference to /build"

  • so I worked around that by configureFlags = [ "--enable-static" "--disable-shared"]

  • now it is building gcc again. Guess I must have changed something else fundamental ...


I'm not saying it works, because it doesn't, but my ath10k wireless at least appears now to exist in #nixwrt. This is progress and it makes me happy





carrier phy80211 phys_switch_id carrier_up_count uevent name_assign_type queues gro_flush_timeout address carrier_changes dev_port device ifindex tx_queue_len duplex statistics wireless type power flags dev_id addr_assign_type phys_port_id addr_len carrier_down_count speed link_mode netdev_group phys_port_name broadcast subsystem iflink operstate dormant ifalias proto_down mtu ```