qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Weil
Subject: Re: [Qemu-devel] multicast and the eepro100 driver
Date: Wed, 11 Jul 2007 19:11:44 +0200
User-agent: IceDove 1.5.0.12 (X11/20070607)

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




reply via email to

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