Subject: Re: [44net] 44Net Digest, Vol 2, Issue 159 From: sp2lob sp2lob@tlen.pl Date: 10/07/2013 09:49 PM
To: AMPRNet working group 44net@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
Rob Janssen wrote:
Subject: Re: [44net] 44Net Digest, Vol 2, Issue 159 From: sp2lob sp2lob@tlen.pl Date: 10/07/2013 09:49 PM
To: AMPRNet working group 44net@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.
Checking the kernel sources I found that besides the IP_ADD_MEMBERSHIP call to setsockopt, another option exists: MCAST_JOIN_GROUP which receives a group_req struct (instead of ip_mreq) which includes a gr_interface member, an interface index which can be filled using if_nametoindex(ifname).
So, if the call is changed in ampr-ripd, it can uniquely add the multicast address to the correct interface (which is already known in ampr-ripd).
Marius ? What about changing this?
Rob
Tnx for the sugestion! I will dig into it during the weekent!
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Rob Janssen Sent: Tuesday, October 08, 2013 22:43 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] 44Net Digest, Vol 2, Issue 162
(Please trim inclusions from previous messages) _______________________________________________ Rob Janssen wrote:
Subject: Re: [44net] 44Net Digest, Vol 2, Issue 159 From: sp2lob sp2lob@tlen.pl Date: 10/07/2013 09:49 PM
To: AMPRNet working group 44net@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.
Checking the kernel sources I found that besides the IP_ADD_MEMBERSHIP call to setsockopt, another option exists: MCAST_JOIN_GROUP which receives a group_req struct (instead of ip_mreq) which includes a gr_interface member, an interface index which can be filled using if_nametoindex(ifname).
So, if the call is changed in ampr-ripd, it can uniquely add the multicast address to the correct interface (which is already known in ampr-ripd).
Marius ? What about changing this?
Rob
Hello XYLs and OMs,
The modified version of ampr-ripd according to Rob's sugestion to use MCAST_JOIN_GROUP and be interface specific is available for download at at www.yo2loj.ro under hamprojects.
Direct links: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.6.tgz http://www.yo2loj.ro/hamprojects/ampr-ripd-1.6.tgz
Download, compile and have fun.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Rob Janssen Sent: Tuesday, October 08, 2013 22:43 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] 44Net Digest, Vol 2, Issue 162
Marius ? What about changing this?
Rob
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@amsat.org napisał(a):
(Please trim inclusions from previous messages) _______________________________________________
Subject: Re: [44net] 44Net Digest, Vol 2, Issue 159 From: sp2lob sp2lob@tlen.pl Date: 10/07/2013 09:49 PM
To: AMPRNet working group 44net@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