Problem with the current IPTV setup and igmpproxy V04-7

marc67 · 26 May 2023 17:56

Hello,
maybe there is a problem with the current igmpproxy V04-7 from the IPFire package.
(And otherwise, which is also (really, really!) possible, that I make a mistake of course)

I’ve tried to install the igmpproxy one week ago, on my IPFire 2.27 (x86_64) - Core-Update 174.
I’ve checked my ISP (Telekom) Account first, and it is obviously a BNG FTTH Type.

At first, after the igmpproxy installation with Pakfire everything seems to be normal, on the System/Dialup page
from the IPFire GUI appear the option IPTV/VLAN “on/off” and INET_VLAN 7 IPTV_VLAN 8 with IP-Address 192.168.X.XX/32, which i can’t determine where it comes from, but 192.168.X.X is the Address-Space of my RED Interface.

(… I’m a little bit confused about VLAN ID8, because in the IPFire Wiki site with the igmpproxy is that VLAN8 is
no longer used for BNG)

Then I do the following steps:

I make the MAC entries in the GUI at Network/Assign MAC Address as recommended
I stopped the connection in the GUI System/Home Main page to change the status of the igmpproxy from “off” to “on” on the System/Dialup page and save the changes.
I copy the igmpproxy.conf (the BNG-based on from wiki.ipfire.org - igmpproxy) in /etc/ and the firewall.local in /etc/sysconfig/ with Filezilla

After a restart during the next boot, I notice a “File not found …” Error message on the Monitor. I check the
firewall.local file and compare the paths and find out that the path for the igmpproxy in the firewall.local
(/usr/local/sbin/igmpproxy /etc/igmpproxy.conf &) is not the same as the path in my IPFire installation
(/usr/sbin/igmpproxy). After I change the path in the File and reboot, the Error message disappears.

But the next Error that appear I can’t fix: “igmpproxy: no process found” … and an Error message for red0.8 (VLAN8 tagging) was also new.
Additionally, in the GUI at the Status/Services Status information page the igmpproxy Add-On should be listed
under “Add-On-Services” I guess? There is nothing.

I also try a fresh installation with IPFire 2.27 - Core-Update 172 and 170. Firstly I think I can get an older Version of igmpproxy (e.g. v0.3)in this way, but what is naturally not possible because Pakfire delivers only the actually Version of the add-on’s, I don’t realize that before, because I’m a rookie.

Anyway, at least I can say I have tested two other Versions of IPFire, with the same result as it appear in 174.

I take a look in the log files and the “install-” and “uninstall-ipmpproxy.log”, but I can’t see any Failures there (because I haven’t the experience that is necessary for it).

install-ipmpproxy.log:

Extracting files...
etc/
etc/igmpproxy.conf
usr/
usr/sbin/
usr/sbin/igmpproxy
var/
var/ipfire/
var/ipfire/backup/
var/ipfire/backup/addons/
var/ipfire/backup/addons/includes/
var/ipfire/backup/addons/includes/igmpproxy
...Finished.
Extracting files...
etc/
etc/igmpproxy.conf
usr/
usr/sbin/
usr/sbin/igmpproxy
var/
var/ipfire/
var/ipfire/backup/
var/ipfire/backup/addons/
var/ipfire/backup/addons/includes/
var/ipfire/backup/addons/includes/igmpproxy
...Finished.
Restoring Backup...
etc/igmpproxy.conf
...Finished.

But I found some messages in the messages text file, but sadly I forgot with which combination of (slight modified) igmpproxy.conf and firewall.local files that happen - sorry …
(I also tested uninstallation and new installation of igmpproxy of course …)

May 18 21:26:05 router1 igmpproxy[8107]: Unknown token 'pphyint' in configfile
May 18 21:26:05 router1 igmpproxy[8107]: Unable to load config file...

May 18 21:31:04 router1 pakfire: PAKFIRE INFO: IPFire Pakfire 2.27-x86_64 started!
May 18 21:31:04 router1 pakfire: PAKFIRE RESV: igmpproxy: Resolving dependencies...
May 18 21:31:04 router1 pakfire: PAKFIRE INFO: Pakfire has finished. Closing.

