AW: Problem receiving multicast/promiscuous-mode with kernel.2.6.24
Visit AVD on prolight+sound in Frankfurt from 12.-15. March 2008 - Hall 8.0,
Stand G16
Hi,
ok, i managed to shrink down my code to show the behaviour in small size ;-)
It shows the same effect as my app, sometimes i get all the packets after a
mc_join, sometimes i get only the timeouts.
I find no predictive behaviour, i'm really desperate ...
Hope you can see the effect too .. Do u need an app sending the multicast VLAN
packets ?
Robert
-
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
//#include
#include
#include
//#define JOIN_SINGLE_IF
#undef JOIN_SINGLE_IF
#define PORT 10500
/*
** Try to receive VLAN-tagged UDP multicast packets
** VLAN-ID:3, VLAN_PRI=6, Addr: 224.1.9.0, dstnport 10500
**
** Kernel used: 2.6.24
**
** HW: VIA Epia 5000, VIA Epia LT (VIA Rhine II and VIA VT6107)
**
** Additional network settings:
** vconfig add eth0 3
** vconfig set_egress_map eth0.3 6 6
** ifconfig eth0.3 10.0.0.1
** route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0.3
**
*/
#define MAX_PAYLOAD 1000
/*
* Network representation of the rtp header.
*/
struct rtp_header {
#ifdef WORDS_BIGENDIAN
uint16_t version:2;
uint16_t padbit:1;
uint16_t extbit:1;
uint16_t cc:4;
uint16_t markbit:1;
uint16_t paytype:7;
#else
uint16_t cc:4;
uint16_t extbit:1;
uint16_t padbit:1;
uint16_t version:2;
uint16_t paytype:7;
uint16_t markbit:1;
#endif
uint16_t seq_number;
uint32_t timestamp;
uint32_t ssrc;
/* In fact we rely on rtp_header being not larger than
* the minimum header length. So, there's no contributing
* sync source field here. */
};
struct rtp_packet {
struct rtp_header header;
unsigned char payload[MAX_PAYLOAD];
};
#ifdef WORDS_BIGENDIAN
#error Sorry this is not supported on bigendian targets.
#endif
#define BYTE0(x) ((x) & 0xff)
#define BYTE1(x) (((x) >> 8) & 0xff)
#define BYTE2(x) (((x) >> 16) & 0xff)
#define BYTE3(x) (((x) >> 24) & 0xff)
static char *my_inet_ntoa (char *buf, size_t n, struct in_addr in)
{
if (snprintf (buf, n, "%u.%u.%u.%u", BYTE0(in.s_addr),
BYTE1(in.s_addr), BYTE2(in.s_addr), BYTE3(in.s_addr)) >= n) {
return NULL;
}
return buf;
}
static int set_non_blocking (int fd)
{
int flags;
if ((flags = fcntl (fd, F_GETFL)) < 0) {
perror ("fcntl getflags ()");
return -1;
}
if (fcntl (fd, F_SETFL, flags | O_NONBLOCK) < 0) {
perror ("fcntl setflags ()");
return -1;
}
return fd;
}
int main()
{
int fd;
fd_set read_fds;
struct timespec timeout;
while(1)
{
int i, ret;
if ((fd = subscribe_udp (PORT)) < 0) {
printf("Could not register UDP port.\n");
return 1;
}
if (join_multicast_group (fd, "224.1.9.0") < 0)
{
printf("Error joining multicast !\n");
return 1;
}
for(i=0;i<10;i++)
{
FD_ZERO (&read_fds);
FD_SET (fd, &read_fds);
timeout.tv_sec = 1;
timeout.tv_nsec = 0;
ret = pselect (fd+1, &read_fds, NULL, NULL, &timeout, NULL);
if (ret < 0) {
if (errno == EINTR) {
continue;
} else {
printf("select failed.\n");
return 1;
}
}
if (FD_ISSET(fd, &read_fds))
{
ssize_t len;
struct rtp_packet p;
struct sockaddr_in from;
socklen_t fromlen;
char from_ip[20];
len = recvfrom (fd, &p, sizeof (p), 0, (struct sockaddr*) &from,
&fromlen);
my_inet_ntoa (from_ip, sizeof (from_ip), from.sin_addr);
printf("Received data packet from %s, length %u\n", from_ip, len);
}
else
{
printf("Got timeout receiving Multicast packets !\n");
}
} /* loop 10 */
if (leave_multicast_group(fd, "224.1.9.0") < 0)
{
printf("Error leaving multicast !\n");
return 1;
}
close(fd);
}
}
int subscribe_udp (int port)
{
int s;
s = create_listening_socket (port, 1);
return s;
}
int create_listening_socket (int listen_port, int udp)
{
struct sockaddr_in a;
int s;
int yes;
if ((s = socket (AF_INET, udp ? SOCK_DGRAM : SOCK_STREAM, 0)) < 0) {
perror ("socket");
return -1;
}
yes = 1;
if (setsockopt (s, SOL_SOCKET, SO_REUS
Re: AW: Problem receiving multicast/promiscuous-mode with kernel.2.6.24
Another relevant piece of information is what the socket is bound to; "netstat -au" will tell you if you're bound to an address that will match the incoming multicast packets. If you suspect that the VLAN device is the problem, then it'd be a good idea to try it on ordinary ethernet. Re: imr_ifindex; using a "0" ifindex and INADDR_ANY interface is valid, but it usually doesn't make sense. What it means is "I don't care what interface I join the group on". But you'll only receive multicasts delivered to the group on the interface the kernel picks for you, which often won't be the one you really want. +-DLS -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: Problem receiving multicast/promiscuous-mode with kernel.2.6.24
Visit AVD on prolight+sound in Frankfurt from 12.-15. March 2008 - Hall 8.0, Stand G16 OK, after some more testing, things become clearer ... joining eth0.3 gives this strange unreliable behaviour... Joining eth0 , and i can see the packets always floating in with tcpdump -p -i eth0.3 (or -i eth0) But my application won't get the packets !!! Maybe this is because i'm using pselect() to wait for incoming packets ? Question: Should it possible to join on a VLAN device ? Or is this something bad ??? Robert -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: Problem receiving multicast/promiscuous-mode with kernel.2.6.24
Visit AVD on prolight+sound in Frankfurt from 12.-15. March 2008 - Hall 8.0,
Stand G16
Hi David,
thanks for your help. Your input is always welcome ;-)
But according to Linux Programmer's Manual it should be OK to use ifindex of 0
e.g. (http://www.rt.com/man/ip.4.html)
but maybe this document is depcecated/obsolte ...
Well anyway, i did what u suggested, used eth0.3 as interface (i'm using VLAN)
Setting ifindex to eth0 won't help .. strange, but well ...,
maybe receiving is blocked by the virtual interface somehow, should be.
The problem is, now i get unreliable results.
At first attempt, it always worked as before with ifindex=0, but now further
attempts SOMETIMES works !!!
Every 3rd or forth attempt i can receive the packets. (this way maybe the same
with old method, i'll investigate further)
But netstat always shows the join (and the absence, if i close socket/leave
mc-group)
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--- -- -
lo 1 224.0.0.1
eth01 224.0.0.1
eth0.3 1 224.1.9.0
eth0.3 1 224.0.0.1
Do u know a way to debug this further ?
It's not so easy for me to build a small app to show the faulty behav, but i'll
try.
Robert
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Auftrag von David Stevens
Gesendet: Donnerstag, 07. Februar 2008 17:09
An: Reither Robert
Cc: netdev@vger.kernel.org
Betreff: Re: Problem receiving multicast/promiscuous-mode with
kernel.2.6.24
You need to join the multicast group on the interface you want
to receive it. If you're setting both imr_address and imr_index
to 0, you haven't specified an interface.
Instead of setting imr_ifindex to 0, try setting it like this:
imr.imr_ifindex = if_nametoindex("eth0");
(or whatever interface you need).
You can verify that you've joined the group on the correct
interface with "netstat -g", also. Make sure that the interface
field is correct for the group you want.
And because I can't resist mentioning it, "inet_aton" is deprecated--
suggest inet_pton() with appropriate arguments and return value
checking instead.
There was a bug fix where the sense of promiscuous mode was
backwards for multicasting, which is probably why it was accidently
(and incorrectly) working in earlier kernels.
If that doesn't do it for you, let me know; better if you can post the
full code (or even better, the smallest subset that demonstrates the
problem).
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
