Pi5/OPi5 ka9q-radio network.
st...@ecsykes.com
I am running an RX888 sdr with ka9q-radio on a raspberrypi5. The RPi5 is connected by cat5 to an OrangePi5. I am using the OPi5 because it has audio. The OPi5 is connected to my router using a USB Ethernet dongle. The two pi's are connected via eth0, no router.
The goal is to be able to run control and monitor on the OPi5 and Ka9q-radio on the Pi5, keeping all the multcast streams between the two.
I don't need to get to the internet as long as I can ssh into the OPi5.
I am pretty sure the issue is a routing problem but am not sure how to route the multicast addresses which are in the 239.0.0.0 range.
Any help or a shove in the right direction would be appreciated.
Phil Karn
Hi Steve, Rob told me you were having problems so I made sure to find your email.
The basic problem is (as I understand it) that Linux multicast
routing is distinct from unicast routing, and it's still a bit of
a mystery to me. As I understand it, by default Linux sends
multicast traffic out whatever interface has the default route for
unicast traffic so nothing special has to be done on a system with
only a single interface. Otherwise it gets really complicated.
Have you tried letting radiod's multicast traffic on your
network? Is it actually a problem? How many streams do you expect
to have? A single 12 ks/s @ 16-bit channel stream is 0.02% of a 1
Gb/s link. A control/status stream is even less. Your only likely
problem is with WiFi, if you have lots of streams and it doesn't
support "multicast to unicast conversion" (more about this below).
Or if you have one or more network ports operating at 10 Mb/s
(original Ethernet speed), they would get clogged first if you had
that much multicast traffic.
If you must keep multicast traffic off the rest of your network,
by far the quickest fix is a small "smart" Ethernet switch with
IGMP snooping. Both the RPI5 and OPI5 will pick up IP addresses
from your regular network and look as if they are directly on it,
so everybody can talk to everybody else without any routing
hassles. No need for an Ethernet dongle on the OPI5 either.
But Linux has a "bridge" driver that is a complete smart Ethernet
switch, and recently I discovered that it *does IGMP snooping*.
You configure it, give it one or more physical interfaces (e.g.,
the built in ethernet and the USB ethernet on your OPI5), and it
acts just like an external switch, sending both multicast and
unicast traffic only where it's wanted.
It might even be possible to use only one Ethernet on the OPI5
(no USB dongle) and still keep multicast traffic off your house
network. The switch already knows who's in each multicast group,
so by setting the "multicast to unicast conversion flag" the
switch sends separate copies of each incoming multicast packet to
each group member with all the correct unicast Ethernet addresses
in the destination fields. No multicast packets reach your regular
home network, and the unicasts only go where they're supposed to
go.
My own access point (which runs OpenWRT, a special version of
Linux), does this so multicasting works great over WiFi. I run
'monitor' and 'control' on my laptop all the time.
I'll test this and let everyone know if it works. It also
promises to solve Rob's problem of wanting only some multicast
streams to leave the sending machine. He wants to do this by
setting different TTL values on the streams (TTL=0 means local
loopback only; don't let it reach the hardware). This is
unnecessary with the bridge driver since IGMP snooping already
knows there are no external group members, so that traffic won't
go over the wire only to be discarded by the other end. It'll be
discarded even before it reaches the physical wire, since it's on
the other side of the virtual switch in the Linux kernel.
Now some TL;DR stuff that I include on background, mainly so it
gets documented somewhere.
Some of my machines, like my RPis, have both wired Ethernet and
WiFi. I sometimes enable both for redundancy in case a cable gets
pulled. (My ethernet and WiFi networks are bridged so both will
work.)
But Linux sends radiod's multicast traffic to whichever interface
comes up first, and it *keeps* doing this even if the one you want
comes up later. I almost always want ethernet, which *usually*
comes up before WiFi. But my smart Ethernet switches have Spanning
Tree Protocol (STP), an artifact of which is a delay before a port
becomes fully operational and DHCP can obtain an IP address. So
radiod sometimes sent its multicast traffic to wlan0 even though
eth0 seemed up and running! Manually restarting radiod caused it
to work properly. This one took a while to find. The fix was to
set those switch ports to "edge" or "fast" mode so they'd come up
without delay. (The startup delay is only needed for ports
connected to other switches, to prevent transient forwarding
loops. I have four switches in my house connected in a fiber
ring.)
I once tried to solve this problem by adding the "iface" keyword to the [global] section of the config file. My intent was to let you manually force a particular interface for multicast traffic. But I have never really used it, and I think I broke it in a code restructuring a few months ago. It will still select the interface on which to *listen* for multicast traffic (e.g, commands from 'control' and 'tune') but output streams always go over the default multicast route, so it's not useful. And I'm not even sure how you do configure Linux multicast routing; I read somewhere that the usual 'ip route add' commands only work for unicast traffic. Again, I just haven't dug into this because I've avoided the problem.
In any event you have the thorny problem that you want some of
your multicast traffic from the OPi5 to go to the RPi5, and some
of it to go to your house network. That requires multicast routing
on the OPi5, which I don't know how to do yet, especially since
the 239/8 addresses are created from a random hash of the DNS
name. Bridging is the only answer, whether in an actual external
smart switch or hopefully in the internal Linux bridge driver.
BTW, it would seem like I should just accept multicast traffic on any interface, right? But that's not a good idea. Joining a multicast group on a particular interface causes the kernel to emit IGMP membership messages. Since my wired and WiFi networks are bridged, joining the same group on both will draw in a copy on both wire and WiFi, which is clearly something you don't want.
Phil
--
You received this message because you are subscribed to the Google Groups "ka9q-radio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ka9q-radio/396c4907-70a8-4aca-8917-9f76be49b0c0n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rob Robinett
I have 4 RX888s each connected to a computer, each of which is connected to the same, unmanaged gigabit switch. The latter should pass all traffic and has done so previously. All 4 computers run radiod but only one runs wsprdaemon. That machine merges a wspr stream from each radiod and uploads the best spots to wsprnet and all the spots to wsprdaemon.org.Until this week, when I started reconfiguring things and updating radiod, this all worked.But now, each computer reports uploading data streams (in the 3-4 Mbps range) but no other machine “sees” them and btop on each machine only shows the routine few kbps of “download” traffic on the ethernet. Each knows the addresses of the RTP streams (so avahi-discover and mdns are resolving) but there just doesn't appear to be anything coming across. In short, each of the 4 computers reports it’s putting an RTP stream on its network device, but none of the others sees them. This means the computer running wsprdaemon has nothing to merge.Each computer has a static ip address. The unmanaged switch they connect to, in turn connects to a managed switch with IGMP snooping enabled so the multicast traffic doesn’t swamp the rest of my LAN and WLAN. Until I started the recent reconfiguration and updates, this all worked. As usual, this most likely means I’ve messed something up.But I haven’t, yet, figured out how I broke it.-mjh AC0G
To view this discussion on the web visit https://groups.google.com/d/msgid/ka9q-radio/99384aeb-23d6-4271-a5bd-37cf30138ec3%40ka9q.net.
Michael Hauan
On Jul 3, 2024, at 03:37, Phil Karn <ka...@ka9q.net> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/ka9q-radio/99384aeb-23d6-4271-a5bd-37cf30138ec3%40ka9q.net.