In developing multicast applications, I would like to be able to test
locally over the loopback interface. This does not work without adding a
bogus route statement to get the kernel to hand up the packets from
loopback to my waiting application.
This route statement is not necessary with other network drivers, so I
assume that adding some logic to the loopback driver would fix this
problem. Is it possible to get this added?
-Erik G. Burrows
> locally over the loopback interface. This does not work without adding a
> bogus route statement to get the kernel to hand up the packets from
> loopback to my waiting application.
The multicast ABI includes the ability to toggle loopback of multicast
datagrams. Use the socket options instead
> > locally over the loopback interface. This does not work without adding a
> > bogus route statement to get the kernel to hand up the packets from
> > loopback to my waiting application.
>
> The multicast ABI includes the ability to toggle loopback of multicast
> datagrams. Use the socket options instead
I read that multicast loopback is by default enabled, and I have witnessed
this, when having my application bind to my ethernet interface, but the
datagrams do not seem to be looped back when I bind to the 'lo' interface.
Could this possibly be a conflict with the inherently 'looped back'
behavior of the loopback net driver?
As far as toggling the flag, or even reading it, I cannot, as I am
developing in Java.
For developing, I can easily kludge it to work, by adding a fake route
statement, forcing the packets back up to the application, but I want to
make sure the differing behavior is not a bug in the kernel networking
code.
-Erik G. Burrows
> I read that multicast loopback is by default enabled, and I have witnessed
> this, when having my application bind to my ethernet interface, but the
> datagrams do not seem to be looped back when I bind to the 'lo' interface.
I wouldnt expect them to be. The lo interface does not support multicasting.
I dont think this is a bug