Re: multicast disabled on 8260_io/fcc_enet.c

Currently I have multicast working just be moving the return statement. It =
seems to work but I guess I did not face yet the problems that caused the =
code to be commented.
Let's say it works in an unreliable way....

Samuel.


Unclassified.

quoted

quoted

Alex Zeffertt [off-list ref] 06/14/05 10:31AM >>>

On Mon, 13 Jun 2005 18:14:06 +0200
"Samuel Osorio Calvo" [off-list ref] wrote:

Hi all!
=20
I was playing with a mpc8260 board and the latest ELDK version, 3.1.1
(linux 2.4.25) and face a strange behaviour:
=20
I was trying to make multicast work and everything seemed to be ok
(/proc/net/igmp, /proc/net/dev_mcast), making a local ping to
224.0.0.1 returns localhost as part of the group, etc....BUT it was
not possible to contact the board to the group it had joined from the
network. I was digging into the kernel drivers and found a strange
return statement just in teh start of the funciton set_multicast_list
(arround line 1471 of the file mentioned in the subject of the mail).
I moved the return to the end of the function and everything worked
perfectly.
=20
My question is wether the return statement was moved at the starting
of the function due to some bug of the set_multicast_list code or it
was just a typo???
=20

According to

	http://ozlabs.org/pipermail/linuxppc-embedded/2005-May/018529.html=
=20

it would seem that multicast is not correctly implemented and has been
effectively commented out.  This also stops promisc mode working.  I
have removed the return in my source tree and promisc mode now works
fine. I can't say whether multicast works.  Maybe you could just give it
a try and see what happens....

Alex

On Jun 15, 2005, at 9:14 AM, Samuel Osorio Calvo wrote:

Currently I have multicast working just be moving the return 
statement. It seems to work but I guess I did not face yet the 
problems that caused the code to be commented.
Let's say it works in an unreliable way....

When I wrote the original code I copied the old SCC driver and didn't 
have
a function for computing CRCs, so I just placed the return early in the 
function.
I believe there is a patch floating around that wrote a CRC function 
(or used some
existing one), to compute the filter mask.  If the code has a CRC 
function call,
then it will likely work.  If it doesn't have one, then you are running 
on luck.  Either
the proper filter bit is set by some random reset bits, or you somehow 
get the
right one set.  By default, the multicast filter may just catch 
everything, forcing
the Linux IP stack to do the filtering at a higher level, not exactly 
what you want. :-)

This has been discussed many times in the past.

Thanks.

	-- Dan