!tCyGickeVqkHsYjWnh:nixos.org

NixOS Networking

915 Members
Declaratively manage your switching, routing, wireless, tunneling and more.268 Servers

Load older messages

SenderMessageTime
22 Nov 2025
@raboof:matrix.orgraboof

however, when I curl --interface wlan0 http://2.18.244.76:

17:27:54.743874 wlan0 Out IP 192.168.1.212.42430 > 2.18.244.76.80: Flags [S], seq 2483937156, win 64240, options [mss 1460,sackOK,TS val 227351562 ecr 0,nop,wscale 7], length 0
17:27:54.754041 wlan0 In  IP 2.18.244.76.80 > 192.168.1.212.42430: Flags [S.], seq 1128095182, ack 2483937157, win 65160, options [mss 1452,sackOK,TS val 527354654 ecr 227351562,nop,wscale 7], length 0
17:27:54.761158 wlan0 In  IP 2.18.244.76.80 > 192.168.1.212.42430: Flags [S.], seq 1128095182, ack 2483937157, win 65160, options [mss 1452,sackOK,TS val 527354662 ecr 227351562,nop,wscale 7], length 0
17:27:56.787444 wlan0 In  IP 2.18.244.76.80 > 192.168.1.212.42430: Flags [S.], seq 1128095182, ack 2483937157, win 65160, options [mss 1452,sackOK,TS val 527356685 ecr 227351562,nop,wscale 7], length 0
17:28:00.933524 wlan0 In  IP 2.18.244.76.80 > 192.168.1.212.42430: Flags [S.], seq 1128095182, ack 2483937157, win 65160, options [mss 1452,sackOK,TS val 527360717 ecr 227351562,nop,wscale 7], length 0
17:28:09.330484 wlan0 In  IP 2.18.244.76.80 > 192.168.1.212.42430: Flags [S.], seq 1128095182, ack 2483937157, win 65160, options [mss 1452,sackOK,TS val 527369228 ecr 227351562,nop,wscale 7], length 0

it seems somehow the SYNACK does arrive at the network interface, but doesn't make it to curl? what could explain that?

16:33:58
@hexa:lossy.networkhexaasymmetric pathing16:35:09
@hexa:lossy.networkhexadisable rp_filter16:35:19
@raboof:matrix.orgraboof hmm just set sysctl net.ipv4.conf.default.rp_filter to 0 (and also for the specific interfaces) but don't see a change in behavior yet 16:41:06
@hexa:lossy.networkhexahrm16:42:17
@hexa:lossy.networkhexaso you receive synack but curl doesn't notice16:42:50
@hexa:lossy.networkhexaoops, you said that16:43:15
@hexa:lossy.networkhexaI would still expect this to be related to asymmetry16:43:57
@hexa:lossy.networkhexamaybe check net.ipv4.conf.{all,wlan0}.rp_filter16:44:18
@hexa:lossy.networkhexa * check net.ipv4.conf.{all,wlan0}.rp_filter as well 16:44:29
@hexa:lossy.networkhexa * check net.ipv4.conf.{all,wlan0}.rp\_filter as well 16:44:35
@hexa:lossy.networkhexa * check net.ipv4.conf.{all,wlan0}.rp_filter as well 16:44:38
@hexa:lossy.networkhexabecause the packets arrive from a link that the system would not use for outgoing traffic towards that src address16:45:13
@raboof:matrix.orgraboof yeah sysctl net.ipv4.conf | grep filter is all zero's 16:45:33
@hexa:lossy.networkhexathe term here is martian16:45:55
@hexa:lossy.networkhexaI would probably put both links into a distinct vrf16:46:12
@hexa:lossy.networkhexa because when you ping 192.168.1.212 hat happens is that a lookup for the return path might short-circuit and go over the ethernet link 16:46:50
@hexa:lossy.networkhexa * because when you ping 192.168.1.212 what happens is that a lookup for the return path might short-circuit and go over the ethernet link 16:47:00
@hexa:lossy.networkhexadoes the kernel still log martian packets to dmesg? 🤔16:47:15
@raboof:matrix.orgraboofnot sure, dmesg is pretty quiet on this machine at least16:47:55
@raboof:matrix.orgraboof ha, disabling networking.firewall.checkReversePath seems to have done the trick :). thanks for pointing in that general direction 16:56:40
@hexa:lossy.networkhexayeah, same shit, different stack16:59:12
@raboof:matrix.orgraboofout.png
Download out.png		17:06:17
@raboof:matrix.orgraboofyay17:06:20
@hexa:lossy.networkhexa why aren't you buying into orb instead? https://orb.net/ 17:37:02
@hexa:lossy.networkhexa(anyway, I think they're a nice product to take inspiration from)17:37:33
@raboof:matrix.orgraboofNeat, never seen it before. Yeah I thought "I'll just throw something together real fast". A blackbox-exporter patch, autossh conflicting with nixos-rebuilder-ng and this rp thing later it didn't quite turn out like that, but still enjoying the learning 😊18:40:48
@elisaado:matrix.orgelisaadothe topic mentions "do not rely on networking.*", why is that? networking. options are so comfy :(23:02:45
@tom:dragar.deTomFrom my understanding: networking.* (without the networking.useNetworkd Option which is problematic in itself) is a bunch of scripts and systemd services which try to configure networking. It's just not the way to do it and networkd and networkmanager will be more robust.23:27:26
@hexa:lossy.networkhexanobody really maintains those scripts23:28:51

Show newer messages

Back to Room ListRoom Version: 6