biscuitswalrus

Yeah, my mum isn't going into the shell. She's 65.

I don't really like the idea of 'beginner friendly' like 'you'll get better and start doing it the real way'. It's not some esport where it's easy to play and hard to master, it's a toolbox where it's only job is to get out of the way of you accessing your tools.

Operating systems are middleware.

Yes, you're right about voltage and amp combined, but the problem is modern phones and their charges don't generally want to be doing high amps at 5v, they increase their voltage to 9v, 15v or, 20v. Which like you would point out, is not the right voltage.

Personally I just feed 5v in via a ubec like this: https://core-electronics.com.au/ubec-dc-dc-step-down-buck-converter-5v-at-3a-output.html since I usually have some kind of 12v battery powered thing going on with mine and lots of 12v ac-dc adapters for bench testing and charging. Lots of ways to power them but it's definitely not just 'grab your usb-c charger and it'll be right' which can be frustrating for people since it's almost all other usb-c things will 'just work'.

Tailscale can act as a site to site vpn, but it's best used as a meshvpn imo with as many things as possible in it.

Why? Because the dynamic dns is so powerful. Every host name automatically is in every other tailscale joined computer automatically. My NAS (Truenas in my case) is just "nas" so to access it it's just https://nas. Same with my rustdesk server on https://rustdesk. Jellyfin? You guessed it: https://jellyfin.

Why is this cool? I moved my box between other networks and it just works again. No ips changed.

I take it to work. It just works. I keep one server at my parents place? It just works.

But my printer doesn't have the ability to join the tailnet so I use subnet routing to create a node on that network to act as a NAT router to get to and from that printer.

You can even define exit nodes so if I install tailscale on my parents TV in another state, they can exit their internet via my home which has my IP and therefore Netflix counts it as inside my residence.

Anyway just some considerations. I generally use the subnet routing as a last resort. My 3 node proxmox cluster is all joined and if I took a node to my parents it would literally just work, if slower, as a cluster member. Crazy. Very cool

I've used virtio for Nutanix before and not using open speed test, but instead using iperf, gathered line rate across hosts.

However I also know network cards matter a lot. Some network cards, especially cheap Intel x710 suck. They don't have specific compute offloading that can be done so the CPU does all the work and the host cpu itself processes network traffic significantly slowing throughput.

My change to mellanox 25g cards showed all vm network performance increase to the expected line rate even on same host.

That was not a home lab though, that was production at a client.

Edit sorry I meant to wrap up:

• to test use iperf (you could use UDP at 10Gbit and run it continuous, in UDP mode you need to set the size you try to send)
• while testing look for CPU on the host

If you want to exclude proxmox you could attempt to live boot another usb Linux and test iperf over the lan to another device.

After installing mint, and you find a problem, just live boot mint again.

You can do a lot in live boot including mount your permanent copy even the kernel. Whatever is missing you can download put onto the installed hdd or usb storage, and then install.

Ask me how I know. Lol.

Or maybe they're trying to keep their system minimised from yet to be found security issues in the hundreds of packages pre installed that they don't ever use or need, and act as nothing other than additional threat surface.

Ok so you may need to translate a few things.

Routers gateway networks. Networks are extended physically by Ethernet. The ether in Ethernet is basically "to the network it doesn't matter the medium" and in days past that was coax, or whatever Cabling you had but today is almost exclusively in a house, fibre, WiFi, and cat[5/6/7].

Why does this matter? The router is the pivot between networks. Wireless access points are just part of the network.

A wireless router is a device with two functions!

Ok so how does a router work? When you buy a home grade router like an Asus or netgear, you get a device which has a single routing statement "0.0.0.0/0 via connected interface WAN". This works on almost everyones home network because they only have a single network.

A local network doesn't need a router to talk, you only talk when you need to talk to something on another network. Your devices automatically broadcast to every other device on connection or device start up "I'm [mac address] with ip [ip] can you introduce yourself?" and everyone who is online responds back not in broadcast, but unicast directly to that device about their mac address. Your device stores that info in a Mac address table with time outs. This applies to the router too, it knows all the ip addresses on the LAN interface.

