8 Oct
2013
8 Oct
'13
4:22 p.m.
Rob,
Well, I'm not coder and I'm not big linux wizard either.
I made some digging as issue seemd to me quite interesting.
Multicast routing enabled isn't necessary for receiving
- that's almost obvious.
Your explanation is very detailed.
I see now what is your exact goal to achieve.
Best regards.
Tom - sp2lob
Dnia 8 października 2013 21:11:54 Rob Janssen <pe1chl(a)amsat.org> napisał(a):
> (Please trim inclusions from previous messages)
> _______________________________________________
>
> > 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
>
>