On Jun 9, 4:21 am, Janardhan wrote:
> Hi,
> I have a mulitcast server program. I have added the interface to the
> mulitcast group and also binded on that interface to receive mulitcast
> packets. When the mulitcast packets arrive I am not able to receive
> the mulitcast packets. This is happening when I do the bind to the
> interface on which i want to listen. Instead if i do a bind on
> INADDR_ANY, then I am able to receive the mulitcast packets.
>
> Is there any problem with the vxWorks IP stack?
>

Here is a list of information you did not provide:

- What version of VxWorks you're using

- What CPU arch/BSP you're running it on

- What network controller you're trying to send/receive multicasts
with

- What driver you're using with this controller

- Does your target board have more than one network interface

Yes, all of this matters.

If you have more than one network interface, you must join the
multicast group using the right one. For this, you may need to use an
IP_MULTICAST_IF setsockopt() call. Also, you did not bzero() the
ipMreq structure in your code.

If the driver for your network controller is broken, it may not be
programming the multicast filter correctly. This will stop you
receiving multicast traffic. If you wrote your own driver, it may be
broken. If you're using some of the older drivers shipped with
VxWorks, it may also be broken. (We can't tell though, since you
didn't tell us what version of VxWorks you have.)

-Bill

On Jun 9, 9:42 pm, noiset...@gmail.com wrote:
> On Jun 9, 4:21 am, Janardhan wrote:
>
> > Hi,
> > I have a mulitcast server program. I have added the interface to the
> > mulitcast group and also binded on that interface to receive mulitcast
> > packets. When the mulitcast packets arrive I am not able to receive
> > the mulitcast packets. This is happening when I do the bind to the
> > interface on which i want to listen. Instead if i do a bind on
> > INADDR_ANY, then I am able to receive the mulitcast packets.
>
> > Is there any problem with the vxWorks IP stack?
>
> Here is a list of information you did not provide:
>
> - What version of VxWorks you're using
>
> - What CPU arch/BSP you're running it on
>
> - What network controller you're trying to send/receive multicasts
> with
>
> - What driver you're using with this controller
>
> - Does your target board have more than one network interface
>
> Yes, all of this matters.
>
> If you have more than one network interface, you must join the
> multicast group using the right one. For this, you may need to use an
> IP_MULTICAST_IF setsockopt() call. Also, you did not bzero() the
> ipMreq structure in your code.
>
> If the driver for your network controller is broken, it may not be
> programming the multicast filter correctly. This will stop you
> receiving multicast traffic. If you wrote your own driver, it may be
> broken. If you're using some of the older drivers shipped with
> VxWorks, it may also be broken. (We can't tell though, since you
> didn't tell us what version of VxWorks you have.)
>
> -Bill

Bill,
Thanks for the reply. Here are the answers for your questions,

- What version of VxWorks you're using
VxWorks 6.4

- What CPU arch/BSP you're running it on
Power PC
> - What network controller you're trying to send/receive multicasts
> with
Broadcom BCM5650X Ethernet switch.

> - What driver you're using with this controller
Provided by broadcom.

> - Does your target board have more than one network interface
Yes.

> Yes, all of this matters.
>
> If you have more than one network interface, you must join the
> multicast group using the right one. For this, you may need to use an
> IP_MULTICAST_IF setsockopt() call. Also, you did not bzero() the
> ipMreq structure in your code.

OK, will add this and try it out.

> If the driver for your network controller is broken, it may not be
> programming the multicast filter correctly. This will stop you
> receiving multicast traffic. If you wrote your own driver, it may be
> broken. If you're using some of the older drivers shipped with
> VxWorks, it may also be broken. (We can't tell though, since you
> didn't tell us what version of VxWorks you have.)


> -Bill

On Jun 11, 7:32 am, Janardhan wrote:
> On Jun 9, 9:42 pm, noiset...@gmail.com wrote:
>
>
>
> > On Jun 9, 4:21 am, Janardhan wrote:
>
> > > Hi,
> > > I have a mulitcast server program. I have added the interface to the
> > > mulitcast group and also binded on that interface to receive mulitcast
> > > packets. When the mulitcast packets arrive I am not able to receive
> > > the mulitcast packets. This is happening when I do the bind to the
> > > interface on which i want to listen. Instead if i do a bind on
> > > INADDR_ANY, then I am able to receive the mulitcast packets.
>
> > > Is there any problem with the vxWorks IP stack?
>
> > Here is a list of information you did not provide:
>
> > - What version of VxWorks you're using
>
> > - What CPU arch/BSP you're running it on
>
> > - What network controller you're trying to send/receive multicasts
> > with
>
> > - What driver you're using with this controller
>
> > - Does your target board have more than one network interface
>
> > Yes, all of this matters.
>
> > If you have more than one network interface, you must join the
> > multicast group using the right one. For this, you may need to use an
> > IP_MULTICAST_IF setsockopt() call. Also, you did not bzero() the
> > ipMreq structure in your code.
>
> > If the driver for your network controller is broken, it may not be
> > programming the multicast filter correctly. This will stop you
> > receiving multicast traffic. If you wrote your own driver, it may be
> > broken. If you're using some of the older drivers shipped with
> > VxWorks, it may also be broken. (We can't tell though, since you
> > didn't tell us what version of VxWorks you have.)
>
> > -Bill
>
> Bill,
> Thanks for the reply. Here are the answers for your questions,
>
> - What version of VxWorks you're using
> VxWorks 6.4
>
> - What CPU arch/BSP you're running it on
> Power PC

Arrrrgh. Could you have not found it within yourself to at least say
_WHICH_ PowerPC CPU it is?

> - What network controller you're trying to send/receive multicasts
> > with
>
> Broadcom BCM5650X Ethernet switch.
>
> > - What driver you're using with this controller
>
> Provided by broadcom.

No no no. You misunderstand the question. When I said "network
interface" I meant the ethernet interface that you're binding to in
VxWorks. That is, when run "muxShow()" at the target shell, you see a
list of interfaces. I'm talking about those, NOT the Broadcom switch
chip.

Now, based on the information you've presented, I suspect that you
have one of these:

http://www.radisys.com/products/data...asheetsid=1453

(If I'm wrong, please correct me.)

It's PPC-based, has a BCM5650X, and a VxWorks BSP. Now, the key piece
of information about this board is that the management CPU -- which is
where VxWorks runs -- is a Freescale MPC8548. This is what I was
hoping you would tell me, because I happen to know that MPC8548 uses
built-in ETSEC ethernet controllers. If you are running VxWorks on the
MPC8548 management CPU, then it's the ETSEC ports that you're using to
receive your multicast traffic _NOT_ the Broadcom switch controller.

Do you understand this?

Now.

I happen to also know that in VxWorks 6.4, there's a bug in the etsec
driver that breaks the multicast filtering. (It's fixed in 6.5. 6.6
and later use a new VxBus driver that also works correctly.) This
means the ethernet port will discard multicast frames.

If you are in fact using this board, you can attempt the following
workaround:

- Obtain a pointer to the MUX cookie for the etsec port you're using.
You can do this as follows

void * pCookie;
pCookie = muxTkCookieGet ("etsec", 0);

- Use the cookie with muxIoctl() to set the IFF_ALLMULTI flag:

muxIoctl (pCookie, EIOCSFLAGS, (caddr_t)IFF_ALLMULTI);

Do this before you run your multicast application code.

Setting the ETSEC for all multicast mode should program the multicast
hash table to all ones, which avoids the buggy code in the hash table
calculation. This will cause the interface to receive all multicast
frames, but the TCP/IP stack will discard the unwanted ones in
software. (Some people suggest using IFF_PROMISC instead -- this has
the same effect with regard to multicasts, but also allows all unicast
frames through as well.)

If you have a support contract with Wind River, you should also be
able to obtain a fix for the bug in the etsec driver.

If you're not actually using the MPC8548, you should tell us what
ethernet controller you actually are using.

-Bill

On Jun 13, 11:04 pm, noiset...@gmail.com wrote:
> On Jun 11, 7:32 am, Janardhan wrote:
>
>
>
> > On Jun 9, 9:42 pm, noiset...@gmail.com wrote:
>
> > > On Jun 9, 4:21 am, Janardhan wrote:
>
> > > > Hi,
> > > > I have a mulitcast server program. I have added the interface to the
> > > > mulitcast group and also binded on that interface to receive mulitcast
> > > > packets. When the mulitcast packets arrive I am not able to receive
> > > > the mulitcast packets. This is happening when I do the bind to the
> > > > interface on which i want to listen. Instead if i do a bind on
> > > > INADDR_ANY, then I am able to receive the mulitcast packets.
>
> > > > Is there any problem with the vxWorks IP stack?
>
> > > Here is a list of information you did not provide:
>
> > > - What version of VxWorks you're using
>
> > > - What CPU arch/BSP you're running it on
>
> > > - What network controller you're trying to send/receive multicasts
> > > with
>
> > > - What driver you're using with this controller
>
> > > - Does your target board have more than one network interface
>
> > > Yes, all of this matters.
>
> > > If you have more than one network interface, you must join the
> > > multicast group using the right one. For this, you may need to use an
> > > IP_MULTICAST_IF setsockopt() call. Also, you did not bzero() the
> > > ipMreq structure in your code.
>
> > > If the driver for your network controller is broken, it may not be
> > > programming the multicast filter correctly. This will stop you
> > > receiving multicast traffic. If you wrote your own driver, it may be
> > > broken. If you're using some of the older drivers shipped with
> > > VxWorks, it may also be broken. (We can't tell though, since you
> > > didn't tell us what version of VxWorks you have.)
>
> > > -Bill
>
> > Bill,
> > Thanks for the reply. Here are the answers for your questions,
>
> > - What version of VxWorks you're using
> > VxWorks 6.4
>
> > - What CPU arch/BSP you're running it on
> > Power PC
>
> Arrrrgh. Could you have not found it within yourself to at least say
> _WHICH_ PowerPC CPU it is?
>
> > - What network controller you're trying to send/receive multicasts
> > > with
>
> > Broadcom BCM5650X Ethernet switch.
>
> > > - What driver you're using with this controller
>
> > Provided by broadcom.
>
> No no no. You misunderstand the question. When I said "network
> interface" I meant the ethernet interface that you're binding to in
> VxWorks. That is, when run "muxShow()" at the target shell, you see a
> list of interfaces. I'm talking about those, NOT the Broadcom switch
> chip.
>
> Now, based on the information you've presented, I suspect that you
> have one of these:
>
> http://www.radisys.com/products/data...uctdatasheetsi...
>
> (If I'm wrong, please correct me.)
>
> It's PPC-based, has a BCM5650X, and a VxWorks BSP. Now, the key piece
> of information about this board is that the management CPU -- which is
> where VxWorks runs -- is a Freescale MPC8548. This is what I was
> hoping you would tell me, because I happen to know that MPC8548 uses
> built-in ETSEC ethernet controllers. If you are running VxWorks on the
> MPC8548 management CPU, then it's the ETSEC ports that you're using to
> receive your multicast traffic _NOT_ the Broadcom switch controller.
>
> Do you understand this?
>
> Now.
>
> I happen to also know that in VxWorks 6.4, there's a bug in the etsec
> driver that breaks the multicast filtering. (It's fixed in 6.5. 6.6
> and later use a new VxBus driver that also works correctly.) This
> means the ethernet port will discard multicast frames.
>
> If you are in fact using this board, you can attempt the following
> workaround:
>
> - Obtain a pointer to the MUX cookie for the etsec port you're using.
> You can do this as follows
>
> void * pCookie;
> pCookie = muxTkCookieGet ("etsec", 0);
>
> - Use the cookie with muxIoctl() to set the IFF_ALLMULTI flag:
>
> muxIoctl (pCookie, EIOCSFLAGS, (caddr_t)IFF_ALLMULTI);
>
> Do this before you run your multicast application code.
>
> Setting the ETSEC for all multicast mode should program the multicast
> hash table to all ones, which avoids the buggy code in the hash table
> calculation. This will cause the interface to receive all multicast
> frames, but the TCP/IP stack will discard the unwanted ones in
> software. (Some people suggest using IFF_PROMISC instead -- this has
> the same effect with regard to multicasts, but also allows all unicast
> frames through as well.)
>
> If you have a support contract with Wind River, you should also be
> able to obtain a fix for the bug in the etsec driver.
>
> If you're not actually using the MPC8548, you should tell us what
> ethernet controller you actually are using.
>
> -Bill

Bill,
Thanks for the information. We are using MPC8548 processor only. I
didn't think you are really looking for Processor info. I thought
powerPC would be sufficient. Anyways you have got it right. Will check
with the vxworks contacts to get the fix for the multicast issue. I
will try the workaround you have suggested.

thanks for all the info. will let you know how it goes.

regards
Janardhan

On Jun 13, 11:39 pm, Janardhan wrote:
> On Jun 13, 11:04 pm, noiset...@gmail.com wrote:
>
>
>
> > On Jun 11, 7:32 am, Janardhan wrote:
>
> > > On Jun 9, 9:42 pm, noiset...@gmail.com wrote:
>
> > > > On Jun 9, 4:21 am, Janardhan wrote:
>
> > > > > Hi,
> > > > > I have a mulitcast server program. I have added the interface to the
> > > > > mulitcast group and also binded on that interface to receive mulitcast
> > > > > packets. When the mulitcast packets arrive I am not able to receive
> > > > > the mulitcast packets. This is happening when I do the bind to the
> > > > > interface on which i want to listen. Instead if i do a bind on
> > > > > INADDR_ANY, then I am able to receive the mulitcast packets.
>
> > > > > Is there any problem with the vxWorks IP stack?
>
> > > > Here is a list of information you did not provide:
>
> > > > - What version of VxWorks you're using
>
> > > > - What CPU arch/BSP you're running it on
>
> > > > - What network controller you're trying to send/receive multicasts
> > > > with
>
> > > > - What driver you're using with this controller
>
> > > > - Does your target board have more than one network interface
>
> > > > Yes, all of this matters.
>
> > > > If you have more than one network interface, you must join the
> > > > multicast group using the right one. For this, you may need to use an
> > > > IP_MULTICAST_IF setsockopt() call. Also, you did not bzero() the
> > > > ipMreq structure in your code.
>
> > > > If the driver for your network controller is broken, it may not be
> > > > programming the multicast filter correctly. This will stop you
> > > > receiving multicast traffic. If you wrote your own driver, it may be
> > > > broken. If you're using some of the older drivers shipped with
> > > > VxWorks, it may also be broken. (We can't tell though, since you
> > > > didn't tell us what version of VxWorks you have.)
>
> > > > -Bill
>
> > > Bill,
> > > Thanks for the reply. Here are the answers for your questions,
>
> > > - What version of VxWorks you're using
> > > VxWorks 6.4
>
> > > - What CPU arch/BSP you're running it on
> > > Power PC
>
> > Arrrrgh. Could you have not found it within yourself to at least say
> > _WHICH_ PowerPC CPU it is?
>
> > > - What network controller you're trying to send/receive multicasts
> > > > with
>
> > > Broadcom BCM5650X Ethernet switch.
>
> > > > - What driver you're using with this controller
>
> > > Provided by broadcom.
>
> > No no no. You misunderstand the question. When I said "network
> > interface" I meant the ethernet interface that you're binding to in
> > VxWorks. That is, when run "muxShow()" at the target shell, you see a
> > list of interfaces. I'm talking about those, NOT the Broadcom switch
> > chip.
>
> > Now, based on the information you've presented, I suspect that you
> > have one of these:
>
> >http://www.radisys.com/products/data...uctdatasheetsi...
>
> > (If I'm wrong, please correct me.)
>
> > It's PPC-based, has a BCM5650X, and a VxWorks BSP. Now, the key piece
> > of information about this board is that the management CPU -- which is
> > where VxWorks runs -- is a Freescale MPC8548. This is what I was
> > hoping you would tell me, because I happen to know that MPC8548 uses
> > built-in ETSEC ethernet controllers. If you are running VxWorks on the
> > MPC8548 management CPU, then it's the ETSEC ports that you're using to
> > receive your multicast traffic _NOT_ the Broadcom switch controller.
>
> > Do you understand this?
>
> > Now.
>
> > I happen to also know that in VxWorks 6.4, there's a bug in the etsec
> > driver that breaks the multicast filtering. (It's fixed in 6.5. 6.6
> > and later use a new VxBus driver that also works correctly.) This
> > means the ethernet port will discard multicast frames.
>
> > If you are in fact using this board, you can attempt the following
> > workaround:
>
> > - Obtain a pointer to the MUX cookie for the etsec port you're using.
> > You can do this as follows
>
> > void * pCookie;
> > pCookie = muxTkCookieGet ("etsec", 0);
>
> > - Use the cookie with muxIoctl() to set the IFF_ALLMULTI flag:
>
> > muxIoctl (pCookie, EIOCSFLAGS, (caddr_t)IFF_ALLMULTI);
>
> > Do this before you run your multicast application code.
>
> > Setting the ETSEC for all multicast mode should program the multicast
> > hash table to all ones, which avoids the buggy code in the hash table
> > calculation. This will cause the interface to receive all multicast
> > frames, but the TCP/IP stack will discard the unwanted ones in
> > software. (Some people suggest using IFF_PROMISC instead -- this has
> > the same effect with regard to multicasts, but also allows all unicast
> > frames through as well.)
>
> > If you have a support contract with Wind River, you should also be
> > able to obtain a fix for the bug in the etsec driver.
>
> > If you're not actually using the MPC8548, you should tell us what
> > ethernet controller you actually are using.
>
> > -Bill
>
> Bill,
> Thanks for the information. We are using MPC8548 processor only. I
> didn't think you are really looking for Processor info. I thought
> powerPC would be sufficient. Anyways you have got it right. Will check
> with the vxworks contacts to get the fix for the multicast issue. I
> will try the workaround you have suggested.
>
> thanks for all the info. will let you know how it goes.
>
> regards
> Janardhan


Bill,
I did try the options you specified but somehow i am not successful in
get it working.

Here is the complete code that i am using it now. can you please let
me know if I am missing anything.

------------------------------------------

char * mcastRcv
(
unsigned int ifAddr, /* interface address to recv
mcast packets */
unsigned int mcastAddr, /* multicast address */
unsigned int mcastPort, /* udp port number to recv */
int numRead /* number of bytes to read */
)
{
struct sockaddr_in fromAddr;
struct sockaddr_in sin;
int fromLen;
struct ip_mreq ipMreq;
int recvLen;
int sockDesc;
char * bufPtr;
int status = OK;
char * recvBuf = NULL;
unsigned int m_addr;
void * pCookie;

if ((sockDesc = socket (AF_INET, SOCK_DGRAM, 0)) < 0)
{
printf (" cannot open recv socket\n");
return (NULL);
}

bzero ((char *)&sin, sizeof (sin));
bzero ((char *) &fromAddr, sizeof(fromAddr));
fromLen = sizeof(fromAddr);

if ((recvBuf = (char*)calloc (numRead, sizeof (char))) == NULL)
{
printf (" calloc error, cannot allocate memory\n");
status = ERROR;
goto cleanUp;
}

sin.sin_len = (u_char) sizeof(sin);
sin.sin_family = AF_INET;
//sin.sin_addr.s_addr = htonl (mcastAddr);
sin.sin_addr.s_addr = htonl (ifAddr);

/* UDP port number to match for the received packets */
sin.sin_port = htons (mcastPort);

/* bind a port number to the socket */
if (bind(sockDesc, (struct sockaddr *)&sin, sizeof(sin)) != 0)
{
perror("bind");
status = ERROR;
goto cleanUp;
}

pCookie = muxTkCookieGet ("mottsec", 0);
if (OK != muxIoctl (pCookie, EIOCSFLAGS, (caddr_t)IFF_ALLMULTI))
{
perror("failed to set the interface for multicast");
status = ERROR;
goto cleanUp;
}


/* fill in the argument structure to join the multicast group */
/* initialize the multicast address to join */

bzero ((char *) &ipMreq, sizeof(ipMreq));
ipMreq.imr_multiaddr.s_addr = htonl (mcastAddr);

/* unicast interface addr from which to receive the multicast
packets */
ipMreq.imr_interface.s_addr = htonl (ifAddr);

/* set the socket option to join the MULTICAST group */
if (setsockopt (sockDesc, IPPROTO_IP, IP_ADD_MEMBERSHIP,
(char *)&ipMreq,
sizeof (ipMreq)) < 0)
{
printf ("setsockopt IP_ADD_MEMBERSHIP error:\n");
status = ERROR;
goto cleanUp;
}

m_addr = htonl(ifAddr);

if (setsockopt (sockDesc, IPPROTO_IP, IP_MULTICAST_IF,
(char *)&m_addr,
sizeof (m_addr)) < 0)
{
printf ("setsockopt IP_MULTICAST_IF error:\n");
status = ERROR;
goto cleanUp;
}

/* get the data destined to the above multicast group */
bufPtr = recvBuf;



while (numRead > 0)
{
if ((recvLen = recvfrom (sockDesc, bufPtr, numRead, 0,
(struct sockaddr *)&fromAddr, &fromLen))
< 0)
{
perror("recvfrom");
status = ERROR;
break;
}
numRead -= recvLen; /* decrement number of bytes to read
*/
bufPtr += recvLen; /* increment the buffer pointer */
}

/* set the socket option to leave the MULTICAST group */
if (setsockopt (sockDesc, IPPROTO_IP, IP_DROP_MEMBERSHIP,
(char *)&ipMreq,
sizeof (ipMreq)) < 0)
printf ("setsockopt IP_DROP_MEMBERSHIP error:\n");

cleanUp:
close (sockDesc);
if ((status != OK) && (recvBuf != NULL))
{
free (recvBuf);
recvBuf = NULL;
}
return (recvBuf);
}
};
------------------------------------------

thanks
Janardhan