Ok now we want to add a second home network to segment IoT away from your highly personal devices with all your personal information. Good idea! So to do that on any "fully fledged" router it's super easy you would connect a cable to LAN2 plan a second IP subnet and connect a switch or AP to that. The router is now a router for network LAN1 and LAN2. If a device needs to get from LAN1 it goes "this IP isn't in my subnet therefore I will send it to the router". It will have no idea if the device is online or offline, it just sends it blindly to the router. Your router gets that IP and now looks at its routing table which now looks like this,for example:

• 192.168.0.0/24 via connected interface LAN1
• 192.168.1.0/24 via connected interface LAN2
• 0.0.0.0/0 via connected interface WAN

So now the router who knows you tried to get to a device within LAN2 from LAN1 will check the mac address table it has for LAN2 and see if there's a mac address it's learned from that device connection. If it does it sends the packet on back unmodified. The packet has return address information saying who sent it, and the IoT device can talk back.

Wonderful, that's the most simplest type of multi-lan network you can create. There are no virtual lans and everyone expects networks to mostly work this way. This exact principle is how the rest of the whole internet works. What networks are via what interface and a traceroute will tell you the resulting path. A router doesn't need to know the destination just the next network.

One last note on the background info, if you don't want to setup everything with static IP addresses, you'll setup a DHCP server which gives out IP details to devices via a lease system, and included can be DNS settings. You must have a dhcp service within a local network. That can be on the router on the LAN1 interface, and another DHCP server with different details on LAN2.

To apply this to your problem, I think you'll want to review the features of your two WiFi routers that you have. Many home routers do not support two discrete LAN interfaces. If they have 4 LAN ports they could be already configured as a "bridge" which is to say they're a switch. They're all grouped all belonging to LAN1. Check to see if you can remove one from the bridge. BTW the WiFi is usually part of this bridge too.

If I had to guess the Asus router is likely more featured and more likely to have the ability to create a new network on a different interface.

The simplest design will be to have your one router be the router for both networks. One wireless router has the router function disabled and becomes a wireless access point connected to LAN2. The router will know all connected networks (WAN/LAN1MLAN2). You won't even need to write in your own route.

But if this is not possible, it is still possible to use NAT. network address translation is a technology for a router to re-write the "return address" on every packet it sends. The return address becomes the routers WAN interface IP. Your network already has NAT because your LAN IP would send to an external network like "1.1.1.1" and if your return l address was "192.168.0.2" then 1.1.1.1 wouldn't know how to get back to you since your IP is used on millions of home private networks. Instead your router uses NAT to keep a table of every single connection to the internet and waits for replies and redirects them back to the right device. It replaces the source address with your ISP assigned public IP. So 1.1.1.1 could have got a return address of 12.23.34.45 your home internet ip.

But this can work on your home network but there's limitations. Just 1.1.1.1 can't randomly reach back out to the original device ever. Only your device can ask 1.1.1.1. If 1.1.1.1 tried to reach back to your public IP the router has no NAT entry for this, and drops the connection.

Do let's take the real possibility that you can't setup two LAN interfaces on your home grade routers. What would you do? Instead could have a second wireless router with NAT enabled (which it is by default). Your second wireless router could broadcast a different SSID and it's network ip subnet address should be different to your home network IP subnet address. So if your home is 192.168.0.0/24 your IOT could be 192.168.1.0/24. Your WAN interface should be setup static on an address that does not conflict with your DHCP scope. Or if it does, go to the dhcp server and reserve it. It should be an ip that doesn't change and can't accidentally be given to another device thereby giving you IP conflicts.

So then your IoT devices now will get that 192.168.1.2+ address and reach to your IOT router to get out of their network. Now this does allow them to talk to your home network devices on 192.168.0.0/24. But the downside is your home lan devices by default can not talk to your IOT devices. This is kind of the reverse of what you want from a security perspective. To configure your IOT you'll need to join the IOT WIFI. Why is this? If you on your home network connected device on 192.168.0.1/24 try to go to the IOT network device on 192.168.1.0/24, then the home device first notes that the network is not local, so it will send the request to the configured gateway. Your home gateway has no idea where 192.168.1.0/24 is either. So it goes out to the 0.0.0.0/0 route which is to your ISPs router.

I'm sure you'll think: if this is backwards why not flip my home network behind my second NAT router? And the answer is NAT isn't free, and you'll probably have heard CGNAT or carrier grade NAT making a mess of games and services. Double NAT has problems too.

