Been a while since I looked in here. Been busy with Smoothwall Express and getting 8 updates out.
A qemu option that fixes the mouse:
-usb -usbdevice tablet
(Duh! I should’ve realized that a tablet pointing device would be the solution: where the pointer is, the cursor is.)
Recently been dealing with a ‘dicey’ system; on my desktop, the CPU fan just wouldn’t spin fast enough. After much rending of garments and gnashing of teeth, I discovered that the Vishera 8350 (slightly overclocked to 4.4GHz and the 1866 RAM to 2133) draws more than 22A of 12VDC, at least when compiling gcc and linux using all 8 cores. Once I figured that out, I bought a Corsair RM750x P/S (single 12VDC rail) from Newegg (about $60 after rebates). 12VDC is rock solid now and the stock CPU fan once again spins up to 6200 RPM and is able to keep the CPU under 60°C: important when the linux compile keeps all 8 cores full bore for 7 minutes.
It would be, mmm, interesting to see if netfilter could be adapted to Haiku-OS. As I understand, there are hooks in the Linux network stack that make calls into netfilter in various stages of packet processing (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING). If you know Haiku’s networking code, http://www.docum.org/docum.org/kptd/ might be of some use. It’s old, but still reasonably reflects the path packets (more likely pointers to packets) take as they travel through Linux’s network stack. But with nftables replacing iptables/ebtables, the diagram may need significant redrawing.
Basically, you’d need conntrack (it is the ‘Stateful Packet Inspection’ part) so you can know if a packet is NEW (the first packet of the association between two endpoints), ESTABLISHED (the rest of the packets in the association), RELATED (the first packet of an association a helper has determined to be related to an existing conn (such as the data connection of an existing FTP control connection), or INVALID (conntrack has no idea what to do with this packet or why it was received; it would’ve been an ESTABLISHED packet except that it belongs to no active conntrack).
You would need filter to decide which packets are allowed, which are rejected (with return notification), and which are dropped (as though never received).
You might need nat, not so much for changing the address, but more to redirect the packet to a different port (for a transparent web/NTP/DNS/SIP proxy, for example).
For a standalone system (only one NIC and no forwarding between them), you could probably get away with conntrack and filter to start with.