| 21 Nov 2025 |
|  isabel changed their profile picture. | 18:14:31 |
| 22 Nov 2025 |
|  raboof joined the room. | 12:54:10 |
| raboof | possibly not nixos-specific, but perhaps someone here recognizes this behaviour | 16:31:46 |
| raboof | I'm trying to configure a rpi to monitor the wlan and wired connections. both are on the same network (192.168.1.0/24). when both are enabled, I'm having a hard time using the wireless connection. For example, when I curl --interface enu1u1u1 http://2.18.244.76, tcpdump as expected goes:
17:27:41.606428 enu1u1u1 Out IP 192.168.1.101.45516 > 2.18.244.76.80: Flags [S], seq 3074758675, win 64240, options [mss 1460,sackOK,TS val 1422732498 ecr 0,nop,wscale 7], length 0
17:27:41.611238 enu1u1u1 In IP 2.18.244.76.80 > 192.168.1.101.45516: Flags [S.], seq 69448321, ack 3074758676, win 65160, options [mss 1452,sackOK,TS val 527341513 ecr 1422732498,nop,wscale 7], length 0
17:27:41.611400 enu1u1u1 Out IP 192.168.1.101.45516 > 2.18.244.76.80: Flags [.], ack 1, win 502, options [nop,nop,TS val 1422732503 ecr 527341513], length 0
17:27:41.611657 enu1u1u1 Out IP 192.168.1.101.45516 > 2.18.244.76.80: Flags [P.], seq 1:76, ack 1, win 502, options [nop,nop,TS val 1422732503 ecr 527341513], length 75: HTTP: GET / HTTP/1.1
17:27:41.616315 enu1u1u1 In IP 2.18.244.76.80 > 192.168.1.101.45516: Flags [.], ack 76, win 509, options [nop,nop,TS val 527341518 ecr 1422732503], length 0
17:27:41.632673 enu1u1u1 In IP 2.18.244.76.80 > 192.168.1.101.45516: Flags [FP.], seq 1:517, ack 76, win 509, options [nop,nop,TS val 527341518 ecr 1422732503], length 516: HTTP: HTTP/1.0 400 Bad Request
17:27:41.633322 enu1u1u1 Out IP 192.168.1.101.45516 > 2.18.244.76.80: Flags [F.], seq 76, ack 518, win 501, options [nop,nop,TS val 1422732524 ecr 527341518], length 0
| 16:33:08 |
| raboof | 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 (clat on linux when) | asymmetric pathing | 16:35:09 |
| hexa (clat on linux when) | disable rp_filter | 16:35:19 |
| raboof | 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 (clat on linux when) | hrm | 16:42:17 |
| hexa (clat on linux when) | so you receive synack but curl doesn't notice | 16:42:50 |
| hexa (clat on linux when) | oops, you said that | 16:43:15 |
| hexa (clat on linux when) | I would still expect this to be related to asymmetry | 16:43:57 |
| hexa (clat on linux when) | maybe check net.ipv4.conf.{all,wlan0}.rp_filter | 16:44:18 |
| hexa (clat on linux when) | * check net.ipv4.conf.{all,wlan0}.rp_filter as well | 16:44:29 |
| hexa (clat on linux when) | * check net.ipv4.conf.{all,wlan0}.rp\_filter as well | 16:44:35 |
| hexa (clat on linux when) | * check net.ipv4.conf.{all,wlan0}.rp_filter as well | 16:44:38 |
| hexa (clat on linux when) | because the packets arrive from a link that the system would not use for outgoing traffic towards that src address | 16:45:13 |
| raboof | yeah sysctl net.ipv4.conf | grep filter is all zero's | 16:45:33 |
| hexa (clat on linux when) | the term here is martian | 16:45:55 |
| hexa (clat on linux when) | I would probably put both links into a distinct vrf | 16:46:12 |
| hexa (clat on linux when) | 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 (clat on linux when) | * 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 (clat on linux when) | does the kernel still log martian packets to dmesg? 🤔 | 16:47:15 |
| raboof | not sure, dmesg is pretty quiet on this machine at least | 16:47:55 |
| raboof | ha, disabling networking.firewall.checkReversePath seems to have done the trick :). thanks for pointing in that general direction | 16:56:40 |
| hexa (clat on linux when) | yeah, same shit, different stack | 16:59:12 |
| raboof | 
Download out.png | 17:06:17 |
| raboof | yay | 17:06:20 |
| hexa (clat on linux when) | why aren't you buying into orb instead? https://orb.net/ | 17:37:02 |
| hexa (clat on linux when) | (anyway, I think they're a nice product to take inspiration from) | 17:37:33 |
