AW: AW: AW: Problem receiving multicast with kernel.2.6.24, REAL solution
Visit AVD on prolight+sound in Frankfurt from 12.-15. March 2008 - Hall 8.0, Stand G16 Hurray, your patch does the trick for me !!! Now join/leave und receiving of multicasts work like it should !! May i kiss you Patrick, this saves my week ;-) Hope we see a minor kernel release with this patch very soon ... Greetings Robert -Ursprüngliche Nachricht- Von: Patrick McHardy [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. Februar 2008 15:03 An: Reither Robert Cc: David Stevens; netdev@vger.kernel.org Betreff: Re: AW: AW: Problem receiving multicast with kernel.2.6.24 #3 > > OK, found one solution (but i think, this should not the normal way) > > MC joining first the VLAN device (eth0.3) and than the physical (eth0) does > the trick, 100% success ... > > Doing it the opposite way, gives the same problem as before ... > > So somehow joining the VLAN interface disrupts the join to the physical one > ... > > Ideas ? Does this patch help? -- 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: AW: Problem receiving multicast with kernel.2.6.24 #3
Visit AVD on prolight+sound in Frankfurt from 12.-15. March 2008 - Hall 8.0, Stand G16 OK, found one solution (but i think, this should not the normal way) MC joining first the VLAN device (eth0.3) and than the physical (eth0) does the trick, 100% success ... Doing it the opposite way, gives the same problem as before ... So somehow joining the VLAN interface disrupts the join to the physical one ... Ideas ? 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,
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
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
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,
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 (VIA EPIA LT, VIA EPIA 5000, 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 multicast packets !
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.
Closer look:
-
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 user 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 before i close the socket.
Robert Reither
Research & Development
AV Digital Audio- Videotechnik GmbH
Pottendorfer Strasse 25-27/4/1/1
A-1120 Wien/Austria
Commercial Register No.: FN 201615v
Commercial Court: Handelsgericht Wien
VAT-No.: ATU 50461904
Tel.: +43/1/3680368 43
email: [EMAIL PROTECTED]
Visit:
Robert Reither
Research & Development
AV Digital Audio- Videotechnik GmbH
Pottendorfer Strasse 25-27/4/1/1
A-1120 Wien/Austria
Commercial Register No.: FN 201615v
Commercial Court: Handelsgericht Wien
VAT-No.: ATU 50461904
Tel.: +43/1/3680368 43
email: [EMAIL PROTECTED]
Visit:
--
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: [RFT] r8169 changes against 2.6.23-rc3
Hi François, tested your latest patchset with my 8110SC multicast problem (unreliable multicast receiving) Sad but true, but all still the same ... Greetings 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
still not properly working multicast receiving at rtk8110SC (with 23rc3+ your patches)
Hi Francois, i just tested the new kernel 2.6.23rc3 with and without your patches, i cannot find a difference to the behaviour of the previous state ... (22 + your patches) I still have a very unreliable receiving of multicast packets, only for about 1/3 of my join mc attempts or so i receive them, in the other cases i do not. Glen Gray also reported the same problems here on list, and i did some conversation. I'm using a Jetway mini-ITX board 7F4K with VIA C7 processor and he uses a similar platform, also with a C7 cpu, maybe the platform influences the problem ? Do we have reports on other platforms with the r8110SC and multicast receiving ? I also tried drivers from realtek homepage (the new 2.x series does not compile under kernel >2.6.20) The older driver (1.x for kernel 2.4) does work fine for me if i do some changes to the code to fit with kernel 2.6 series (transfered code from older versions which did support 2.6 too). Greetings 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: Problems receving multicasts with r8169.c driver from linux kernel (2.6.21.5)
Hi Francois , i can spare some time now, so i ask: Would it help, if i code/send u a tool to simulate your multicast packet scenario ? Buts its possible for me to reproduce the problem with e.g. nc -u 224.1.1.1 10500 http://www.av-digital.at> - 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
Still problems receving multicasts with r8169.c driver from linux kernel (2.6.22.1) + patches
Hi Francois, sorry, i 4got to add the netdev-cc should not happen again ;-) I still cannot access some patches (maybe u get them via browser cache or no right restrictions?) So, i added all your patches(1-21) from the bz2 file in the root-dir to a plain driver from 2.6.22.1 ... Fact is: I still have missing multicast packet income, but things changed: before i had one good try within 20, now i get my packet stream every second to 3rd try. Descrition what i do: i'm sending multicast packets (e.g. Dstn IP 224.1.13.1 port 10501) every 8,9ms the packetlen is 496 bytes (it's a RTP stream) to my linux system and monitor incoming packets with tcpdump -i eth0 (and my application of course) What i get now is, almost every 2nd attempt i start transmitting packets i get them just fine (without any drops between) on the other side on some attempts i start sending and i see no incoming multicast packets with tcpdump (as well as from within the receiving application) routes look OK, netstat -g shows correct memberships Greetings Robert -Ursprüngliche Nachricht- Von: Francois Romieu [mailto:[EMAIL PROTECTED] Gesendet: Montag, 16. Juli 2007 13:05 An: Reither Robert Betreff: Re: Problems receving multicasts with r8169.c driver from linux kernel (2.6.21.5) Is there a specific reason why you did not Cc: netdev@vger.kernel.org ? Reither Robert <[EMAIL PROTECTED]> : [...] > Tested now with latest official kernel (2.6.22.1), happens the same way. Ok. It's the expected result. > Will now try to add the patches ... > > > Can you give me a hint, which patch exactly could fix my problem ? 0020, 0021 and probably some bits of the merge with Realtek's driver. Start gross and apply everything. It takes something along the lines of: cat series | while read f; do patch -p1 $f; done > Btw, some patches from your link > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/ > are not accessable (3, 9, 13, 18) I have tried the four url below and they downloaded correctly: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/0003-r8169-kill-eth_copy_and_sum.patch http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/0009-r8169-prettify-mac_version.patch http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/0013-r8169-small-8101-comment.patch http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/0018-r8169-add-endianess-annotations-to-RT-xDesc.patch Can you check your command line or grep the tarball in the upper directory ? > -Ursprüngliche Nachricht- Please avoid TOFU. -- Ueimor - 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