May 18 21:32:41 router1 pakfire: PAKFIRE INFO: IPFire Pakfire 2.27-x86_64 started!
May 18 21:32:41 router1 pakfire: PAKFIRE INFO: Packages to remove:
May 18 21:32:41 router1 pakfire: PAKFIRE INFO: igmpproxy ^I - 30.00 KB
May 18 21:32:41 router1 pakfire: PAKFIRE REMV: igmpproxy: Decrypting...
May 18 21:32:41 router1 pakfire: CLEANUP: tmp
May 18 21:32:41 router1 pakfire: DECRYPT STARTED: igmpproxy
May 18 21:32:41 router1 pakfire: DECRYPT FINISHED: igmpproxy - Status: 0
May 18 21:32:41 router1 pakfire: PAKFIRE REMV: igmpproxy: Removing files and running post-removing scripts...
May 18 21:32:41 router1 pakfire: CLEANUP: tmp
May 18 21:32:41 router1 pakfire: PAKFIRE REMV: igmpproxy: Finished.
May 18 21:32:41 router1 pakfire: PAKFIRE INFO: Pakfire has finished. Closing.

May 18 21:37:56 router1 pakfire: PAKFIRE INFO: IPFire Pakfire 2.27-x86_64 started!
May 18 21:37:56 router1 pakfire: DB INFO: packages_list.db is 492 seconds old. - DEBUG: noforce
May 18 21:37:57 router1 pakfire: PAKFIRE RESV: igmpproxy: Resolving dependencies...
May 18 21:37:57 router1 pakfire: PAKFIRE INFO: Packages to install:
May 18 21:37:57 router1 pakfire: PAKFIRE INFO: igmpproxy ^I - 30.00 KB
May 18 21:37:57 router1 pakfire: PAKFIRE INFO: Total size: ^I ~ 30.00 KB
May 18 21:37:57 router1 pakfire: PAKFIRE INFO: Interaction skipped.
May 18 21:37:57 router1 pakfire: PAKFIRE INST: igmpproxy: Decrypting...
May 18 21:37:57 router1 pakfire: CLEANUP: tmp
May 18 21:37:57 router1 pakfire: DECRYPT STARTED: igmpproxy
May 18 21:37:57 router1 pakfire: DECRYPT FINISHED: igmpproxy - Status: 0
May 18 21:37:57 router1 pakfire: PAKFIRE INST: igmpproxy: Copying files and running post-installation scripts...
May 18 21:37:57 router1 pakfire: CLEANUP: tmp
May 18 21:37:57 router1 pakfire: PAKFIRE INST: igmpproxy: Finished.
May 18 21:37:57 router1 pakfire: PAKFIRE INFO: Pakfire has finished. Closing.

My humble idea is that possibly the igmpproxy.exe v04-7 itself is broken, because the start-command in the firewall.local is IMHO correct, or maybe a problem in the install-routines? And - the forum posts that I found and the wiki-page were written in time of the former v03 of igmpproxy, which is (probably) working?

I don’t know - can you help please?

bonnietwin · 27 May 2023 09:08

I just did the updates for igmpproxy to 0.3 and then to 0.4 as they had been available for some time but not updated.

I don’t use igmpproxy so was not able to test it at all. The change to 0.4 was in CU173. Your feedback is the first since that update.

The changelog for 0.4 was relatively small

Changelog
* Release version 0.4

Complement phyint whitelist with blacklist
Fixes: #54
Implement new phyint configuration option (blacklist), which enables
blocking of specific traffic.

Chroot and drop privileges after startup
With this PR:

The apparent root directory can be changed after startup, thus denying
igmpproxy access to files and commands outside that environmental
directory tree.

igmpproxy can drop root privileges after startup by changing id to
another user.

Add travis apt repositories for Ubuntu Precise

I don’t know if any of those changes could have caused the sort of issues you are seeing.

I don’t believe that any of the IPFire devs use igmpproxy but if any of them do, hopefully they can give input.

I suspect they were probably written in the time of version 0.2.1 back in 2019 or even earlier.

bonnietwin · 27 May 2023 09:12

It does not show up there because it has not been defined as a service. There is no initscript defined for it. In the wiki page there are start stop reload commands defined into rc.local but no status command.
The add-services table works by querying the status command in the initscript located at /etc/init.d/ so that won’t work with commands in rc.local.

