== Networking ==
	== Simple forwarding ==
		To forward a simple port without configuring bridges and whatnot
		we use the following syntax:
		`-netdev user,id=unet,hostfwd=tcp::2222-:22 -device virtio-net,netdev=unet` 
		this forwards port on localhost:2222 to the ssh service on the guest
		and configures a net device. On NetBSD we use virtio-net on linux
		maybe virtio-net-device.

	If 2 devices have the same MAC address, they
	share the same traffic if the router knows about it?
	== Bridges ==
		Make sure to check `sysctl net.bridge`
			all entries should be 0 to enable bridging
			otherwise the kernel will filter packets and drop
			them, making it seemingly not work
		Make sure to check if there is no conflict in the routes
		with `route -n` there shouldn't be 2 default routes
		with 2 different interfaces
		The default should now go through the newly defined bridge.
		Also make sure the bridge gets a `dhcp` address via `dhcpcd` or
		equivalent. 
		So, to summarise, here is a checklist of things to do
		before setting up a bridge:
			* Check if `iptables` isnt filtering in the FORWARDING
				table all packets to DROP. if they do,
				add the necessary entries for your bridge
			* Check the output of `sysctl net.bridge` and make sure 
			  all filtering options are disabled 
			* Create the bridge:
				`ip link add name  type bridge`
				`ip link set  up`
			* Assign interfaces to it
				`ip link set  master `
			* Aquire a dhcp lease:
				`dhcpcd `
			* Check routing table:
				`route -n`
			* Make sure there are no conflicting entries for the
				`default` route. i.e. `` should be the
				only interface showing up in the route
			* Delete unnecessary routes if needed:
				`route del -net 0.0.0.0/24 dev `
				`route del -net /24 dev `
			* The bridge is now configured, check with ping and other tools
			* You can try to bring down the original physical interface
				down then up again to make sure.
	
	== Persistance of the bridge ==
		In order to make the bridge persistent, make sure to make aprorpiate
		entries in /etc/conf.d/net and link in net.lo to net.br0 or whatever
		the bridge interface was called
	
	== QEMU Bridged networking ==
		Once the above has been done it is now time to connect a guest to it
		`-net nic -netdev bridge,id=net0,br=br0 -device virtio-net-pci,netdev=net0`
		Append the above line to a QEMU instance run command. In the above,
		we used `br0` as our ``
		
		Additionally, in new qemu configurations, we can use `-nic bridge,br=br0`
		to configure bridged networking. This works very well. Sometimes
		the previous config. throws a warning "hub 0 not connected to host network"
		and may not work properly. Using the `-nic` parameter, this resolves
		itself and the host gets proper bridged networking.
		For a comprehensive explanation of these options, consult:
		https://www.qemu.org/2018/05/31/nic-parameter/
		It is important to also set the *mac address* via `-nic bridge,br=br0,mac=11:22:33:44:55:66`
		to allow the differentiation of different hosts.
		Also remember to check `sysctl net.bridge.bridge-nf-call-iptables` and set it to 0 in
		case `docker` is installed or if `iptables` ip forwarding has been disabled
		or simmilar.
		
		With this setup, it should now be possible to connect multiple hosts
		together with their ips being visible to eachother along with the
		host.
		
		It is also important to check the `iptables` default policies for
		the `FORWARD` chain. If it defaults to drop, then chances are
		the connection will not work properly.
		
		To fix this we can either flush all rules with `iptables -F; iptables -X`
		and set the default policies `iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT`
		or make sure that the bridge doesnt end up getting filtered by adding `iptables -I FORWARD -i br0 -j ACCPET` and
		`iptables -I FORWARD -o br0 -j ACCEPT`.
		Once again, we need to make sure that the bridge doesnt get filtered via iptables or other rules.
		So inspect the output of `sysctl net.bridge` and check if everything related to filtering is disabled.
		
		After all this it should be possible to listen to connections on the guest and connect from the host
		and vice-versa.
		
		Also make sure `sysctl net.ipv4.conf.all.proxy_arp` and `sysctl net.ipv4.conf.all.proxy_arp_pvlan` are set to 1 to
		allow forwarding of arp. also relevant arp forwarding `sysctl net.ipv4.conf.all.arp_forwarding=1` and
		possibly other releated forwarding rules for the bridge or ideally for all if its permissible
	
		== Bridge networking for windows 10 guest ==
			In order for the windows 10 guest to work we need to supply
			the `-device e1000,netdev=net0` instead of the `virtio-net-pci`
			because only for that device the default win10 ms-edge
			testing ISO has the driver. We could install another driver
			for the virtio-net-pci device but for the sake of simplicty
			this will do.
	
	== QEMU usb passthrough ==
		To enable pass-through for the a usb storage stick,
		we first need to make sure to have proper rules/permissions
		so that we do not need to be root to access the device from
		within qemu.
		To do this, we add the following lines in our _/etc/udev/rules.d/10-qemu.rules_ file
		{{{udev
			SUBSYSTEM=="usb",ATTRS{idVendor}=="1908",TAG+="uaccess"
		}}}
		The idVendor has to be one specified by `lsusb` command
		and should match the usb stick we wish to pass through our GUEST.
		We then need to update/reload the rules with
		`udevadm control -R`
		`udevadm trigger`
		Next, we need to add the following command line options to our qemu
		quest invocation:
		`-device usb-ehci,id=ehci -device usb-host,bus=ehci.0,hostbus=2,hostaddr=4`
		where _hostbus_ represents the device bus and hostaddr the address as specified
		by the `lsusb` command. We could also use `vendorid=xxxxxx,productid=xxxxxx`
		instead of hostbus and hostaddr