It's probably par for the course. Networking is an area that's always felt like shifting ground. Anytime I need to spin up a machine with WoL or (rarely) need to edit something at the conf level, it's always a software archeology project, trying to figure out what the new hotness is, where the system vs user config is under the new networking package, grokking the new config syntax/options, and what supercedes if/when multiple networking packages exist on the same host.
Knowing the reality, looking at the domain name, given the title, and that it starts off:
> It is time to revisit of the simple wifi setup as much has changed [in a year]
This actually reminds me of sound on Linux too. I'm running a bleeding edge Tumbleweed on my laptop and Home Cinema. I now have to occasionally tweak ALSA, PulseAudio and PipeWire stuff. I know that by installing pipewire-pulse, I'm actually using PipeWire, but since it still relies on a heap of PulseAudio conf files and command line utilities, it feels like they've added one more thing to be confused about rather than simplifying the setup. Just try to figure out how to upmix stereo to 5.1 with an LFE channel to your subwoofer. Do you use the (now renamed) lfe options in pulse daemon.conf, some pipewire conf, or the extremely arcane ALSA ttable mappings? There has never been a decent GUI for handling audio in Linux. Sometimes I wonder if I should also install Jack to see if that complicates it more or simplifies it.
Oh, does networking ever get fun. Debugging udev sounds like easy mode. At least it's userspace and has logs. I've been beating my head against this one problem for days with no progress whatsoever.
Inner VM is a normal Ubuntu install, nothing odd about it.
Outer VM is setup to MASQUERADE Inner's IP address. It's all straightforward. There's only one exit network interface, and iptables is set up perfectly normally. Copy/pasted from the docs even just to be sure.
Checking stats shows that the NAT table is not actually being hit. Inner's packets get forwarded to Host with the IP address un-NATed. Stuff obviously doesn't work.
And how exactly do you debug this? How do you ask the kernel, "hey, why do you think this particular packet has no need to go through the NAT table?"
In general for networking kernel-side what you get is that if you're lucky you get an error number which doesn't even come close to explaining what the actual problem is. If you're not, stuff just fails to work with no explanation whatsoever. Yeah, you can add log rules, but it's kind of a problem when the table you think should be consulted just isn't, at all.
Well, I guess at least there's source code. Hope it doesn't come to that.