bonnietwin · 27 May 2023 11:48

I have looked through the history of igmpproxy. The directory was changed from
/usr/loca/sbin/igmpproxy to /usr/sbin/igmpproxy
in Core Update 103 in 2016. This was while the version of igmpproxy stayed at 0.1

That is clearly an error in the wiki that has never been updated by anyone that uses igmpproxy.

I will modify that - done.

bonnietwin · 27 May 2023 12:11

The reason for this error is that you have written pphyint instead of phyint in the config file.

That would also stop the igmpproxy program starting as the config file is unable to be loaded.

marc67 · 28 May 2023 15:08

Hey, thank you very much for support & the explanations, this make something more clearly for me.

Sorry for my mistake with pphyint, I’ve corrected that, but the problem still exists:
May 28 13:17:04 router1 igmpproxy[5109]: MRT_DEL_MFC; Errno(2): No such file or directory

… and also during the boot-process the Monitor shows the message “igmpproxy: no process found” as I describe above.

If I log in as root on the console, I can obviously start igmpproxy with
igmpproxy /etc/igmpproxy.conf
without any error message at the prompt, it seems that it can run in general, but I can’t find out more up to this point.

cfusco · 28 May 2023 17:18

In the wiki there is also a section where it is suggested to start igmpproxy in rc.local. That entry is redundant with firewall.local and that could generate the error message with a second call to the program.

The other alternative is that there is something in /etc/igmpproxy.conf that prevents the program to correctly start. I would make sure you are not copying and pasting some invisible character or using a wrong syntax.

Finally, there seems to be a problem with the Multicast Forwarding Cache which is the data structure used by igmpproxy to decide which packet is to be sent to which interface. The error message seems to indicate that the program cannot delete a Multicast Forwarding Cache entry (MRT_DEL_MFC). I think the problem could be related to a non correct configuration of the network interface or the upstream conection. I do not have time now, but as I have an IPTV service, tomorrow I will test my system and report back (it used to work fine with version 173, which is last time I tested it). Even if we have different providers with different settings, at least we can exclude a problem with IPFire.

You need to know the configuration of the IPTV specific for your provider. In particular whether you have a VLAN dedicated to the IPTV service or the traffic is mixed with the rest of the notwork, and you also need to know the network where the content provider is expecting to receive the IGMP messages, which frequently is 224.0.0.0/4 but it can change from provider to provider.

EDIT: reading again the wiki and your initial message, it seems that Deutsche Telekom has updated their network with a Broadband Network Gateway (BNG) at the edges, which would make their network much more optimized and performant. This seems to suggest that the IPTV traffic would not need anymore to be segregated in a separate VLAN, it can come together with the rest of the traffic to the same interface as the provider has more efficient ways to organize the traffic at the gateway (e.g. some advanced QoS or segregating at the IP level).

If this is the case, you need to change the configuration of your connection script for the dial-up to remove the VLAN ID 8 option and change the configuration of igmpproxy.conf from red0.8 to phyint ppp0 upstream ratelimit 0 threshold 1. You can also remove the spoofed ethernet mac address which would not be necessary anymore as this is only necessary to prevent network problems with a VLAN setting.

bonnietwin · 28 May 2023 18:53

If it worked with CU173 then it was working with version 0.4 as CU173 was when igmpproxy-0.4 was implemented.

cfusco · 28 May 2023 18:58

indeed. And it is also working with 174. I tested it. There is an unrelated bug opened for the IP blocklist interfering with IPTV and I need to test the proposed patch (which I will do it tomorrow and report back to the bug tracking system), however when I disable the blocklist IPTV works as usual in my network. There is nothing wrong with IPFire to cause any problem. @marc67 I think you need to have the correct configuration for Telekom:

interface: should be set in the dial-up setting, choosing VDSL without VLAN (could also be PPPoE, whatever gives you an internet connection); No need for segregated MAC addresses
Unicast or Multicast? Likely the latter. If the former, you do not need igmpproxy at all
igmpproxy.conf likely it is what is suggested in the wiki, something like:

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave

