Hi,
I got quite a weird problem, short backstory: Using an espressobin as my main router since a while, noticed that linux-espressobin seemed to be stuck on 5.10 for to long but as I read here and there that mainline support should work out nowadays I go for it and install linux-aarch64, it initially fails but after I'm re-understanding u-boot again (it has been a while) I get it to boot. Now, seemed to be working great initially, the espressobin can connect to the network, my wireguard setup also still works, but then I notice that my whole LAN has no internet, well besides the one raspi zero w that solely uses the espressobin's wiregurad, fishy as I changed nothing on how I do masquerading with my quite simple nftables setup.
I switch to my ISP's router for now to get internet to my people and plug the espressobin for testing between that ISP router as new WAN and my desktop as test client, so that part of the network looks currently about like:
So I connect to my Raspberry Pi Zero W, add a route for the espressobin LAN like:
$this->bbcode_second_pass_code('', 'ip route add 192.168.1.0/24 via 192.168.0.115')
And sure enough I can ping the Espressobin also on 192.168.1.1, but when I try my desktop while running tcpdump I get the following weird result:
$this->bbcode_second_pass_code('', '20:21:13.482962 IP 192.168.0.80 > desktop: ICMP echo request, id 4, seq 11, length 64
20:21:13.483370 IP desktop > 192.168.0.80: ICMP echo reply, id 4, seq 11, length 64
20:21:14.537007 IP 192.168.0.80 > desktop: ICMP echo request, id 4, seq 12, length 64
20:21:14.537420 IP desktop > 192.168.0.80: ICMP echo reply, id 4, seq 12, length 64
20:21:15.563434 IP 192.168.0.80 > desktop: ICMP echo request, id 4, seq 13, length 64
20:21:15.563851 IP desktop > 192.168.0.80: ICMP echo reply, id 4, seq 13, length 64')
Iow., I see both request and also the reply so my desktop gets the ICMP request, but the RPi Zero doesn't get that reply anymore, so its lost, I have a suspicion regarding the kernels forwarding chain, or the network stack itself, possible in the Forwarding DB of the nic/bridge or the like..
And if I then boot back to the 5.10 espressobin setup all works out great again, ping and also other connections from the LAN behind of the espressobin to the WAN in front.
Is this a kernel bug, do newer kernel require something else? Albeit I checked on my x86_64 work setup and 5.15.5, masquerading worked there flawlessly without special care required...