[Feature Request] Raw Socket Support for Network Discovery Use Cases

[fnicolelli-ls]

Hello team 👋
I'm exploring WASM as a sandboxed plugin runtime for network monitoring and discovery tools. The goal is to allow modular components to perform network operations within a controlled, capability-gated environment. However, the current lack of raw socket support in WASI makes this architecture infeasible for many common network discovery patterns.

Specific Operations Requiring Raw Sockets

Operation	Socket Type	Purpose
ARP Scanning	AF_PACKET, SOCK_RAW	Layer 2 device discovery on local network
ICMP Ping	AF_INET, SOCK_RAW, IPPROTO_ICMP	Host reachability detection
NDP (IPv6)	AF_INET6, SOCK_RAW, IPPROTO_ICMPV6	IPv6 neighbor discovery
DHCP Capture	AF_INET, SOCK_DGRAM on ports 67/68	Passive network monitoring

Q:

1. Has raw socket support been previously discussed and rejected?
2. Would a limited subset (e.g., ICMP only) be more acceptable than full raw socket access?

Thanks a lot!

[badeend]

Hi!

I'm exploring WASM as a sandboxed plugin runtime (...) the current lack of raw socket support in WASI makes this architecture infeasible

Just to clear up a potential misunderstanding: it sounds like your application would act as the WASM host. In that case, you are not limited to standardized WASI interfaces. A host is free to expose additional, non-standard APIs to guest modules as needed. For example, you could expose the standard WASI sockets interface alongside a custom raw-socket or packet-level interface.

WASI defines a portable, standardized subset of functionality, not the full boundary of what a WASM runtime is allowed to provide. The absence of raw socket support in WASI does not, by itself, make your architecture infeasible.

With that out of the way:

Has raw socket support been previously discussed and rejected? Would a limited subset (..) be more acceptable?

To the best of my knowledge, raw socket support has not been discussed before and it has not been explicitly rejected either.

There are no hard rules about what is or is not "acceptable", but in practice, for an interface to be included in WASI it generally needs to meet a few criteria (skipping over some nuance):

• It should be broadly useful, meaning it benefits multiple independent users or use cases.
• It must be portable, with well-defined and consistent behavior across major platforms (e.g. Linux, macOS, Windows).
• It must be implemented by at least two independent, production-grade WASI runtimes.
• For this particular area, POSIX compatibility is also an important consideration.

Ultimately, adding any new WASI interface requires someone who is willing to put in the work to drive the proposal, design, and implementation.