A.B

@eyoung100 "The OS is irrelevant in both options as this is a networking question" it is relevant: see unix.stackexchange.com/help/on-topic . While "The underlying *nix OS on an embedded system" is on topic. If it's not about such underlying OS it can get off topic. Even Android can be off-topic if it's not about using it like an *nix system (else it has its own stack: android SE).

But now A, the unknown, black-box, non-Unix/Linux device has to relay between C and B. Why would that functionality be available on A?

Glad you got it back. It's not that I'm angry. I'm not. But stackexchange is not really meant to be an interactive help. It's aiming at solving problems well described. So sometimes, depending on the effort invested before and what effort has to be invested later, it might really be faster to restart from scratch.

(or take the chance to switch to Devuan if you believe you don't want systemd)

If this looks too difficult, then I'm sorry it will be easier to reinstall the whole system instead.

Now /var/tmp/log-apt-backup/history.log can be read by a normal user. You can use any tool to display a file: vi, nano, mousepad, even Firefox should be able to display it by navigating to file:///var/tmp/log-apt-backup/history.log . Find the date of your commands, find your commands and find what was removed. Make a list, and reinstall what you might want to need that you lost.

 cp -a /root/log-apt-backup /var/tmp/

So this file is in /root requiring root, better copy it elsewhere again. as root user (as written at the start of my answer) copy int again in /var/tmp:

I'm sorry but if you don't know how to read the content of a file, it might be easier to copy important data elsewhere and reinstall everything. I'll still give you a few ideas about reading this file, a very basic operation, but I don't intent to give each and every command for this

@Hussain as written in the answer: look for the lines having Remove: in them. They'll show what was removed because of the apt commands. Find the ones below the two Commandline: having your two apt remove systemd and similar commands. It shows everything (which might be a lot) that was removed because of this. This gives a list of packages to potentially put back. Where are you having a problem in this?

Btw, for anything more difficult (eg: Wifi and can't get network and don't want to figure out if enough commands are available to start it), the plan B is described there (and can then be followed the apt commands in my answer): wiki.debian.org/RescueLive

@Hussain So to get network. If using Ethernet (wired): get the interface name using ip -br link. Then run dhclient -v eth0 (replace eth0 with the actual interface name from the previous command). If using Wifi, plan B: have a live image available on USB stick or on CD. Which is it for you?

Your case might not be an isolated case. So I'll be sure when reading people complain about this, that they tell which Docker they did install. It's possible upstream-provided Docker does break Debian 12.

just not related to the Q/A

I'll delete my comments from the main site btw.

It's even possible this was not Docker but an other action who knows. Looks like reinstalling could be faster than spending more days on it. Just do it a few steps at a time, and verify it's still working (reboot) at each step.

Debian's docker is directly available using apt-get: apt-get install docker.io. But you'd have to remove the other one first (using purge), verify there are no configuration files left, reboot (which means you have to backup your own work first) and then install it.

you're in luck, sometimes I take comments like the one you did as an attack on my answer and won't behave so well, that's human nature. But as I couldn't see how my answer could have been the cause of anything here and got some spare time, I did behave.

guides are more often wrong than correct. Of course Docker (upstream) would recommend to install their release, how could they support problems with one they didn't supply else?

Anyway for your problem, you'll have to consider removing Docker after the lengthy backup. It appears (from one of your comments) you installed upstream's Docker rather than Debian-provided Docker. Debian's one, even of less recent, might have behaved differently because it's supposed to be better integrated by those who provided it. If you have to restart dhclient, then something has removed some of the network configuration on the host and that doesn't seem to be a big problem anyway.

As I said, I can cut/paste without problem through an (host) terminal including paths. Through the GUI it requires addons which depends on the hypervisor (vmware, virtualbox or libvirt (I have practical GUI experience only about libvirt, because at work none of the VMs have a GUI, why would they?). So if not using a GUI tool from the VM, I don't see the need to have a GUI on the VM.

How do you use Docker if not with commands?

But really I see you are ranting, searching everywhere etc. But this solution has to be done methodically, to check you still have network interfaces (drivers), then check their configuration, etc. Requires using tcpdump on all involved sides. This is a debug thing, and Stackexchange is not well geared for doing debugging.

As much as I can I ssh to my VM, without GUI. So I can do cut/pastes from my terminal as usual heh.

@JohnSmith personally I don't run Docker on my personal (including work-related "personal") host system: I run it in a VM to be sure it won't disrupt other tools (LXC, libvirt, ...) running beside it.

@JohnSmith You might need to ask your own question about it with details (intended to allow to reproduce your problem: it can be rare to suddenly think "oh I know that must be this" without experimenting with the problem first); because the problem you describe doesn't appear to be related to the problem described in this Q/A (which is related to bridging). I wouldn't know if SF is a good choice (rather than SU or UL SE) for this.

@JohnSmith If you install Docker and only Docker, and don't do anything with bridges (did you use bridges on Debian 9 before installing Docker?), then I don't see how installing Docker will break things. If you do use other networking technologies but didn't when using Debian 9, then you're comparing apples and oranges.

@JohnSmith nothing changes here between Debian 9 and Debian 12. Same tools are available in both (iptables is not deprecated (though iptables-legacy might be) and won't disappear). What makes you think something changed? Can you give more details? libvirt will get problems the same using Debian 9 and Debian 12 (though libvirt might have added counter measures meanwhile: it does handle the NAT issue correctly for example).

@MadMike comprehension is half the solution. If you don't understand how it's working, this requires one solution per configuration. Also recent kernels (5.something) have a per-namespace setting instead of a global all-namespaces-wide setting.

answer updated

everything written was correct, but the other way around wasn't considered

I'll add an UPDATE to the answer (rather than rewriting completely) explaining this part

I can update my answer to explain all this, but this can take quite some time

without going into details 2 is similar to 0 only in the presence of a default route

yes 2 would explain everything (including the default route elsewhere)

before doing it, what's the result of sysctl -ar \\.rp_filter (with twice a \ )

or maybe =2

Seems I can reproduce the timeout when it's =1 so I assume it's =1 on your system.

sysctl -w net.ipv4.conf.wlp2s0.rp_filter=0

sysctl -w net.ipv4.conf.all.rp_filter=0

what about running these 2 commands?

an never mind ok the working case

Indeed that means it succeeds

moved where?

ok

or anyway no ARP failure

anyway the ARP case takes 3s. I noticed you didn't always get 3s. no 3s means no ARP even attempted.

add 'or arp or icmp'

You can use tcpdump and see when you get or don't get ARPs and on what interface this happens.

Ok. well I don't know what can differ then.