I give the 2.5 series a try every once in a while and found the
2.5.63 booted and ran reasonably well.
I happen to working on some multicast stuff and found that I can't
read multicast data when running 2.5.63.
Switched back to 2.4.20 and the multicast data reads fine.
Back to 2.5.63 and nada. tcpdump shows the data showing up
at the interface. I double checked the obvious stuff like
multicast being turned on in the kernel.
I even have tulip and rtl-8139 based cards I can switch between
and that made no difference either.
Is there something I have to set someplace to get multicast
support in 2.5.x?
--
Brian Litzinger
Hi Brian,
On Monday, 3 March 2003, [email protected] wrote:
> I give the 2.5 series a try every once in a while and found the 2.5.63
> booted and ran reasonably well.
>
> I happen to working on some multicast stuff and found that I can't
> read multicast data when running 2.5.63.
>
> Switched back to 2.4.20 and the multicast data reads fine.
>
> Back to 2.5.63 and nada. tcpdump shows the data showing up
> at the interface. I double checked the obvious stuff like
> multicast being turned on in the kernel.
>
> I even have tulip and rtl-8139 based cards I can switch between
> and that made no difference either.
>
> Is there something I have to set someplace to get multicast support in
> 2.5.x?
You appear to be strugling with the same problem I have. What I find is
that the multicast application binds to the loopback instead of ethernet
interface (also no IGMP joins are send out on the ethernet interface).
Can you please check the output of 'netstat -n -g' and see if the
multicast address shows up at the correct interface?
Various people have provided hints on how (and in what order) to setup
the interfaces, but uptil now I have not been able to receive any
multicast data with 2.5 kernels.
It would be nice to know if anyone is able to join multicast groups on
2.5 kernels. Especially for applications that don't bind to a very
specific interface, but leave this choice to the kernel.
-- Niels
> On Monday, 3 March 2003, [email protected] wrote:
> > I give the 2.5 series a try every once in a while and found the 2.5.63
> > booted and ran reasonably well.
> >
> > I happen to working on some multicast stuff and found that I can't
> > read multicast data when running 2.5.63.
On Tue, Mar 04, 2003 at 11:39:53PM +0100, Niels den Otter wrote:
> You appear to be strugling with the same problem I have. What I find is
> that the multicast application binds to the loopback instead of ethernet
> interface (also no IGMP joins are send out on the ethernet interface).
> Can you please check the output of 'netstat -n -g' and see if the
> multicast address shows up at the correct interface?
The apps I have vlc, and mpeg2dec (with mods) cannot read
multicast data under 2.5.63, but both work under 2.4.20.
I also have some PERL tools which do multicasting stuff and
they don't work any longer either.
However, I added 'eth0' to the IO::Socket::Multicast::mcast_add()
call and now the data is showing up.
I believe this means back in the C/C++ paradigm you can't rely on
INADDR_ANY to do the right thing. So you may have to set the
specific IP of the interface you want your multicast data to
come from in imr_interface.s_addr of the struct ip_mreq you pass
in via setsockopt( sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, ...
I'll give this a try and let you know what I find.
--
Brian Litzinger
Brian,
On Tuesday, 4 March 2003, [email protected] wrote:
> The apps I have vlc, and mpeg2dec (with mods) cannot read multicast
> data under 2.5.63, but both work under 2.4.20.
>
> I also have some PERL tools which do multicasting stuff and they don't
> work any longer either.
>
> However, I added 'eth0' to the IO::Socket::Multicast::mcast_add()
> call and now the data is showing up.
>
> I believe this means back in the C/C++ paradigm you can't rely on
> INADDR_ANY to do the right thing. So you may have to set the specific
> IP of the interface you want your multicast data to come from in
> imr_interface.s_addr of the struct ip_mreq you pass in via setsockopt(
> sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, ...
>
> I'll give this a try and let you know what I find.
But lot of multicast applications use INADDR_ANY and most don't provide
an option to choose a specific interface. So I really think that the
kernel should bind the application to an ethernet interface and not to
the loopback interface to make them work.
Can you please check if it tries to bind to the loopback interface when
using INADDR_ANY by checking 'netstat -n -g' output?
-- Niels
On Tue, 4 Mar 2003, Niels den Otter wrote:
> You appear to be strugling with the same problem I have. What I find is
> that the multicast application binds to the loopback instead of ethernet
> interface (also no IGMP joins are send out on the ethernet interface).
Please try the patch below.
- James
--
James Morris
<[email protected]>
diff -urN -X dontdiff linux-2.5.64.orig/net/ipv4/igmp.c linux-2.5.64.w1/net/ipv4/igmp.c
--- linux-2.5.64.orig/net/ipv4/igmp.c Tue Feb 25 15:03:26 2003
+++ linux-2.5.64.w1/net/ipv4/igmp.c Thu Mar 6 15:55:37 2003
@@ -606,7 +606,7 @@
static struct in_device * ip_mc_find_dev(struct ip_mreqn *imr)
{
struct flowi fl = { .nl_u = { .ip4_u =
- { .daddr = imr->imr_address.s_addr } } };
+ { .daddr = imr->imr_multiaddr.s_addr } } };
struct rtable *rt;
struct net_device *dev = NULL;
struct in_device *idev = NULL;
From: James Morris <[email protected]>
Date: Thu, 6 Mar 2003 16:06:46 +1100 (EST)
On Tue, 4 Mar 2003, Niels den Otter wrote:
> You appear to be strugling with the same problem I have. What I find is
> that the multicast application binds to the loopback instead of ethernet
> interface (also no IGMP joins are send out on the ethernet interface).
Please try the patch below.
Oops, a typo of mine during the flowi changes for ipsec, my bad.
Good spotting James.
> On Tuesday, 4 March 2003, [email protected] wrote:
> > The apps I have vlc, and mpeg2dec (with mods) cannot read multicast
> > data under 2.5.63, but both work under 2.4.20.
> >
> > I also have some PERL tools which do multicasting stuff and they don't
> > work any longer either.
> >
> > However, I added 'eth0' to the IO::Socket::Multicast::mcast_add()
> > call and now the data is showing up.
> >
> > I believe this means back in the C/C++ paradigm you can't rely on
> > INADDR_ANY to do the right thing. So you may have to set the specific
> > IP of the interface you want your multicast data to come from in
> > imr_interface.s_addr of the struct ip_mreq you pass in via setsockopt(
> > sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, ...
> >
> > I'll give this a try and let you know what I find.
>
On Wed, Mar 05, 2003 at 09:25:20AM +0100, Niels den Otter wrote:
> But lot of multicast applications use INADDR_ANY and most don't provide
> an option to choose a specific interface. So I really think that the
> kernel should bind the application to an ethernet interface and not to
> the loopback interface to make them work.
I have to agree that the kernel is broke. After further reading
the expected behavior looks well defined, and the apps along
with my code are designed properly.
> Can you please check if it tries to bind to the loopback interface when
> using INADDR_ANY by checking 'netstat -n -g' output?
I will do my best to give it a try.
--
Brian Litzinger
James,
On Thursday, 6 March 2003, James Morris wrote:
> On Tue, 4 Mar 2003, Niels den Otter wrote:
> > You appear to be strugling with the same problem I have. What I find
> > is that the multicast application binds to the loopback instead of
> > ethernet interface (also no IGMP joins are send out on the ethernet
> > interface).
>
> Please try the patch below.
This fixes the IGMP problem. Thanks for the patch!
-- Niels