##------------------------------------------------------
# Configuration for red (Upstream Interface)
##------------------------------------------------------
phyint ppp0  upstream  ratelimit 0  threshold 1
      altnet 239.0.0.0/8;
      altnet 232.0.0.0/8;
      altnet 217.0.119.194/16;
      altnet 193.158.35.0/24;
##------------------------------------------------------
## Configuration for green0 (Downstream Interface)
# lan interface of ipfire interacting with the iptv-device
##------------------------------------------------------
phyint green0 downstream  ratelimit 0  threshold 1
      altnet 192.168.0.100/32;   #replace with your own reciver IP's

##------------------------------------------------------
# disable all unused interfaces, especially the one connected to the dsl modem
##------------------------------------------------------
phyint wlan0
phyint lo disabled
phyint blue0 disabled # usually IPTV over WIFI does not work 
phyint red0 disabled
phyint tun0 disabled

Firewall: Start igmpproxy in daemon mode and open the firewall to the IPTV traffic putting this in firewall.local

#!/bin/sh
# Used for private firewall rules

# See how we were called.
case "$1" in
start)
      ## add your 'start' rules here
      /usr/sbin/igmpproxy /etc/igmpproxy.conf & #start igmpproxy in the background

      # for igmpproxy
      /sbin/iptables -I IPTVINPUT -i ppp0 -d 224.0.0.0/4 -j ACCEPT
      /sbin/iptables -I IPTVFORWARD -i ppp0 -d 224.0.0.0/4 -j ACCEPT
      # end for igmpproxy
      ;;
stop)
      ## add your 'stop' rules here
      # for igmpproxy
      /sbin/iptables -I IPTVINPUT -i ppp0 -d 224.0.0.0/4 -j ACCEPT
      /sbin/iptables -I IPTVFORWARD -i ppp0 -d 224.0.0.0/4 -j ACCEPT
      killall igmpproxy
      ;;
reload)
      $0 stop
      $0 start
      ## add your 'reload' rules here
      ;;
  *)
      echo "Usage: $0 {start|stop|reload}"
      ;;
esac

this should allow your system to work, assuming that these parameters are correct. Disable the BOGON block list for now as it will interfere with the traffic. There is a patch available but I need to confirm to the developers that it works.

To understand what’s the meaning of all this, it is useful to know what is a multicast service. A multicast is an optimization method for Video/Audio traffic that has to be delivered in parallel to many customers. The service provider receives IGMP join messages telling the Video-server to add the client to the multicast group, the server update its table and then delivers the stream to the entire group.

When you launch your streaming client (such as VLC, Kodi with an IPTV plugin, or Apple TV), the client signals its interest in a specific channel to the IGMP proxy. In the context of IPFire’s configuration, the IGMP proxy is designed to anticipate these requests from the IP addresses indicated under the ‘phyint green0’ stanza.

Upon receiving the request, the IGMP proxy forwards this IGMP join message to the provider’s network, which is designated in the ‘phyint ppp0’ stanza.

In response, the provider’s network starts transmitting the corresponding audio/video stream as multicast traffic. Notably, this isn’t a direct response to the IGMP join message but a result of it - the provider multicasts the requested content to all members of the multicast group, including your client.

Due to the rules established in ‘firewall.local’, IPFire allows this incoming multicast traffic to pass through the firewall, thereby enabling the client to receive the intended stream.

marc67 · 29 May 2023 17:49

Hi, thank you for your very extensive replies here. I will try going forward step by step here.

In the wiki there is also a section where it is suggested to start igmpproxy in rc.local. That entry is redundant with firewall.local and that could generate the error message with a second call to the program.

Yes, I see that. That rc.local file belongs to the non-BNG-Configuration in the upper area of the Wiki-page I guess, I never try both solutions together, but it can be a trap …

The other alternative is that there is something in /etc/igmpproxy.conf that prevents the program to correctly start. I would make sure you are not copying and pasting some invisible character or using a wrong syntax.

Oh yes, good point, I don’t think about it. I copy the igmpproxy.conf and firewall.local in an online tool, clear it from all potential special characters and other invisible stuff. Saved with gedit UTF-8 Unix/Linux, and I control the Syntax and compare it with yours.

