| 5 Jun 2025 |
 emily | AIUI the Realtek chip that OpenWrt does can actually be operated by an external CPU | 15:30:52 |
| emily | as in it can be a SoC with a MIPS processor, but it can also just be a "dumb" switch that you have an ARM chip talking to or something. | 15:31:05 |
| emily | I believe that nobody has implemented support for that in OpenWrt/mainline, but if there's a MikroTik thing with an AArch64 CPU and that Realtek chip it could be interesting… | 15:31:29 |
|  @tioan:dunwyn.xyz left the room. | 19:01:58 |
| 6 Jun 2025 |
 uep | rtl8367 seems to be the only realtek one they use recently | 01:45:32 |
| uep | there are some qualcomm (arm) and mediatek (mmips) ones with soc and small switch on the same chip | 01:46:23 |
| uep | everything that's a serious switch is marvell | 01:46:58 |
 hexa | (within the openwrt ecosystem) | 01:48:15 |
| emily | how can I find these things? when I go to https://toh.openwrt.org/?view=network and sort by SFP+s, very little shows up. I've seen that other listings don't have stuff in that field but searching SFP in the net comments also doesn't turn up much | 13:24:59 |
| emily | I'm interested in everything OpenWrt can run that has more than a handful of 10 Gbit/s SFP+ | 13:25:21 |
| emily | https://openwrt.org/docs/techref/hardware/soc/soc.marvell mostly talks about GbE (I guess the page seems fairly old) | 13:26:09 |
| emily | so far I haven't been able to find clear records of OpenWrt support for anything between the XikeStor with the Realtek chip (8× SFP+) and the Mellanox monsters (a billion × QSFP) | 13:27:36 |
| emily | which I'm sure is a failure of my own searching, but you seem to know more about this than me, so… :) | 13:27:47 |
|  twiceTubular joined the room. | 19:13:37 |
| uep | Err, I was responding about mikrotik when I said "they", sorry that wasn't clear. | 23:41:33 |
| 7 Jun 2025 |
| hexa | netdev 0x19 videos are up https://netdevconf.info/0x19/pages/sessions.html | 00:20:52 |
|  @deeok:matrix.org changed their display name from deeok to matrixrooms.info mod bot (does NOT read/send messages and/or invites; used for checking reported rooms). | 22:30:12 |
| 8 Jun 2025 |
| @deeok:matrix.org left the room. | 00:03:48 |
|  sacrificial-anode joined the room. | 02:17:17 |
|  Michael joined the room. | 15:04:21 |
 K900 | @emily did your 320mhz change get merged | 17:45:59 |
| emily | no response yet | 18:59:08 |
| emily | it was only for GB though | 18:59:14 |
| emily | not sure about kernel list etiquette re: how long to wait before bumping it | 18:59:26 |
| K900 | Yeah I was thinking maybe I should send in the RU one but decided I don't actually care enough | 19:00:04 |
| 9 Jun 2025 |
 ortolanbunting3002 | I have the following routes:
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.147 metric 3003
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 dead linkdown
192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.147 metric 3003
I have the following sysctl settings:
"net.ipv4.conf.all.ignore_routes_with_linkdown" = 1;
"net.ipv4.conf.default.ignore_routes_with_linkdown" = 1;
From the kernel docs: Ignore routes whose link is down when performing a FIB lookup.
% ip r g 192.168.1.1
192.168.1.1 dev wlan0 src 192.168.1.147 uid 1000
cache
%
eth0 is unplugged. Ping packets to 192.168.1.1 leave and arrive on wlan0 correctly. Despite that, the nixos-fw rpfilter chain drops those packets (checkReversePath = "strict", logReversePathDrops = true).
The relevant reverse path filter rule is fib saddr . mark . iif oif exists accept.
If I remove the routes on eth0, the pings are no longer dropped.
Why does routing work correctly, but the reverse path lookup fails?
| 12:20:02 |
|  SigmaSquadron joined the room. | 13:06:38 |
|  Spaenny changed their display name from Spaenny to Philipp. | 20:46:47 |
| 10 Jun 2025 |
 Ramses 🇵🇸 | I have the stable-privacy addressing method configured for all my networks with networkd, and I recently noticed that for one particular interface, this setting is not being honoured, and the interface still uses eui64. I checked that the right values are actually set in /proc/sys/net/ipv6/conf/<iface>/addr_gen_mode so it seems that networkd is doing what it's supposed to be doing, but the kernel isn't. One characteristic of this particular interface, is that it has a bunch of tagged vlan interfaces stacked on top of it, which is kind of the only thing that makes it stand out from the other interfaces. I was just wondering if anyone has by any change already stumbled upon this behaviour and looked into it? And if others are observing the same behaviour? | 11:23:18 |
| Ramses 🇵🇸 | Ah, I am talking about the LL addresses specifically here | 11:26:12 |
