ktock
tinyemu: Slirp Socket support on WAMR
The Wasm Micro Runtime ships with an Apache 2.0 (with LLVM Exception) library which enables use of sockets in Wasm binaries. Integrating this library and fixing fallout issues enables networking support at least on WAMR.
So as far as I can tell enabling SLIRP would result in the guest using VIRTIO_NET for networking. The module is actually loaded on my custom-built image but not used, at least it doesn't expose a networking interface.
All comments should be somewhat handled now.
EDIT: First signs of user networking, though without a valid IP address (neither static IP nor DHCP work on my end, couldn't figure it out).
Thanks! TinyEMU seems to add the following addresses in the virtual network.
https://github.com/ktock/container2wasm/blob/bc5b06809d99e052dc41ae4396fb3cdffa85c3f0/patches/tinyemu/tinyemu/temu.c#L550-L554
In the guest VM, https://github.com/ktock/container2wasm/blob/main/cmd/init/main.go is executed before launching runc container so we can invoke some commands there for the interface configuration.
Thanks, I'll set it up there and remove the capabilities as soon as it works properly.
Attempting the QEMU-preferred way of using DHCP (using dhclient), it seems as if only the first UDP packet gets forwarded through Virtio, then discarded because the checksum doesn't match, and no further UDP packets get forwarded afterwards. I wonder what's up here.
it seems as if only the first UDP packet gets forwarded through Virtio, then discarded because the checksum doesn't match, and no further UDP packets get forwarded afterwards. I wonder what's up here.
Maybe we need some compile-time configurations for slirp? https://github.com/ktock/container2wasm/blob/main/patches/tinyemu/tinyemu/slirp/slirp_config.h (e.g. SIZEOF_CHAR_P = 4, HOST_LONG_BITS = 32, etc...)
it seems as if only the first UDP packet gets forwarded through Virtio, then discarded because the checksum doesn't match, and no further UDP packets get forwarded afterwards. I wonder what's up here.
Maybe we need some compile-time configurations for slirp? https://github.com/ktock/container2wasm/blob/main/patches/tinyemu/tinyemu/slirp/slirp_config.h (e.g.
SIZEOF_CHAR_P= 4,HOST_LONG_BITS= 32, etc...)
Tried that but those values already were accurate. I assume the device's virtio queue to not getting processed properly. Taking a deeper look now.
Seems as if writing arping responses always returns here: https://github.com/ktock/container2wasm/blob/main/patches/tinyemu/tinyemu/virtio.c#L1203
Now I wonder why that is, since other virtio devices seem to be increasing the last_avail_idx properly. Hacking around this by #if 0-ing out the condition allows the first packet to pass through, though no others.
Note that right now I'm setting up networking like this:
ip addr add 10.0.2.15/24 dev eth0
ip link set dev eth0 up
ip route add default via 10.0.2.2 dev eth0
I haven't dig this deeply but IIRC napi_tx didn't work well on the emulator. Maybe virtio_net.napi_tx=false is needed to the kernel command line?
I haven't dig this deeply but IIRC napi_tx didn't work well on the emulator. Maybe
virtio_net.napi_tx=falseis needed to the kernel command line?
That indeed was it! Will add the ip configuration commands and remove capabilities in a short moment.
I hit a roadblock, apparently the host (10.0.2.2) can be pinged now, but setting a nameserver or even using a known public IP address doesn't result in curl fetching any valid data.
setting a nameserver or even using a known public IP address doesn't result in curl fetching any valid data.
What error is curl reporting?
setting a nameserver or even using a known public IP address doesn't result in curl fetching any valid data.
What error is curl reporting?
Sorry for the late response, I was busy. curl itself just times out, this is what I currently have:
alfredneumayer@Alfreds-Mac-mini build % ./iwasm --addr-pool=10.0.2.15/8 --allow-resolve="*" ~/Projects/open/container2wasm/out.wasm
root@localhost:/# ip addr add 10.0.2.15/8 dev eth0
ip addr add 10.0.2.15/8 dev eth0
root@localhost:/# ip link set up eth0
ip link set up eth0
root@localhost:/# ip addr
ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 02:00:16:67:23:94 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/8 scope global eth0
valid_lft forever preferred_lft forever
root@localhost:/# busybox ping -c 3 10.0.2.2
busybox ping -c 3 10.0.2.2
PING 10.0.2.2 (10.0.2.2): 56 data bytes
64 bytes from 10.0.2.2: seq=0 ttl=255 time=9.825 ms
64 bytes from 10.0.2.2: seq=1 ttl=255 time=5.068 ms
64 bytes from 10.0.2.2: seq=2 ttl=255 time=5.148 ms
--- 10.0.2.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 5.068/6.680/9.825 ms
root@localhost:/# curl http://10.0.2.2:5001
curl http://10.0.2.2:5001
curl: (28) Failed to connect to 10.0.2.2 port 5001 after 132671 ms: Connection timed out
Changing iwasm's address pool to something like 0.0.0.0/0 doesn't help either.
Super interested in this!, ie. networking support from a c2w wasm binary running in my browser. I have a websocket to "network" service ready to go for something like this. Once ready for testing, feel free to ping me, happy to help testing, or help however i can.
For those that want to make use of SLIRP without a networking proxy, tested on WebAssembly Micro Runtime, I finally figured it out!
Turns out Out-Of-Band communication doesn't seem to be a concept the current socket APIs understand. Working around this issue and treating connect()s synchronously does the job.
Right now the way to enable an image with networking support is by using the RISCV/TinyEMU backend and building the image with the c2w --net option. I'll leave the enablement on x86 up to the reader, I'm happy with the result. :)
Though the Go side probably needs some adjustments to fully be upstream-worthy, I guess those count as finishing touches only.