Finally, there seems to be a problem with the Multicast Forwarding Cache which is the data structure used by igmpproxy to decide which packet is to be sent to which interface. The error message seems to indicate that the program cannot delete a Multicast Forwarding Cache entry (MRT_DEL_MFC). I think the problem could be related to a non correct configuration of the network interface or the upstream conection. I do not have time now, but as I have an IPTV service, tomorrow I will test my system and report back (it used to work fine with version 173, which is last time I tested it). Even if we have different providers with different settings, at least we can exclude a problem with IPFire.

Today I can’t find out something about that, and it scratches on my border of knowledge here and there … but you go deeper about it in your next thread, so I leave that here for now.

You need to know the configuration of the IPTV specific for your provider. In particular whether you have a VLAN dedicated to the IPTV service or the traffic is mixed with the rest of the notwork, and you also need to know the network where the content provider is expecting to receive the IGMP messages, which frequently is 224.0.0.0/4 but it can change from provider to provider.

I do some research before I start, and for my Provider Telekom I find the following IP Addresses in actually pages not older than two years, ao I have listed them all in my igmpproxy.conf under my red interface:

phyint ppp0  upstream  ratelimit 0  threshold 1
      altnet 224.0.0.0/4;
      altnet 232.0.0.0/8;
      altnet 87.141.0.0/15;
      altnet 217.0.0.0/16;

EDIT: reading again the wiki and your initial message, it seems that Deutsche Telekom has updated their network with a Broadband Network Gateway (BNG) at the edges, which would make their network much more optimized and performant. This seems to suggest that the IPTV traffic would not need anymore to be segregated in a separate VLAN, it can come together with the rest of the traffic to the same interface as the provider has more efficient ways to organize the traffic at the gateway (e.g. some advanced QoS or segregating at the IP level).

Yes I’ve read also that Telekom something have changed within the step to BNG, and yes I found also some information that says that VLAN ID8 for IPTV is no longer used anymore and IPTV traffic comes over VLAN ID7 now.

If this is the case, you need to change the configuration of your connection script for the dial-up to remove the VLAN ID 8 option and change the configuration of igmpproxy.conf from red0.8 to phyint ppp0 upstream ratelimit 0 threshold 1. You can also remove the spoofed ethernet mac address which would not be necessary anymore as this is only necessary to prevent network problems with a VLAN setting.

I don’t know where my connection script exactly is, I look a bit around today and find in var/ipfire/ppp/ files that called “settings”, these files contend obviously the entries of the Dialup page in the ipfire GUI. I take the one with the last modified date/time, here are some lines of it:

TYPE=vdsl
IPTV=enable
IPTVSERVERS=192.168.XX.XX/32
IPTV_VLAN=8
INET_VLAN=7

For a test, I delete the line with IPTV_VLAN=8 save it to ipfire and do a restart, but during the boot ipfire try always “Creating VLAN Interface red0.8 …” and also nothing changed on the Dialup page in the GUI.

I’ve made the changes in igmpproxy.conf regarding phyint ppp0 as I describe above - but belongs red0.8 not to VLAN ID 8 (and is old/no longer necessary) and red0.7 becomes to ppp0 with VLAN ID 7 is that correct?
With the spoofed MAC you mean the “Assign MAC Address” page from the network menu, right?
I’ve them deleted and ipfire rebooted.

I hope I have time to get further with this in the next few days, thank you very much for your help.
It’s good to know that it works for you - then it must work for me too.

cfusco · 29 May 2023 18:00

First, from the console run setup again, go to the network section, chose the red interface and make sure you chose the correct setup, which should be PPP dialup. Even if you do not change anything, do save it as this should reset all the related configuration files. Then, go in the Web User Interface and create the script by filling up all the relevant fields and saving. Make sure you do not select the VLAN option.

I think so. Unfortunately I can’t test it as my connection is not a dialup, but yes, with PPPoE or VDSL without a VLAN it should become ppp0.

yes

For troubleshooting you might want to start igmpproxy from the command line using the verbose mode or even debug mode. use the igmpproxy -h to see how to do that, I am pretty sure that verbose switch should be igmpproxy -v /etc/igmpproxy.conf, ctrl-c to stop. In the console you should see more logs appearing.