On Fri, Aug 12, 2005 at 12:02:46PM +0200, Henrik Nordstrom wrote:
> >This solves the problem quite nicely, and it is probably the simplest to
> >implement, but requires changing the hardware.
> >
> >I'm trying to figure out how to achieve the same effect with eth0 and tap0
> >(as opposed to eth0 an
On Thu, 11 Aug 2005, Jim C. Brown wrote:
Incidently, if you have eth0 and eth1, and both are connected to the same
LAN, then it works. Just set up vde_packet/pcacp on eth1, then packed tp the
host from the VDE will be sent out over eth1 and recieved back in eth0.
Right. Just don't set an IP on
On Thu, 11 Aug 2005, Oliver Gerlich wrote:
Couldn't we avoid these incompatibilities if we would route packets only on
the Ethernet level? If the Qemu networking setup on the host involves IP
addresses or such things, we're already on the wrong OSI layer I think...
From what I can tell there
On Thu, Aug 11, 2005 at 06:00:12PM +0100, Paul Brook wrote:
> > I guess this means that VDE would have to provide a kernel-layer
> > component which grabs the packets from eth0 and provides the faked eth0
> > for the Host OS...
>
> You can do all this with the standard linux tools. Something like
On Thu, Aug 11, 2005 at 06:24:51PM +0200, Oliver Gerlich wrote:
> Couldn't we avoid these incompatibilities if we would route packets only
> on the Ethernet level? If the Qemu networking setup on the host involves
> IP addresses or such things, we're already on the wrong OSI layer I think...
>
> I guess this means that VDE would have to provide a kernel-layer
> component which grabs the packets from eth0 and provides the faked eth0
> for the Host OS...
You can do all this with the standard linux tools. Something like the
following(untested) script. ifrename is part of the Linus Wireles
Henrik Nordstrom wrote:
On Wed, 10 Aug 2005, Jim C. Brown wrote:
[...]
The above should work for most situations where the host is a just a
host on the LAN, but if the host is a LAN server for broadcast Ethernet
protocols such as DHCP some additional configuration of each such
service may be
On Wed, 10 Aug 2005, Jim C. Brown wrote:
I was thinking that perhaps vde_packet could be modified to use a tap device
(for example tap0). Since the guests can't communicate to the address thats on
tap0, it doesn't matter what address it gets - the host address of tap0 and the
ip addresses of the
On Thu, Aug 04, 2005 at 12:14:53PM +0200, Henrik Nordstrom wrote:
> For host->guest packets the RAW sockets demonstrated earlier is fine if
> you accept that the guest packets is also duplicated on the local lan. I
> do not know of a method to have host->guest packets sent cleanly without
> dupl
On Thu, Aug 04, 2005 at 12:14:53PM +0200, Henrik Nordstrom wrote:
> On Tue, 12 Jul 2005, Jim C. Brown wrote:
>
> >I just tried this with libnet 1.1 (1.1.2.1 to be specific), and it doesn't
> >seem to work. Pings do not go through. I only handled the vde -> host case
> >though, do I need to do anyt
On Tue, 12 Jul 2005, Jim C. Brown wrote:
I just tried this with libnet 1.1 (1.1.2.1 to be specific), and it doesn't
seem to work. Pings do not go through. I only handled the vde -> host case
though, do I need to do anything special for host -> vde packets?
Did you fake the ARP response to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oliver Gerlich wrote:
> Ross Kendall Axe schrieb:
>
>>>Oliver Gerlich wrote:
>>>
>>>
>The "problem" is that I start vde_switch and the bridging not at boot,
>but when I want to run Qemu. So then I have to restart Samba to bind to
>to br0 i
On Tue, Jul 12, 2005 at 04:49:08AM +0200, Henrik Nordstrom wrote:
> It you forget about Ethernet and instead send the packet as a raw IP
> packet then it should reach the host, but you must then fake ARP
> responses on behalf of the host.
>
I just tried this with libnet 1.1 (1.1.2.1 to be speci
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ross Kendall Axe schrieb:
> Oliver Gerlich wrote:
>
>>>The "problem" is that I start vde_switch and the bridging not at boot,
>>>but when I want to run Qemu. So then I have to restart Samba to bind to
>>>to br0 instead of eth0. Not so much of a proble
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oliver Gerlich wrote:
>
> The "problem" is that I start vde_switch and the bridging not at boot,
> but when I want to run Qemu. So then I have to restart Samba to bind to
> to br0 instead of eth0. Not so much of a problem though... Only I don't
> know
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 it
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
> >
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
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 04:21:31AM +0200, Henrik Nordstrom wrote:
> On Sun, 10 Jul 2005, Jim C. Brown wrote:
>
> >The best solution is to use a vde_switch with libpcap and libnet. This
> >allows
> >intercepting packets meant for the guests (via libnet) and forwarding them
> >thru
> >vde.
>
> In
On Sun, 10 Jul 2005, Jim C. Brown wrote:
The best solution is to use a vde_switch with libpcap and libnet. This allows
intercepting packets meant for the guests (via libnet) and forwarding them thru
vde.
Interesting idea. Would make full qemu networking truly a no-brainer.
Should even be poss
On Sun, 10 Jul 2005, Oliver Gerlich wrote:
Could you explain how you integrated vde_switch and bridging with your
current system? Do you start everything at boot and accept that this
changes the system-wide network configuration, or do you use some
bridging trick to avoid this?
I am not curren
On Sun, Jul 10, 2005 at 08:23:17PM +0200, Oliver Gerlich wrote:
> > The best solution is to use a vde_switch with libpcap and libnet. This
> > allows
> > intercepting packets meant for the guests (via libnet) and forwarding them
> > thru
> > vde. libpcap allows for packets in vde to be passed on
> DHCP is Ethernet broadcast based, not IP.
Not that it matters in this case but strictly speaking DHCP
is an IP protocol, using UDP as its transport and the request
goes to IP broadcast address of 255.255.255.255.
> You could also run a local DHCP server on tap0, configured with the
> address s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim C. Brown schrieb:
> On Sun, Jul 10, 2005 at 06:42:30PM +0200, Henrik Nordstrom wrote:
>
>>On Sun, 10 Jul 2005, Oliver Gerlich wrote:
>>
>>
>>>what is the best solution to connect the vde "switch" to my real LAN so
>>>that Qemu guests get IPs from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Henrik Nordstrom schrieb:
> On Sun, 10 Jul 2005, Oliver Gerlich wrote:
>
>> what is the best solution to connect the vde "switch" to my real LAN so
>> that Qemu guests get IPs from my LAN-wide DHCP server?
>
>
> bridgeing of your ethernet interface
On Sun, Jul 10, 2005 at 06:42:30PM +0200, Henrik Nordstrom wrote:
> On Sun, 10 Jul 2005, Oliver Gerlich wrote:
>
> >what is the best solution to connect the vde "switch" to my real LAN so
> >that Qemu guests get IPs from my LAN-wide DHCP server?
>
> bridgeing of your ethernet interface and the TA
On Sun, 10 Jul 2005, Oliver Gerlich wrote:
what is the best solution to connect the vde "switch" to my real LAN so
that Qemu guests get IPs from my LAN-wide DHCP server?
bridgeing of your ethernet interface and the TAP interface connecting to
vde is undoubtly the best if you want to provide f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
what is the best solution to connect the vde "switch" to my real LAN so
that Qemu guests get IPs from my LAN-wide DHCP server?
So far I've experimented with bridging tap0 and eth0 so that the Qemu
guests are transparently on my LAN and get IPs
29 matches
Mail list logo
