Hi,

i'm working on a realtime-audio application, which should be capeable to receive RTP packets via multicast addresses.

App did work fine till i switched from 2.6.22 to kernel 2.6.24 (because of hwmon support for VIA EPIA LT15000AG)

With kernel 2.6.22 i had no problems, i'm using almost identical .config
Also tried kernel 2.6.24-rc5, same problem.
Tried it on two different boards (diff. NIC's, cpu's mem, etc ..)

I'm using the same setsockopt with IP_ADD_MEMBERSHIP as before for all interfaces.
But now my app does not receive any multicast packet !

Strange thing is, as long as tcpdump is running, the app (and tcpdump) get the multicast packets, but if i stopp tcpdump, my application at the same moment gets no more multicast packets.

I can see with netstat -g the joined MC-address (if app is active)
multicast route is set up properly.
i'm using VLAN (VLAN packets routed to eth0.3)

Any ideas ?

Thanks
Robert

OK, i partly found out what happend.

Right after reboot, receiving of mc-packets worked for just one time.
After one ADD_MEMBERSHIP/DROP_MEMBERSHIP cycle it won't work any longer.

If i deny tcpdump setting promiscous-mode (-p) i get no packets.

Looks like somehow the NIC won't be (re)set to promiscous mode.

My code:

int join_multicast_group (int fd, const char *mc_address)
{
struct ip_mreqn imr;

log_message(DVA_LOG_INFO,"In join_mc_group: %s\n",mc_address);

if (inet_aton (mc_address, &imr.imr_multiaddr) == 0) {
log_message (DVA_LOG_ERROR, "join_mc:Bad IP address format: %s\n", mc_address);
return -1;
}

imr.imr_address.s_addr = INADDR_ANY;
imr.imr_ifindex = 0;

// Check if already member
if (setsockopt (fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &imr, sizeof (imr)) < 0)
{
if (errno == EADDRINUSE) // Address already joined for IP_ADD_MEMBERSHIP
log_message(DVA_LOG_INFO,"Already joined IP_ADD_MEMBERSHIP for %s.\n", mc_address);
else
{
log_perror (DVA_LOG_ERROR, "getsockopt ip_add_membership");
return -1;
}
}
return 0;
}

and quite the same with DROP_MEMBERSHIP

A am also having that same problem, did you ever get it to work?
I did a work around to get it working on my box. When you use vlaning (trunking) you can make a "Native" vlan on a trunked port. A native vlan will use no tag, just make sure your switch has the same native vlan. After that add the vlans and it will still work on the native vlan.

But I am interested if you ever did get it working

Thanks

Yes, there was a bug in vlan mapping (uninitialised data). It was fixed in one of the following 2.6.24.x releases.
Works quite fine for me now !