9 Oct
2013
9 Oct
'13
2:11 a.m.
Subject:
Re: [44net] 44Net Digest, Vol 2, Issue 159
From:
sp2lob <sp2lob(a)tlen.pl>
Date:
10/07/2013 09:49 PM
To:
AMPRNet working group <44net(a)hamradio.ucsd.edu>
Hello Rob et al,
Quote:
"...by default mcast routes will be associated with an interface
the kernel picks (usually the first to come up)."
There is something what you're looking for, I believe.
Small, nifty & powerfull program to install: *smcroute*
The *smcroute* <http://www.cschill.de/smcroute/> utility provides a command line
interface to manipulate
the multicast routing tables via a method other than *mrouted*.
Tom,
I looked in the source and this tool is not going to fix it.
It uses exactly the same setsockopt call that ampr-ripd is already using to join the
multicast group.
The problem is that this setsockopt has 2 IP address parameters, one is the address
of the local interface and the other is the multicast group to join.
This is of course wrong. The first should not be an IP address but an interface name.
But this kernel interface appears to be very old, dating back from BSD Unix.
Given is situation, there is no way to uniquely identify the interface where the
multicast
group has to be joined, and the problem cannot be solved.
Either all interfaces have to use a different address, or the multicast group must be
joined before a duplicate address is created (I do that now).
Or, when you don't mind using undefined implementation details, it will probably also
work when tunl0 is created as the last interface.
(because it appears the kernel has preference for the last interface in the list when
a duplicate is found)
W.r.t. multicast routing not being enabled: that does not appear to matter.
Probably this is only required when you want the Pi to do actual forwarding of multicast
traffic, not for just receiving it.
Rob