I'm now exploring the eth-multiplexer project written by
Zheng. AFAICT, the aim of this project is to provide a much more
flexible network strategy by allowing new virtual devices and filters
and by dispatching the packets received via a (single) physical device
to corresponding clients connected to one of the virtual devices.
My problem is, in short, the following: I follow this HOWTO:
http://www.bddebian.com:8888/~hurd-web/user/zhengda/howto/ and setup
the devnode, eth-multiplexer, and modified pfinet translators. When I
try to do lookups under the multiplexer's virtual filesystem,
everything works okay, which makes me think that both the devnode and
eth-multiplexer are (at least) alive. When I try to gracefully
settrans -g the pfinet translator, it quietly goes away, without
messages like "Device busy" which occur when translators
hang. However, when I do apt-get update, it (very slowly) fetches me
~800B, then hangs for around 6-7 minutes and then stops with warnings
and errors about failures in fetching data.
Taking into consideration that neither antrik (running Hurd on bare
metal) nor Zheng (running Hurd not in QEMU) experience no problems of
the kind, and, moreover, when antrik tried the exact sequence of
commands I had used, it worked for him, I suspect QEMU's user-space
network of getting into the way of eth-multiplexer in my case.
I put much hope into my old box, but I forgot that it had some weird
software RAID stuff embedded into the motherboard, which I cannot turn
off. When I tried to install Debian Hurd on this box, the installation
system could not detect my hard drives at all.
antrik suggested trying a different virtualization solution, so I'm
asking whether anybody could recommend me something suitable, since
I'd prefer not to grope in ignorance for something which is actually
Also, I remember Zheng having been given an account on flubber (I hope
I remember things well) last summer and I wonder whether it is
possible for me to get an account too :-) Anyways, the main question
here is whether this solution is suitable for testing
eth-multiplexer. What worries me most about this idea is the fact that
Zheng *still* uses a local virtualization solution, instead of his
remote account, which might mean that eth-multiplexer has problems
running on public hurd boxen...