1bd9af1e9d
Consider the scenario where you run DHCPv4 on the primary bridge interface. You have no real interface to "wait upon", so it's OK. Nonetheless, anything depending on successful completion of DHCPv4, e.g. adding a default route, will block `s6-rc -v2 up change default`. The way new interfaces are attached to the bridge is via `s6-rc -b -u change $attach-oneshot-service`, this introduce in turn a deadlock. At some point, DHCPv4 will timeout, unblocking the deadlock and attaching the members to the primary bridge interface, making it ready to send L2 broadcast packets for DHCP, unblocking DHCP in turn again. This is not satisfying because we really want to have a no-hiccups bring-up. To fix this, we proceed to multiple changes: - we remove `svc.ifwait.build` out of band `s6-rc -b -u $oneshot-attach` call, which is, by design, wrong here. - users can now depend on the members service to know when a bridge is fully operational (we could make it more granular and let them depend on the LAN member joining rather than WLAN, etc.) - users can also depend on the primary service being brought up rather than just being present, this is useful if you need to bring it up when it has AT LEAST one member to get link local address or MAC addresses (fixing DHCPv6 bring up as well because `ff02::1` is used there). One thing is not addressed yet, if you are running a WLAN service using RADIUS attached to the bridge, at bring up time, it will try to reach out the external RADIUS server and *fail*. To solve this, granular dependency on the DHCPv4 once LAN is joined. Then the hostapd can wait on defaultroute4 completion so that connectivity is available to reach RADIUS server. It can join the bridge later on without any hiccup as well. This is left as a TODO as hostapd can survive RADIUS authentication failure and retry later. Signed-off-by: Raito Bezarius <masterancpp@gmail.com> |
||
|---|---|---|
| .forgejo/workflows | ||
| devices | ||
| doc | ||
| examples | ||
| lib | ||
| modules | ||
| pkgs | ||
| tests | ||
| .gitignore | ||
| bordervm-configuration.nix | ||
| bordervm.conf-example.nix | ||
| ci.nix | ||
| CODE-OF-CONDUCT.md | ||
| CONTRIBUTING.md | ||
| default.nix | ||
| LICENSE | ||
| nat.nft | ||
| NEWS | ||
| overlay.nix | ||
| README.md | ||
| shell.nix | ||
| STYLE.md | ||
| THOUGHTS.txt | ||
| vanilla-configuration.nix | ||
Liminix
A Nix-based system for configuring consumer wifi routers or IoT device devices, of the kind that OpenWrt or DD-WRT or Gargoyle or Tomato run on. It's a reboot/restart/rewrite of NixWRT.
This is not NixOS-on-your-router: it's aimed at devices that are underpowered for the full NixOS experience. It uses busybox tools, musl instead of GNU libc, and s6-rc instead of systemd.
The Liminix name comes from Liminis, in Latin the genitive declension of "limen", or "of the threshold". Your router stands at the threshold of your (online) home and everything you send to/receive from the outside word goes across it.
Current status (does it work yet?)
Liminix is pre-1.0. We are still finding new and better ways to do things, and there is no attempt to maintain backward compatibility with the old ways.
The NEWS file (available wherever you found this README) is a high-level overview of breaking changes.
Development mostly happens on the main branch, which is therefore
not guaranteed to build or to work on every commit. For the latest
functioning version, see the CI system and pick a revision with all jobs green.
Documentation
Documentation is in the doc directory. You can build it by running
nix-shell -p sphinx --run "make -C doc hardware.rst html"
Rendered documentation corresponding to the latest commit on main
is published to https://www.liminix.org/doc/
Extremely online
There is a #liminix IRC channel on the OFTC
network in which you are welcome. You can also connect with a Matrix
client by joining the room #_oftc_#liminix:matrix.org.
In the IRC channel, as in all Liminix project venues, please conduct yourself according to the Liminix Code of Conduct.