On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
Attached is a patch proposition to allow opennig an existing tun (already
configured by root).
This patch can work only on Linux as it make no change into the code for BSD.
Please make open comment about this to improve it or to let my know w
On Sat, 1 Oct 2005, Jim C. Brown wrote:
Well I tried it myself and it doesn't work. eth0 gets an IP of 1.1.1.1 but
nothing is pingable.
1.1.1.1 is not a QEMU given IP.
Try manually assigning the IP 10.0.2.15/24(255.255.255.0) to the quest
with a default route to 10.0.2.2. This should work.
On Sat, 1 Oct 2005, Jim C. Brown wrote:
Depends on how intellegent the switch is. (Forwarding back only those packets
which are addressed to the host itself wouldn't necessarily cause an infinite
loop. Tho the switch would probably be smarter if it dropped such packets
outright.)
Imagine havin
Well I tried it myself and it doesn't work. eth0 gets an IP of 1.1.1.1 but
nothing is pingable.
I tried to make the packet sizes larger than 300 bytes just in case that was
the cause of the error (tho thats unlikely imvho), but that just got me a
syntax error from lua.
On Fri, Sep 30, 2005 at 04:
Jim C. Brown a écrit :
On Sat, Oct 01, 2005 at 10:24:03PM +0200, Jean-Christian de Rivaz wrote:
And qemu already supports that, via the -tun-fd option.
Can you please give me an exemple how to use the -tun-fd option to open
an existing tun (i.e: tun-alice) ? This option only work for already
On Sat, Oct 01, 2005 at 02:50:59PM +0100, Paul Brook wrote:
> On Saturday 01 October 2005 14:07, Jim C. Brown wrote:
> > On Sat, Oct 01, 2005 at 01:30:06PM +0200, Oliver Gerlich wrote:
> > > That means it would work if the host NIC is connected to a switch? Then
> > > the switch would send packets
On Sat, Oct 01, 2005 at 10:24:03PM +0200, Jean-Christian de Rivaz wrote:
> >And qemu already supports that, via the -tun-fd option.
>
> Can you please give me an exemple how to use the -tun-fd option to open
> an existing tun (i.e: tun-alice) ? This option only work for already
> opened tap/tun
Attached is a patch proposition to allow opennig an existing tun
(already configured by root).
This patch can work only on Linux as it make no change into the code for
BSD.
Please make open comment about this to improve it or to let my know why
this if not a good thing...
--
Jean-Christian
Henrik Nordstrom a écrit :
On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
You point the real question: why it has been impossible to get
accepted any patch that fixed this. I has proposed one myself and I
get no comment at all. I see similar effort from others and obviousely
there failed
You point the real question: why it has been impossible to get accepted
any patch that fixed this. I has proposed one myself and I get no
comment at all. I see similar effort from others and obviousely there
failed almost the same way. No getting any valuable comment about why a
idea proposed
On Sat, 1 Oct 2005, Oliver Gerlich wrote:
That means it would work if the host NIC is connected to a switch? Then
the switch would send packets from the guest which are meant for the
host back to the host NIC and everything's fine! Or did I misunderstand
that now?
In this kind of setup you wil
On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
You point the real question: why it has been impossible to get accepted any
patch that fixed this. I has proposed one myself and I get no comment at all.
I see similar effort from others and obviousely there failed almost the same
way. No gett
On Saturday 01 October 2005 14:07, Jim C. Brown wrote:
> On Sat, Oct 01, 2005 at 01:30:06PM +0200, Oliver Gerlich wrote:
> > That means it would work if the host NIC is connected to a switch? Then
> > the switch would send packets from the guest which are meant for the
> > host back to the host NIC
On Sat, Oct 01, 2005 at 01:30:06PM +0200, Oliver Gerlich wrote:
> That means it would work if the host NIC is connected to a switch? Then
> the switch would send packets from the guest which are meant for the
> host back to the host NIC and everything's fine! Or did I misunderstand
> that now?
>
>
On Sat, Oct 01, 2005 at 10:12:41AM +0200, Jean-Christian de Rivaz wrote:
> Jim C. Brown a ?crit :
>
> >Typically, tapX (tap0, tap1, etc) names are reserved for tap devices
> >(ethernet
> >frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP
> >frames).
> >
> >qemu breaks those rul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim C. Brown schrieb:
> On Fri, Sep 30, 2005 at 03:13:21PM -0700, Don Kitchen wrote:
>
[...]
>
>>I'm interested in the handling of ethernet frames because I haven't been
>>able to get the bridge to pass packets between added interfaces (yes,
>>they'r
Jim C. Brown a écrit :
Typically, tapX (tap0, tap1, etc) names are reserved for tap devices (ethernet
frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP frames).
qemu breaks those rules and calls the tap device that it creates tun0. This is
done for reasons that Fabrice has not
[EMAIL PROTECTED]/9b<[EMAIL PROTECTED]>R2p$7$F$*$j$^$9!#$b(B
[EMAIL PROTECTED]>@\M6$&;[EMAIL PROTECTED])$C$F$*$j$^$9!#(B [EMAIL PROTECTED](B
$BCO0h2q0w(B([EMAIL
PROTECTED](B)$B$+$i5.J}$N%"%I%l%9$XD>@\%a!<%k$,FO$-$^$7$?$N$G!"(B
$BLBOG$G$J$1$l$P!"0lEY$4GRFID:$-$?$/;W$$$^$9!#(B
$B!V$J$s$H$J$
18 matches
Mail list logo