So what about dhcp and dns? The simple answer is the IOT router becomes a dhcp server and offers your IOT pihole for DNS. Your home network shouldn't need touching

There are ways to band-aid these two networks. If you know your home router has a proper route table you can modify that. remember you setup the IoT router with a static IP? Well here's why. If you setup a route statement 192.168.1.0/24 via IP 192.168.0.251 (whatever IP is the IoT router) then now your home router can find and redirect traffic. This still occasionally has issues though and this routing statement can create a triangle route which would take a long time to explain, and secondly a fix for that can be more NAT more translation so we can return communication from the same way, but the branching possibilities are still not fully defined. Alternative fixes are on your local computer add a single routing statement to find 192.168.1.0/24 via 192.168.0.251 (or whatever IoT router ip you assigned).

Now my suggestion: get a router which handles two local networks. Then you're topology is pretty much the simplest, easiest to troubleshoot later, avoid Nat.

To me, not a player, it seems like there's a long winded explanation/justification for why they uploaded a illegitimately approved run. In Super Mario maker, if you make a level you need to beat it to upload it. They beat it with a tool instead of skill, to ensure the sequence of frame perfect tricks could be completed, something nearly impossible to do by real players.

There were many top level players all at once playing that level non stop. So I feel for them. Training their muscle memory to execute robot timings for what came out to be not a legit level.

Most of what was said was irrelevant, they managed a life story in the middle of an apology.

The messaging around this so far doesn't lead me to want to follow the fork on production. As a sysadmin I'm not rushing out to swap my reverse proxy.

The problem is I'm speculating but it seems like the developer was only continuing to develop under condition that they continued control over the nginx decision making.

So currently it looks like from a user of nginx, the cve registration is protecting me with open communication. From a security aspect, a security researcher probably needs that cve to count as a bug bounty.

From the developers perspective, f5 broke the pact of decision control being with the developer. But for me, I would rather it be registered and I'm informed even if I know my configuration doesn't use it.

Again, assuming a lot here. But I agree with f5. That feature even beta could be in a dev or test environment. That's enough reason to know.

Edit:Long term, I don't know where I'll land. Personally I'd rather be with the developer, except I need to trust that the solution is open not in source, but in communication. It's a weird situation.

IP and Routing is layer 3, broadcast is layer 2 with Mac addresses being shared within a broadcast domain (often a vlan/lan) and the only requirement for layer 2 is a switch you don't need routers. Devices on a lan talk only via switches which switch based on Mac address tables. You don't learn Mac addresses of devices past your broadcast domain, that's what a router handles.

So in network practice (nothing Linux related) if you are on a broadcast network that's a /24 subnet, what should happen is all devices within that subnet talk to each other without using a router, instead they learn a mac address and the associated ip from a broadcast from the device which owns it.

If you tell your device that it's only on a /32 then it should discard every arp it hears as invalid. Which means it won't learn any neighbouring lan devices.

While your network on your single device with the /32 probably works ok to get to other networks (routed networks like internet or other vlans), because other networks ask the router, and the router probably learned your mac and ip on whatever vlan/interface your device is connected via.

But unless you're trying to do something unconventional, devices on a lan should match the routers expected subnet. This way devices can trust their assumption that within their subnet they communicate to other local devices by learning other network devices network address via arp, and communicate directly in unicast via learned ips from that arp. If it's outside the subnet they then look to the gateway. They trust the gateway. The gateway should route to the right interface or next hop.

If you really wanted to make this work though, usually routers can proxy arp. So in this case, you tell the router to 'oroxy' and broadcast your arp to other devices. Those devices on your lan looking for your ip will find the routers Mac address, then using destination network address translation you can redirect the incoming connection from a lan device to your device via your router. Then your /32 ip can probably work. Usually this is done when someone has put a static ip on a device with a wrong subnet ip on a vlan with another subnet. So the device which arps is ignored by the router and the other network devices. If you use the router to proxy arp you can basically give the local lan devices an ip to hit that they expect, which then you can translate to the misconfigured device. This generally is considered a bandaid solution temporary until a vendor or technician can fix their misconfiguration. I do not recommend.

I mean, the rdp is from Linux to Windows for desktop application access, so it's the right tool for that job.

I self host rustdesk privately via tailscale and strongly recommend it. I don't always need a desktop but when I do, I'm glad I can use rustdesk.