listhelper-moderate
[Top][All Lists]
Advanced

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

Qemu-devel post from address@hidden requires approval


From: qemu-devel-owner
Subject: Qemu-devel post from address@hidden requires approval
Date: Wed, 11 Jul 2007 07:01:16 -0400

As list administrator, your authorization is requested for the
following mailing list posting:

    List:    address@hidden
    From:    address@hidden
    Subject: multicast and the eepro100 driver
    Reason:  Post by non-member to a members-only list

At your convenience, visit:

    http://lists.nongnu.org/mailman/admindb/qemu-devel
        
to approve or deny the request.
--- Begin Message --- Subject: multicast and the eepro100 driver Date: Wed, 11 Jul 2007 20:52:41 +1200 User-agent: Thunderbird 1.5.0.10 (X11/20060911)
Hi,

I have been using a recent snapshot version of QEMU (5th July, 2007)
which has the eepro100 Ethernet driver, in order to set up a couple of
routing engines (one each in a separate QEMU VM). While I have basic
connectivity between each engine (including telnet between each) it
seems that the RIP/OSPF routing updates do not pass between them (I have
let to try a TCP based one). These are multicast UDP packets, which seem
to be output the FXP0 interface (see tcpdump below) and I can even see
them on the TAP0 interface, but they don't appear to be received by the
other VM. The two VM are connected using VDE (with different values for
HDA & macaddresses). Does the emulated Ethernet driver receive multicast
udp packets? I assumed that the virtual switch is forwarding the packets
since they are received by the TAP0 interface.

Anyway any information or light that could be shed would be appreciated.

Regards jeff

Use VDE to start QEMU---
vdeq /usr/local/bin/qemu -no-kqemu  -hda
/home/jhoare/qemu/images/juniper01.img -net
nic,vlan=0,macaddr=52:54:00:12:34:56,model=i82559er -net
nic,vlan=1,macaddr=52:54:00:12:34:57,model=i82559er -localtime
-nographic -m 96 -net vde

output from vde_switch---
vde: port/allprint
0000 DATA END WITH '.'
Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
  -- endpoint ID 0006 module tuntap      : tap0
Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
  -- endpoint ID 0007 module unix prog   : vdeqemu user=root PID=5311 
SOCK=/var/run/vde.ctl.05311-00000
Port 0003 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
  -- endpoint ID 0009 module unix prog   : vdeqemu user=root PID=5327 
SOCK=/var/run/vde.ctl.05327-00000


freebsd FXP0 Interface---
address@hidden tcpdump -i fxp0
verbose output suppressed, use <detail> or <extensive> for full protocol
decode
Listening on fxp0, capture size 96 bytes

19:32:08.503194 Out IP 192.168.254.1.router > 224.0.0.9.router: RIPv2,
Response, length: 64
19:32:08.905539 Out IP 192.168.254.1 > 224.0.0.5: OSPFv2, Hello, length: 44
19:32:18.328338 Out IP 192.168.254.1 > 224.0.0.5: OSPFv2, Hello, length: 44

TAP0 Interface (also connected to vde switch)---
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
19:54:19.087172 IP 192.168.254.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello,
length: 44
19:54:43.394726 IP 192.168.254.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello,
length: 44




--- End Message ---
--- Begin Message --- Subject: confirm 8ba838562200a0bea505e3d5ac747b789317b84f
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message.  Do this if the message is
spam.  If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list.  The Approved: header can also appear in the first line
of the body of the reply.

--- End Message ---

reply via email to

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