On Sun, 10 Jul 2005, Jim C. Brown wrote:
Yes, but if one was running multiple qemu guests, it would be cleaner to
implement this thru vde_switch instead of in qemu directly. That way eth0 is
intercepted by only a single process. (Also no worries about having permissions
to intercept packets and
On Mon, Jul 11, 2005 at 09:50:11AM +0200, Henrik Nordstrom wrote:
On Sun, 10 Jul 2005, Jim C. Brown wrote:
I didn't mean to implement this in qemu directly, but rather in a helper
similar to vdeq, but the primary method should be via vde_switch. Having
this shortcut helper is a future
Hi
I wanted to submit a new OS image (CentOS 4 on x86) to FreeOSZoo.org.
I'm getting taken to what looks like a search or cyber-squatter's site.
Any idea what's up?
$ dig freeoszoo.org +nodebug +noadditional +nostats +noquery
; DiG 8.3 freeoszoo.org +nodebug +noadditional +nostats
+noquery
Dear QEMU developers!
This is my first post to this list so please don't be very angry
if I'm doing something wrong.
I've encountered some network related bug when using qemu with tun
and I'm willing to debug it but could you please provide some help.
The bug isn't new, I believe it's described
On Mon, Jul 11, 2005 at 11:02:04AM -0400, Jim C. Brown wrote:
b) can't talk to the host itself. This is due to the packets going
directly to the wire and never really seen by the host stack. Not sure
yet if there is an easy way out, but I suppose it may be possible to set
up a dummy
On Mon, 11 Jul 2005, Jim C. Brown wrote:
I tried using libnet 1.0 to send the packets, but that did not help. Also
tried libnet 1.1, that actually allowed the host to be pinged by the guest -
part of the time. It also caused pings on the same lan (from the guest) to fail
as well sometimes, so
