Hi all,
I have tried to run several IP Multicast applications (SDR, Vat,...)
with on 2.5 kernels (now running 2.5.59bk3) without succes. Same
applications appear to work on 2.4 kernels.
What seems to be happening is that the application binds to the lo
interface instead of eth0 so that no IGMP queries are send out on the
ethernet interface. I have a small application that tries to listen to
address 233.4.5.9 and here is /proc/net/igmp with and without the app
running:
Withtout app running:
Idx Device : Count Querier Group Users Timer Reporter
1 lo : 0 V2
010000E0 1 0:FFF779D7 0
2 eth0 : 3 V2
010000E0 1 0:400DA3C3 0
With app running:
Idx Device : Count Querier Group Users Timer Reporter
1 lo : 0 V2
090504E9 1 1:00000C28 1
010000E0 1 0:FFF73910 0
2 eth0 : 3 V2
010000E0 1 0:400D62FC 0
Is there a known problem? Or should multicast applications be changed to
run on 2.5 kernels?
Thanks,
Niels
On Wednesday, 12 February 2003, Niels den Otter wrote:
> On Monday, 10 February 2003, Niels den Otter wrote:
> > I have tried to run several IP Multicast applications (SDR, Vat,...)
> > with on 2.5 kernels (now running 2.5.59bk3) without succes. Same
> > applications appear to work on 2.4 kernels.
> >
> > What seems to be happening is that the application binds to the lo
> > interface instead of eth0 so that no IGMP queries are send out on
> > the ethernet interface. I have a small application that tries to
> > listen to address 233.4.5.9 and here is /proc/net/igmp with and
> > without the app running:
>
> Did more debugging and disabled my loopback interface to ensure the
> mcast apps don't bind to this interface. strace shows all applications
> go wrong with the same error. Is this kernel related?
In the meantime I have had verious discussion on this subject with
Antonio Querubin and others and I don't know any solution yet.
Is anyone able to use multicast applications on recent 2.5 kernels and
make it send out IGMP joins on an ethernet device?
RFC 1112 says
If the upper-layer protocol chooses not to identify an outgoing
interface, a default interface should be used, preferably under the
control of system management.
In Linux 2.4 kernels this seems to work with adding a route for
224.0.0.0/4 on the desired ethernet interface. This doesn't work in 2.5
kernels however.
Anyone who knows what the problem is and how it can be solved?
Thanks,
Niels
On Mon, 3 Mar 2003, Niels den Otter wrote:
> On Wednesday, 12 February 2003, Niels den Otter wrote:
> > On Monday, 10 February 2003, Niels den Otter wrote:
> > > I have tried to run several IP Multicast applications (SDR, Vat,...)
> > > with on 2.5 kernels (now running 2.5.59bk3) without succes. Same
> > > applications appear to work on 2.4 kernels.
> > >
> > > What seems to be happening is that the application binds to the lo
> > > interface instead of eth0 so that no IGMP queries are send out on
> > > the ethernet interface. I have a small application that tries to
> > > listen to address 233.4.5.9 and here is /proc/net/igmp with and
> > > without the app running:
> >
> > Did more debugging and disabled my loopback interface to ensure the
> > mcast apps don't bind to this interface. strace shows all applications
> > go wrong with the same error. Is this kernel related?
>
> In the meantime I have had verious discussion on this subject with
> Antonio Querubin and others and I don't know any solution yet.
>
> Is anyone able to use multicast applications on recent 2.5 kernels and
> make it send out IGMP joins on an ethernet device?
>
> RFC 1112 says
> If the upper-layer protocol chooses not to identify an outgoing
> interface, a default interface should be used, preferably under the
> control of system management.
>
> In Linux 2.4 kernels this seems to work with adding a route for
> 224.0.0.0/4 on the desired ethernet interface. This doesn't work in 2.5
> kernels however.
>
>
> Anyone who knows what the problem is and how it can be solved?
>
>
> Thanks,
Did you try to use bind() to bind your socket to a specific interface?
Using `route` to obtain side-effects is not the correct way. The
application needs to bind the socket to a specific interface if
the applications requires a specific interface (which you seem to
require). Otherwise, the first interface found will be used as
the default. If you can't rebuild the programs, you might work-
around the problem by modifying start-up so that your ethernet
interfaces are started before loop-back.
You can expriment without rebooting...
Remove all routing entries first.
route del -default xxx
route del -net xxx, etc.
`ifconfig eth0 down`
`ifconfig lo down`
Completely reconfigure eth0 first....
Then configure lo.
If you don't remove all the routing entries first, you don't
really end up with a new configuration. Something 'remembers'
and the order of entries doesn't get changed.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
Richard,
On Monday, 3 March 2003, Richard B. Johnson wrote:
> Did you try to use bind() to bind your socket to a specific interface?
> Using `route` to obtain side-effects is not the correct way. The
> application needs to bind the socket to a specific interface if the
> applications requires a specific interface (which you seem to
> require). Otherwise, the first interface found will be used as the
> default. If you can't rebuild the programs, you might work- around the
> problem by modifying start-up so that your ethernet interfaces are
> started before loop-back.
>
> You can expriment without rebooting...
>
> Remove all routing entries first.
> route del -default xxx
> route del -net xxx, etc.
>
> `ifconfig eth0 down`
> `ifconfig lo down`
>
> Completely reconfigure eth0 first....
> Then configure lo.
>
> If you don't remove all the routing entries first, you don't really
> end up with a new configuration. Something 'remembers' and the order
> of entries doesn't get changed.
I have tried both your method and also booting Linux without any
interfaces enabled, then enable eth0 and after that also lo.
When only eth0 was enabled, I got the following error from sdr:
pangsit:~> sdr
setsockopt - IP_ADD_MEMBERSHIP: No such device
setsockopt - IP_ADD_MEMBERSHIP: No such device
sd_listen: setsockopt IP_ADD_MEMBRSHIP err, addr: 224.2.127.254
I can send strace if this helps.
This is the same problem I see with other multicast applications. It
really doesn't want to bind to the ethernet interface.
pangsit:~> ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:08:74:22:48:CF
inet addr:192.87.109.130 Bcast:192.87.109.255 Mask:255.255.255.0
inet6 addr: 2001:610:508:109:208:74ff:fe22:48cf/64 Scope:Global
inet6 addr: fe80::208:74ff:fe22:48cf/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:32863 errors:0 dropped:0 overruns:1 frame:0
TX packets:150 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:100
RX bytes:16213097 (15.4 MiB) TX bytes:16428 (16.0 KiB)
Interrupt:11 Base address:0xec80
After bringing up the loopback interface again the applications binds to
this interface.
-- Niels