Re: Bind succeeded but not receiving mulitcast packets
- From: Janardhan <janabr.007@xxxxxxxxx>
- Date: Fri, 13 Jun 2008 11:39:00 -0700 (PDT)
On Jun 13, 11:04 pm, noiset...@xxxxxxxxx wrote:
On Jun 11, 7:32 am, Janardhan <janabr....@xxxxxxxxx> wrote:
On Jun 9, 9:42 pm, noiset...@xxxxxxxxx wrote:
On Jun 9, 4:21 am, Janardhan <janabr....@xxxxxxxxx> 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/datasheet_page.cfm?productdatasheetsi...
(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
.
- Follow-Ups:
- Re: Bind succeeded but not receiving mulitcast packets
- From: Janardhan
- Re: Bind succeeded but not receiving mulitcast packets
- References:
- Bind succeeded but not receiving mulitcast packets
- From: Janardhan
- Re: Bind succeeded but not receiving mulitcast packets
- From: noisetube
- Re: Bind succeeded but not receiving mulitcast packets
- From: Janardhan
- Re: Bind succeeded but not receiving mulitcast packets
- From: noisetube
- Bind succeeded but not receiving mulitcast packets
- Prev by Date: Re: Bind succeeded but not receiving mulitcast packets
- Next by Date: Ensiaputaidoista?
- Previous by thread: Re: Bind succeeded but not receiving mulitcast packets
- Next by thread: Re: Bind succeeded but not receiving mulitcast packets
- Index(es):
Relevant Pages
|
