[Qemu-devel] multicast and the eepro100 driver

[Qemu-devel] multicast and the eepro100 driver

[Jeff Hoare]

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---
root@junos01% 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

Re: [Qemu-devel] multicast and the eepro100 driver

[Stefan Weil]

Hi Jeff,

eepro100.c is my work, so maybe I can help you.

First of all: there exists a newer version of eepro100.c which
fixes some bugs of the CVS version and largely improves
support for big endian hosts and targets. Get it from
http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eepro100.c?op=file&rev=0&sc=0

I am still working on this new version, because support for big endian
hosts is still untested.

If you define macro DEBUG_EEPRO100 in eepro100.c, you will get
debugging messages which show the frames sent and received.

Multicast frames should be received, but I never tested this,
so maybe there is a bug, and I know that I did not implement
all functions needed for multicast.

Look in the code for function nic_receive and try to remove the
return statement which aborts the reception of unwanted multicast
frames. You will get too many multicast frames - but perhaps
that is better than getting none at all :-)

Regards
Stefan

Jeff Hoare schrieb:
> 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

Re: [Qemu-devel] multicast and the eepro100 driver

[Nicolas Guilbaud]

Hi Stefan,

I experienced the same issue as Jeff, so removing the 'return'  
statement in nic_receive works for multicast (at least 224.0.0.5)  
with your latest code.

Thanks !
Nicolas.










> Hi Jeff,
>
> eepro100.c is my work, so maybe I can help you.
>
> First of all: there exists a newer version of eepro100.c which
> fixes some bugs of the CVS version and largely improves
> support for big endian hosts and targets. Get it from
> http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eepro100.c? 
> op=file&rev=0&sc=0
>
> I am still working on this new version, because support for big endian
> hosts is still untested.
>
> If you define macro DEBUG_EEPRO100 in eepro100.c, you will get
> debugging messages which show the frames sent and received.
>
> Multicast frames should be received, but I never tested this,
> so maybe there is a bug, and I know that I did not implement
> all functions needed for multicast.
>
> Look in the code for function nic_receive and try to remove the
> return statement which aborts the reception of unwanted multicast
> frames. You will get too many multicast frames - but perhaps
> that is better than getting none at all :-)
>
> Regards
> Stefan
>
> Jeff Hoare schrieb:
> > 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
>

[Qemu-devel] Re: multicast and the eepro100 driver

[Bjørn Mork]

Stefan Weil <weil@mail.berlios.de> writes:

> eepro100.c is my work, so maybe I can help you.
>
> First of all: there exists a newer version of eepro100.c which
> fixes some bugs of the CVS version and largely improves
> support for big endian hosts and targets. Get it from
> http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eepro100.c?op=file&rev=0&sc=0
>
> I am still working on this new version, because support for big endian
> hosts is still untested.
>
> If you define macro DEBUG_EEPRO100 in eepro100.c, you will get
> debugging messages which show the frames sent and received.
>
> Multicast frames should be received, but I never tested this,
> so maybe there is a bug, and I know that I did not implement
> all functions needed for multicast.

Hello,

I just tried your new version of eepro100.c and can confirm that
multicast reception does work with this version.  Found one bug (which
does not prevent it from working):  The length of the multicast list
seems have a byte/number confusion.  I get:



EE100   set_multicast_list      multicast list, 0 entries
EE100   set_multicast_list      multicast list, 0 entries
EE100   set_multicast_list      multicast list, 6 entries
EE100   set_multicast_list      multicast entry  01 00 5e 00 00 01
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast list, 12 entries
EE100   set_multicast_list      multicast entry  01 00 5e 00 00 01
EE100   set_multicast_list      multicast entry  01 00 5e 00 00 06
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast list, 18 entries
EE100   set_multicast_list      multicast entry  01 00 5e 00 00 01
EE100   set_multicast_list      multicast entry  01 00 5e 00 00 05
EE100   set_multicast_list      multicast entry  01 00 5e 00 00 06
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00
EE100   set_multicast_list      multicast entry  00 00 00 00 00 00

This patch fixes this:

--- /home/bjorn/tmp/eepro100.c	2007-12-18 14:52:48.000000000 +0100
+++ /usr/local/src/qemu-0.9.0+20070816/hw/eepro100.c	2007-12-18 15:37:40.000000000 +0100
@@ -905,7 +903,7 @@
             TRACE(OTHER, logout("configuration: %s\n", nic_dump(&s->configuration[0], 16)));
             break;
         case CmdMulticastList:
-            set_multicast_list(s, s->tx.tbd_array_addr & BITS(13, 0));
+            set_multicast_list(s, (s->tx.tbd_array_addr & BITS(13, 0)) / 6);
             break;
         case CmdTx:
             tx_command(s);


Thanks for your work on this!



Bjørn
-- 
How can you say that old people are inherently superior to unborn
people