cursed idea: windows + openvpn-tap-adapter + qemu + linux + clatd
now how to build a minimal linux image with nothing more than clatd...
[#]ipv6
=> More informations about this toot | More toots from SoniEx2@chaos.social
qemu works, openwrt seems to work, the tap adapters seem to work... for the most part. we can't seem to get windows to configure the tap adapter for dhcp for some reason?
this would be so easy if only it just worked...
=> More informations about this toot | More toots from SoniEx2@chaos.social
we have openwrt running in a vm running in windows running in a vm
we have a tap interface and a bridge interface, well 2 of each if you consider both vms
we can't seem to ping the host nor the windows vm, not sure what's going on
=> More informations about this toot | More toots from SoniEx2@chaos.social
we can ping, now to figure out how to turn off the firewall...?
=> More informations about this toot | More toots from SoniEx2@chaos.social
we disabled both firewalls and we still can't connect to it :?
=> More informations about this toot | More toots from SoniEx2@chaos.social
okay so, turns out trying to use -nographic was a bit of a mistake
we have now corrected that, this is a huge improvement to being able to interact with the openwrt VM.
unfortunately we still don't know why networking isn't quite working properly.
=> More informations about this toot | More toots from SoniEx2@chaos.social
we're gonna sleep, might try this again tomorrow
=> More informations about this toot | More toots from SoniEx2@chaos.social
we won't be able to test for a few hours but
we are running qemu under qemu
what are the odds we have a MAC address conflict
=> More informations about this toot | More toots from SoniEx2@chaos.social
attempting a questionable downgrade...
=> More informations about this toot | More toots from SoniEx2@chaos.social
WRONG INTERFACE OOPS
=> More informations about this toot | More toots from SoniEx2@chaos.social
okay so the openvpn tap adapter is broken actually, and we don't know how to workaround
=> More informations about this toot | More toots from SoniEx2@chaos.social
we can get packets from the qemu to the outside world (so e.g. SLAAC works) but not the other way around (so e.g. DHCP doesn't)
=> More informations about this toot | More toots from SoniEx2@chaos.social
oh yeah we haven't done anything with clatd yet, we're just trying to get openwrt working at all (and be able to access LuCI)
=> More informations about this toot | More toots from SoniEx2@chaos.social
is the VM in a VM... just, too slow?
=> More informations about this toot | More toots from SoniEx2@chaos.social
virtio_net helps a lot. so now we can use LuCI! (and give the host an IPv4 address via DHCPv4)
unfortunately, we can't seem to get the bridge to work. without the bridge, we can't do SLAAC for clatd.
(so close, and yet so far...)
=> More informations about this toot | More toots from SoniEx2@chaos.social
btw we had to use this: https://openwrt.org/docs/guide-user/base-system/hotplug#rename_interfaces_by_mac_address
but anyway
=> More informations about this toot | More toots from SoniEx2@chaos.social
could it be a qemu bug? might try another version of qemu and see if it works...
=> More informations about this toot | More toots from SoniEx2@chaos.social
wait, there are packets, they're just not getting bridged...
could be a VM-in-VM issue? hmm...
=> More informations about this toot | More toots from SoniEx2@chaos.social
we think this is on the windows side, actually. so, not a VM-in-VM issue.
=> More informations about this toot | More toots from SoniEx2@chaos.social
okay we're pretty sure we just ran into a qemu bug...
=> More informations about this toot | More toots from SoniEx2@chaos.social
the bug:
given a command like
.\qemu-system-x86_64.exe -m 128 -drive 'file=C:\Users\SoniEx2\Downloads\openwrt-23.05.5-x86-64-generic-ext4-combined-efi.img,id=disk,format=raw' -netdev tap,ifname=ipv4,id=ipv4 -device virtio-net,netdev=ipv4,mac=52:54:98:76:54:33 -netdev tap,ifname=clatd,id=clatd -device virtio-net,netdev=clatd,mac=52:54:98:76:54:32 -rtc base=utc -smp 2
only the last network interface works. ('clatd' in this case.)
=> More informations about this toot | More toots from SoniEx2@chaos.social
if we swap them around then only 'ipv4' works, while 'clatd' stops working.
we need both interfaces because we don't want to leak ipv4 back into the network. a CLAT that leaks ipv4 back into the network is a pretty terrible CLAT.
=> More informations about this toot | More toots from SoniEx2@chaos.social
so, yes, for the time being, the blocker for "CLAT in windows 10" is a qemu bug. this is where we stop for now. hopefully this bug gets fixed before windows 10 is EOL. ;)
=> More informations about this toot | More toots from SoniEx2@chaos.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini