0

I have a problem with multicast routing on a "from scratch" (Debian, not LFS ;)) linux router/firewall. At home I've set up a user and a server net. Between the two is a router/firewall (APU2E4 board) which, among other things, should route media data (UPnP) from the media server (container on a Proxmox VE server) to the clients. I use smcroute for that. For months that has been going fine - and from one moment to the other it stops working (haven't change a bit of the configuration). (I had similar problems before two or three times but could "resolve" them by just restarting the firewall.)

A while after starting smcroute tcpdump doesn't detect any of the expected multicast packets anymore on the firewall (tcpdump -i enp1s0 host 239.255.255.250 and port 1900). Up to that point the packets do come in on that interface. (I've also checked the other interfaces but there are also no such packets - UPnP - to be found. But that's the expected behaviour since the clients should and can only connect to enp1s0.)

TTL of the packets in question is over 1 (checked on the client host). I even let iptables on the router increment the TTL if such a packet has a value of 1.

When there seem to be no packets coming in on enp1s0 anymore ip maddress still does list that interface as a member of the group:

    2:  enp1s0
        link  33:33:00:00:00:01
        link  01:00:5e:00:00:01
        link  33:33:ff:54:2b:98
        link  01:00:5e:7f:ff:fa
        inet  239.255.255.250
        inet  224.0.0.1
        inet6 ff02::1:ff54:2b98 users 2
        inet6 ff02::1
        inet6 ff01::1

But ip mroute doesn't list the (dynamically set) routes anymore:

Before:

root@gw-srv:~# ip mroute
(10.0.0.20,239.255.255.250)      Iif: enp2s0     Oifs: enp1s0  State:
resolved
(192.168.0.20,239.255.255.250)   Iif: enp1s0     Oifs: enp2s0  State:
resolved
(192.168.0.2,239.255.255.250)    Iif: enp1s0     Oifs: enp2s0  State:
resolved
(192.168.0.1,239.255.255.250)    Iif: enp1s0     Oifs: enp2s0  State:
resolved

After:

root@gw-srv:~# ip mroute
(10.0.0.20,239.255.255.250)      Iif: enp2s0     Oifs: enp1s0  State:
resolved

When I specify a source address like 192.168.0.2 in smcroute.conf the corresponding route doesn't "disappeare" (10.0.0.20 is the media server on the other subnet). The problem still resides, however.

I also tested with iperf on the router whether multicast generally works between the two hosts:

Router: iperf -s -u -B 239.255.255.250 -i 1

Client: iperf -c 239.255.255.250 -u -T 32 -t 3 -i 1

When smcroute was just started the server receives the packets. Some minutes later nothing comes in (until I restart smcroute or manually leave the multicast group). When I use any other multicast address at that point (e.g. 239.255.255.249) the packets do get to the firewall (iperf server). And when smcroute isn't running at all the problem doesn't occur (with 239.255.255.250).

All in all it seems to me that when a multicast route has been established some minutes later the router isn't able to receive multicast traffic to the corresponding address at all anymore.

Can you make sense out of this? So far I could't find a hint regarding such a problem.

Many thanks for suggestions.

  • Multicast routing is very different than unicast routing. Multicast routing uses protocols like IGMP and PIM to send multicasts to networks where they have been requested, and to prevent multicasts from overloading a network. Trying to route multicast via unicast routing is not something you want to do. – Ron Maupin Jul 18 '20 at 20:45
  • So I should rather use mrouted or similar in this situation? (But still it worked for months since some days ago. That has to have a reason...) – The Becheesus Jul 18 '20 at 20:49
  • You should run IGMP on the router interfaces so that the router know when a host in that network wants multicast, and you use PIM to actually route multicast. PIM can also route multicasts between routers. There are real reasons that multicast routing is different than unicast routing. – Ron Maupin Jul 18 '20 at 20:51
  • Thanks for the hint. I will look into that. – The Becheesus Jul 18 '20 at 20:56

0 Answers0