| 15 Jan 2026 |
 kdn | did it last year and I barely remember what is what now xD | 14:39:32 |
 elisaado | I'm aiming to replace VyOS in my stack, because well, VyOS | 14:41:08 |
| elisaado | is using the networking.* fine if you set networking.useNetworkd = true;, or does it still use legacy/bespoke bash scripts? | 14:45:41 |
| elisaado | oh I should have read the description | 14:46:01 |
 K900 | Depends on which options you use | 14:46:06 |
| elisaado | for future reference, "Whether we should use networkd as the network configuration backend or the legacy script based system. Note that this option is experimental, enable at your own risk." | 14:46:09 |
| K900 | But also honestly just don't | 14:46:10 |
| K900 | The mapping to networkd is not entirely obvious | 14:46:16 |
| K900 | And you probably don't want to have two sets of semantics in your head | 14:46:27 |
| K900 | It's a migration aid | 14:46:33 |
| elisaado | fair | 14:46:35 |
 adamcstephens | i agree. just use networkd native options. | 15:09:29 |
| adamcstephens | especially for something like a router | 15:09:42 |
 hexa | last time I checked the mapping was also incomplete and you don't get any feedback for things that won't get applied | 15:13:14 |
| 16 Jan 2026 |
|  Marcel joined the room. | 00:52:37 |
| adamcstephens | huh, openvswitch can be configured to drop privileges to a non-root user. yet our very barebones module does not do so | 02:48:50 |
| 17 Jan 2026 |
|  @marcel:envs.net changed their display name from Marcel to Marcel (@). | 23:44:12 |
| @marcel:envs.net changed their display name from Marcel (@) to Marcel => @me:m4rc3l.de. | 23:44:56 |
| 18 Jan 2026 |
|  magic_rb joined the room. | 13:00:53 |
| magic_rb | hi, im here from a different account cause my HS is down | 13:01:22 |
| magic_rb | im seeing a very weird issue with wireguard, my network topology is server -- managed l3 switch -- banana pi r4 -- pppoe -- internet. for some reason if the pppoe link drops then wireguard cant reach my VPS on the internet. The packets from the VPS arrive to my server, but then my server's responses get lost to the void | 13:02:57 |
| magic_rb | ive ran tcpdump and nft monitor trace confirming that my server does send out the packets, yet my banana pi r4 doesn't see them... | 13:03:31 |
| magic_rb | on my server i see
12:58:44.828966 00:25:90:85:56:3e > 2e:2c:64:a9:08:37, ethertype IPv4 (0x0800), length 134: (tos 0x88, ttl 64, id 5539, offset 0, flags [none], proto UDP (17), length 120)
192.168.11.21.6666 > 167.235.230.162.6666: [bad udp cksum 0x5ac1 -> 0x97d9!] UDP, length 92
but no such packet can be seen on my banana pi. I do see other packets from the same server, same port, same wireguard, toward different devices (both LAN and WAN), but this specific 192.168.11.21.6666 > 167.235.230.162.6666 packet is lost to the void somewhere between by server and banana pi
| 13:04:46 |
| magic_rb | i can also ping my VPS no problem, so it seems like the specific UDP state table entry is fucked somehow? | 13:06:17 |
| magic_rb | if i restart wireguard or unplug the ethernet from my server, experience tells me itll fix itself | 13:06:36 |
| magic_rb | 13:08:34.419753 00:25:90:85:56:3e > 2e:2c:64:a9:08:37, ethertype IPv4 (0x0800), length 92: (tos 0x0, ttl 64, id 50063, offset 0, flags [DF], proto UDP (17), length 78)
192.168.11.21.52425 > 167.235.230.162.6666: [bad udp cksum 0x5a97 -> 0x9609!] UDP, length 50
that packet done using netcat appears on banana pi r4
| 13:08:59 |
| magic_rb | ive had this issue before, its always when the pppoe link drops on my banana pi. I do not understand how that can cause the state tables on my server to get mangled | 13:09:54 |
| magic_rb | any suggestions for further debugging? | 13:14:41 |
| magic_rb | only further thing i can think of is taking a laptop, putting it inbetween the router and the switch and sniffing | 13:16:51 |
 magic_rb | fuck it fixed itself while i was trying to do the laptop thing | 13:32:33 |
