multicast disabled on 8260_io/fcc_enet.c

multicast disabled on 8260_io/fcc_enet.c

[Samuel Osorio Calvo]

Hi all!

I was playing with a mpc8260 board and the latest ELDK version, 3.1.1 =
(linux 2.4.25) and face a strange behaviour:

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.

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???

Thanks to all,

Samuel.


Unclassified.

Re: multicast disabled on 8260_io/fcc_enet.c

[Alex Zeffertt]

On Mon, 13 Jun 2005 18:14:06 +0200
"Samuel Osorio Calvo" <samuel.osorio@nl.thalesgroup.com> wrote:

> Hi all!
> 
> I was playing with a mpc8260 board and the latest ELDK version, 3.1.1
> (linux 2.4.25) and face a strange behaviour:
> 
> 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.
> 
> 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???
> 


According to

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

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

Re: multicast disabled on 8260_io/fcc_enet.c

[Samuel Osorio Calvo]

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.
>>> Alex Zeffertt <ajz@cambridgebroadband.com> 06/14/05 10:31AM >>>

On Mon, 13 Jun 2005 18:14:06 +0200
"Samuel Osorio Calvo" <samuel.osorio@nl.thalesgroup.com> 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

Re: multicast disabled on 8260_io/fcc_enet.c

[Dan Malek]

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

Re: multicast disabled on 8260_io/fcc_enet.c

[Samuel Osorio Calvo]

Sorry for asking things that were solved, but I was not  able to find =
them, and I am a newbie in this world.
Anyhow, just thank you for the comment on the CRC, it looks like it is =
properly done in the new DENX release (3.1.1).

Samuel.


Unclassified.
>>> Dan Malek <dan@embeddededge.com> 06/16/05 03:03AM >>>

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

> Currently I have multicast working just be moving the return=20
> statement. It seems to work but I guess I did not face yet the=20
> 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=20
have
a function for computing CRCs, so I just placed the return early in the=20
function.
I believe there is a patch floating around that wrote a CRC function=20
(or used some
existing one), to compute the filter mask.  If the code has a CRC=20
function call,
then it will likely work.  If it doesn't have one, then you are running=20
on luck.  Either
the proper filter bit is set by some random reset bits, or you somehow=20
get the
right one set.  By default, the multicast filter may just catch=20
everything, forcing
the Linux IP stack to do the filtering at a higher level, not exactly=20
what you want. :-)

This has been discussed many times in the past.

Thanks.

	-- Dan