[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Where to run the Hurd

From: Da Zheng
Subject: Re: Where to run the Hurd
Date: Sat, 27 Jun 2009 20:45:43 +0800
User-agent: Thunderbird (Macintosh/20090302)


Sergiu Ivanov wrote:

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...
I failed to install Hurd in Q - the qemu for Mac OS X, so I cannot test eth-multiplexer in qemu. Could you just run the modified pfinet directly on gnumach? So we can test which component has the problem. Of course, you have to use the bpf patch I sent to the mailing list.

eth-mulitplexer needs to set the ethernet card to the promiscuous mode. I wonder if that can cause the problem. My suggestion is testing them internally. For example, you can setup two pfinets on the same eth-multiplexer and write some testing programs to transmit packets between them.

Zheng Da

reply via email to

[Prev in Thread] Current Thread [Next in Thread]