You’ve lost another submarine?

No. A full breakdown here https://youtu.be/1dhvry6E0jA

The power aspect is a lot bigger of a factor than I would have thought. I had an old computer I was going to use as a server for Foundry that I could keep up all the time, but when I measured its wattage and did the math, it would cost me $20 a month to keep on. A pi costs like $2 to keep running, so it paid for itself pretty quick

At least plugging them all into Google translate, the pronunciations are actually all pretty similar, with Swedish being the most dissimilar

I’ve used them both a good bit for D&D/TTRPG campaigns. The image generation has been great for making NPC portraits and custom magic item images. LLM’s have been pretty handy for practicing my DM-ing and improv, by asking it to act like a player and reacting to what it decides to do. And sometimes in the reverse by asking it to pitch interesting ideas for characters/dungeons/quest lines. I rarely took those in their entirety, but would often have bits and pieces I’d use.

I probably do this a good bit without really thinking about it. I don’t really care about walking in mud/grass and I like to give people their space. The fact that they continued to walk on the grass after they passed makes me think it wasn’t a big deal for them either.

Relevant xkcd’s

I would throw out that Windows executables work surprisingly well on Linux these days via “wine.” I use EndeavorOS and it’s pretty much no work on my part, I double-click a .exe and it starts it up via wine. I think the only thing that’s been spotty for me is Meshmixer crashes sometimes, but it’s also abandonware so I’m not sure it actually runs better on Windows.

Oh, I don’t heat it at all, I just eat it room temperature

To me, the potential point of confusion is referring to “sent by Ctrl+D” and things “received by the end process” as synonymous, ignoring the tty driver in between. When you Ctrl+d, you send a magic byte value to the tty master (which I would refer to as a EOF character, but I understand the argument against the terminology). On the other side of it the process doesn’t receive this value, but instead has its read call returned even if the buffer is 0.

A simple example hopefully highlighting the difference

Window1:
nc -nvlp 5555 #"far nc"

Window2:
nc -nv 127.0.0.1 5555 #"local NC"
Hi there[Enter]
Hi [Ctrl+D]There[Ctrl+D][Enter]

Window3:
strace -p [pid of local nc]

Window2:
[Right arrow][Right arrow][Ctrl+D]
[Ctrl+D]Uh oh[Enter]

What we see is pretty much as described. From the first line, we see “Hi there\n” on the other side. For the second line, we first see "Hi " appear, then “There” then “\n”.

From the third line, in the strace we can see the sequences representing the right-arrow key, and we can see the tty driver on the far side takes those sequences and interprets them to render the cursor two characters to the right.

The fourth line is where it gets more interesting. We send the tty driver the EOF byte, and the tty driver interprets this and gives the current active tty client a 0-byte return to read() and assumes we have no more data to send. But unlike bash, nc doesn’t care about a 0-byte read and is still looking for more data (as we can see in the strace). But if we continue to type and send more data (the “Uh oh”), we can see in the strace that the tty never sends this to the nc. So, to some definition, we’re still sending data to the local nc, but the tty driver isn’t actually relaying it

I’m not sure I understand how you’d shred your fingers on them. I put my nail under the tab and lift until my finger can get under it

Sorry, I was looking more specifically at that DNAT rule

8   480 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2222 to:192.168.101.4:22

That rule exists in the host 192.168.86.73, correct? And from the guest, 192.168.101.4 you are attempting to ssh into 192.168.86.73:2222?

It might not be your issue (or only issue), but that DNAT rule says that if a connection comes in on port 2222, instead send it to 192.168.101.4:22. So 192.168.101.4->192.168.86.73:2222->192.168.101.4:22. I would have thought you’d want it to be a DNAT to 192.168.86.73, functionally doing port bending, so it goes 192.168.101.4->192.168.86.73:2222->192.168.86.73:22.

That doesn’t explain the connection refused, though, based on what you’ve said; there’s some fringe possibilities, but I wouldn’t expect for your setup if you hadn’t said (like your ~/.ssh/ssh_config defining an alternate ssh port for your guest OS than 22). It’s somewhat annoying, but it might be worthwhile to do a packet capture on both ends and follow exactly where the packet is going. So a

tcpdump -v -Nnn tcp port 22 or tcp port 2222

For general awareness, not all flags can match all parts of an iptables command; the part you included there with “–to offset” is only valid with the string module, and not the DNAT action. That said after playing around with it a little, iptables actually does short flag matching, so ‘DNAT --to 1.2.3.4’ ‘DNAT --to-d 1.2.3.4’ and ‘DNAT --to-destination’ are all equivalent, so not the source of your issue.

I am having trouble following the IP scheme, though. Is your Alma guest 192.168.101.4, or is that the host IP? If it’s Alma’s and you are attempting to ssh from that IP to the host with that iptables rule, what should happen is that DNAT would then redirect that connection back to Alma. If the guest doesn’t have a :22 listener, you’d get a connection refused from itself.

Your hook has

/sbin/iptables -t nat -I PREROUTING -p tcp --dport $HOST_PORT -j DNAT --to $GUEST_IP:$GUEST_PORT

But I’d didn’t think that “–to” was a flag for DNAT, I thought it was “–to-destination”

If you ‘iptables -nvL’ and ‘iptables -t nat -nvL’ do you see both your DNAT and forwarding rules (although if the default is ACCEPT and you don’t have other rules, the FORWARD one isn’t needed), and do you see the packet count for the rules increase?