2023-08-07 22:43:12 +02:00
|
|
|
## Bridge module
|
2023-08-07 23:14:58 +02:00
|
|
|
## =============
|
2023-08-07 22:43:12 +02:00
|
|
|
##
|
|
|
|
## Allows creation of Layer 2 software "bridge" network devices. A
|
|
|
|
## common use case is to merge together a hardware Ethernet device
|
|
|
|
## with one or more WLANs so that several local devices appear to be
|
2023-08-19 00:58:06 +02:00
|
|
|
## on the same network.
|
2023-08-07 22:43:12 +02:00
|
|
|
|
|
|
|
|
2023-07-20 12:46:19 +02:00
|
|
|
{ lib, pkgs, config, ...}:
|
|
|
|
let
|
|
|
|
inherit (lib) mkOption types;
|
|
|
|
inherit (pkgs.liminix.services) oneshot;
|
2023-08-05 15:08:02 +02:00
|
|
|
inherit (pkgs) liminix;
|
2023-07-20 12:46:19 +02:00
|
|
|
in
|
|
|
|
{
|
2024-03-16 21:41:13 +01:00
|
|
|
imports = [ ../ifwait ];
|
|
|
|
|
2023-07-20 12:46:19 +02:00
|
|
|
options = {
|
2023-08-28 00:45:27 +02:00
|
|
|
system.service.bridge = {
|
|
|
|
primary = mkOption { type = liminix.lib.types.serviceDefn; };
|
|
|
|
members = mkOption { type = liminix.lib.types.serviceDefn; };
|
fix(bridge): reorder initialization for bridge dependents
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>
2024-09-01 15:42:26 +02:00
|
|
|
ready = mkOption { type = liminix.lib.types.serviceDefn; };
|
2023-07-20 12:46:19 +02:00
|
|
|
};
|
|
|
|
};
|
2023-08-28 00:45:27 +02:00
|
|
|
config.system.service.bridge = {
|
|
|
|
primary = liminix.callService ./primary.nix {
|
2023-08-16 20:44:00 +02:00
|
|
|
ifname = mkOption {
|
|
|
|
type = types.str;
|
|
|
|
description = "bridge interface name to create";
|
2023-08-05 15:08:02 +02:00
|
|
|
};
|
2024-09-01 14:56:08 +02:00
|
|
|
|
|
|
|
macAddressFromInterface = mkOption {
|
|
|
|
type = types.nullOr liminix.lib.types.service;
|
|
|
|
default = null;
|
|
|
|
description = "reuse mac address from an existing interface service";
|
|
|
|
};
|
2023-08-05 15:08:02 +02:00
|
|
|
};
|
2024-03-16 21:41:13 +01:00
|
|
|
members = config.system.callService ./members.nix {
|
2023-08-28 00:45:27 +02:00
|
|
|
primary = mkOption {
|
|
|
|
type = liminix.lib.types.interface;
|
|
|
|
description = "primary bridge interface";
|
|
|
|
};
|
|
|
|
|
|
|
|
members = mkOption {
|
|
|
|
type = types.listOf liminix.lib.types.interface;
|
|
|
|
description = "interfaces to add to the bridge";
|
|
|
|
};
|
|
|
|
};
|
fix(bridge): reorder initialization for bridge dependents
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>
2024-09-01 15:42:26 +02:00
|
|
|
|
|
|
|
# TODO: generalize it outside
|
|
|
|
ready = config.system.callService ./ready.nix {
|
|
|
|
primary = mkOption {
|
|
|
|
type = liminix.lib.types.service;
|
|
|
|
description = "primary bridge interface";
|
|
|
|
};
|
|
|
|
|
|
|
|
members = mkOption {
|
|
|
|
type = liminix.lib.types.service;
|
|
|
|
description = "members service";
|
|
|
|
};
|
|
|
|
};
|
2023-07-20 12:46:19 +02:00
|
|
|
};
|
2023-08-30 18:29:42 +02:00
|
|
|
config.kernel.config = {
|
|
|
|
BRIDGE = "y";
|
|
|
|
BRIDGE_IGMP_SNOOPING = "y";
|
2023-08-31 19:24:09 +02:00
|
|
|
} // lib.optionalAttrs (config.system.service ? vlan) {
|
|
|
|
# depends on bridge _and_ vlan. I would like there to be
|
|
|
|
# a better way to test for the existence of vlan config:
|
|
|
|
# maybe the module should set an `enabled` attribute?
|
|
|
|
BRIDGE_VLAN_FILTERING = "y";
|
2024-03-16 21:41:13 +01:00
|
|
|
};
|
2023-07-20 12:46:19 +02:00
|
|
|
}
|