Re: [COFF] A little networking tool to reduce having to run emulators with privilege

On 9/21/20 3:38 PM, Steffen Nurpmeso wrote: Is it the bridge that's the problem or is it the wireless interface that's the problem? My understanding is that some (many?) wireless interfaces are funky regarding multiple MAC addresses. Mostly in that they don't work with extra MAC addresses. What would you do with veth interfaces in this context? I've been able to use ip to do much of what I used to do with brctl. ip link add bri0 type bridge ip link set eth1 master bri0 (from memory) What would network namespaces provide in this context? Would you run the $EMULATOR in the network namespace (~container)? What does that get you that running the $EMULATOR in the main / root / unnamed network namespace does not get you? -- If anything, I'd think that running the $EMULATOR in the network namespace would add additional networking complexity. Don't get me wrong, I'm all for network namespaces and doing fun(ky) things with them. I've emulated entire corporate networks with network namespaces. I've currently got nine of them on the system I'm replying from, with dynamic routing. I'll argue that Proxy ARP /is/ a form of routing. ;-) Your system replies to ARP requests for the IP(s) behind it and the packets are sent to it as if it's a router. }:-) I find veth to be quite helpful. {MAC,IP}{VLAN,VTAP} are also fun. Aside: {MAC,IP}{VLAN,VTAP} is slightly more difficult to get working. In my experience, {MAC,IP}{VLAN,VTAP} don't support talking to the host directly, instead you need to create an additional {MAC,IP}{VLAN,VTAP} and have the hose use it as if it is it's own guest. I've never noticed any sort of increased latency worth mentioning. If you create the netns first, then you can have the veth interface created and moved into the network namespace in one command. ${ip} link add v_n type veth peer name v_i netns v_ns Note: This does create the v_i veth interface in the network namespace that you're running the command in and then automatically move it for you. Why are you adding a (host) route to 10.0.0.1 when it's part of 10.0.0.0/8 which is going out the same interface? Why are you adding a bridge inside the v_ns network namespace? Why are you adding the v_i interface to the bridge /inside/ the network namespace? What does creating a bridge with a single interface /inside/ of the network namespace get you? I would have assumed that you were creating the bridge outside the network namespace and adding the network namespace's outside veth to said bridge. Yep. I've done a LOT of things like that. Though I have the bridge outside. What was (historically, since it's commented out) the purpose for setting arp_ignore to 1. This is more what I would expect. I guess the route is because you're using Proxy ARP. That makes me ask, is the 10.0.0.0/8 network also used on the outside home LAN? ;-) You can bind mount /dev into the chroot. That way you could chroot in. Much like Gentoo does during installation. :-) Have you spent any time looking at unshare and / or nsenter? # Spawn the lab# NetNSs and set it's hostname. unshare --mount=/run/mountns/${1} --net=/run/netns/${1} --uts=/run/utsns/${1} /bin/hostname ${1} # Bring up the loopback interface. nsenter --mount=/run/mountns/${1} --net=/run/netns/${1} --uts=/run/utsns/${1} /bin/ip link set dev lo up I use the mount, net, and uts namespaces. RTFM for more details on different combinations of namespaces. ... VM everywhere. But ... are they /really/ VMs? You're running an /emulator/* in a (home grown) /container/. }:-) *Okay. QEMU can be more of a VM than an emulator, depending on command line options. I'm not that familiar with jails. But I'm convinced that there are some possibilities with namespaces (containers) that may come close. Network namespaces (ip netns ...) don't alter the mount namespace. That's one of the advantages of unshare / nsenter. You can create new namespace (container) specific mount configurations. -- Grant. . . . unix || die