[Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)

Matthew Howkins rpcemu-list at howkins.me.uk
Thu Nov 22 11:32:32 PST 2018


> QEMU uses a library called SLIRP, which contains its own ethernet stack,
> including servers to do DHCP, DNS, etc.  When a QEMU VM wants to use the
> network,
> the default mode is to push packets into SLIRP which will NAT them and emit
> them from the QEMU app as if they were native connections.  This enables
> no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
> In principle, doing the same for RPCEmu would allow no-setup networking
> across all the platforms it supports.
>

I have previously done some work integrating Slirp with RPCEmu, and got
further than you, because I can send and receive network packets :)

There's a lot to think about before integrating and releasing the code as
is, but the ultimate aim is to get user-friendly networking with the
absolute minimum number of configuration steps.

One of the challenges of incorporating Slirp was that there are so many
derivatives of the original code base, and they tend to differ in their
suitability. Here are some of the things I've considered when selecting
which Slirp code to integrate:

* Not all Slirp derivatives are easy to extract and integrate with RPCEmu.
The copies in QEMU and VirtualBox are fully-featured, but are very
difficult to integrate.
* Not all Slirp code is portable to 64-bit platforms or Windows, as the
original code was only for Unix.
* Only some Slirp code has good support for DHCP.
* Only some Slirp codebases support port-forwarding, which I consider a
highly desirable feature.
* Few Slirp codebases support DNS proxying, and this I consider an
essential feature (see below).

The DNS proxying I consider an essential feature, because without it the
user would not only have to manually configure DNS (which would seem odd
given that the rest of the config would be automatic), but they would have
to change their RISC OS config every time they moved to another network,
which laptop users would be very likely to do.

I got to the point of having Slirp integrated and working on Linux, though
without support for the DNS proxying feature. However, testing showed up
deficiencies and bugs in the other parts of the network code including the
EtherRPCEm driver, and that is where most of the recent effort has been
expended.

I expect that there's still a lot to do on networking, but the long-term
plan is definitely to go with Slirp (or if not Slirp, something
equivalent). This would become the recommended networking option, and the
most portable option.

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riscos.info/pipermail/rpcemu/attachments/20181122/5e3a04f8/attachment.html>


More information about the RPCEmu mailing list