Your VDSL connection probably is terminated via the new Telekom BNG platform. Here, Entertain and Internet both work via the same VLAN (which is 7). I will post an updated tutorial in the next few days. In general, just do not create an extra interface but add some firewall rules for the WAN interface (IGMP & IPv4 Multicast). And configure igmpproxy accordingly.
that does not seem to be the case for me, my connection seems to be “traditional”
I am conencted to the DSLAM via a DrayTek Vigor 130 on which I disabled the default vlan7 tagging and after that added the VLAN tag to my PPPoE interface, so PPPoE began to work just fine again.
The Telekom somehow fucket it all up and my entertain package was not active for some reason, after some tweets they had found the right button 
and now it works all fine.
1 Like
your blog delivers a 502 atm -.-
but I still have one thing: after a reboot igmpproxy needs to be restarted once to work, it seems to be started too early.
Honestly all related articles for Turris should be in one place, which is Turris documentation.
Otherwise we (as community) will have articles on the whole internet. We should have one place for that.
Here is my current configuration. I’m on the BNG platform afaik, that means there is no separate VLAN for Entertain anymore (makes it simpler).
I switched from igmpproxy to mcproxy which seems to work better (at least for me).
Here is my config:
file /etc/config/mcproxy
config mcproxy 'mcproxy_file'
option disabled '1'
option respawn '1'
option file '/etc/mcproxy.conf'
config mcproxy 'mcproxy'
option disabled '0'
option respawn '1'
option protocol 'IGMPv3'
config instance
option disabled '0'
option name 'proxy1'
list upstream 'pppoe-wan'
list downstream 'br-lan'
In /etc/config/network add igmp_snooping to your lan interface:
config interface 'lan'
...
option igmp_snooping '1'
...
To enable multicast streams via WLAN I had to disable slow modulation and coding schemes. Add the following to the configuration of radio0 and radio1 in /etc/config/wireless:
config wifi-device 'radio0'
...
list supported_rates '18000'
list supported_rates '24000'
list supported_rates '36000'
list supported_rates '48000'
list supported_rates '54000'
list basic_rate '18000'
list basic_rate '36000'
list basic_rate '54000'
config wifi-device 'radio1'
...
list supported_rates '18000'
list supported_rates '24000'
list supported_rates '36000'
list supported_rates '48000'
list supported_rates '54000'
list basic_rate '18000'
list basic_rate '36000'
list basic_rate '54000'
Via the webinterface (luci) I added the following firewall rule (Network → Firewall → Traffic Rules):
(Additionally, there should be a rule allowing IGMP from WAN to your router. But this is a default rule I guess.)
Let me know if this helps you or if I missed something.
1 Like
Hey,
since Turris OS 3.9.2 mcproxy doesn’t start anymore.
https://forum.test.turris.cz/t/mcproxy-doesnt-start-since-turris-os-3-9-2/6330
Has anyone a solution to fix?
See my reply in the thread you linked.
Here is another addition. As I had problems with mcproxy not running, I created a cronjob to check whether it is running via the file /etc/cron.d/mcproxy:
MAILTO=""
* * * * * root /bin/pgrep mcproxy > /dev/null || /etc/init.d/mcproxy startI am not able to get it back working even with the config u posted in the other thread 
Entertain is not working anymore.
I’m currently also having problems with Entertain not working, however my mcproxy is running and also picking up the IGMP messages from my LAN and forwarding them to pppoe-wan. But no TV. I’m already looking into it and will let you know when I can solve the problem.
I’m observing the following: IGMP messages going out on the upstream interface (pppoe-wan in my case) have 0.0.0.0 as source address:
23:51:33.754128 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 48, options (RA))
0.0.0.0 > 224.0.0.22: igmp v3 report, 2 group record(s) [gaddr 239.35.10.48 to_in { }] [gaddr 239.35.10.4 to_ex { }]
As far as I know, the source address should be the public, routable IPv4 address of the upstream interface (pppoe-wan). Or am I wrong here?
I’m observing this behavior independent of whether I use mcproxy or igmpproxy. Therefore, I guess this is a kernel problem which maybe was introduced by some of the recent updates. Does anybody of the turris team (@turris-admin ?) have any idea in regard to the problem described here?
Forcing IGMP to version 2 helps for me:
echo 2 > /proc/sys/net/ipv4/conf/pppoe-wan/force_igmp_version
However, this only seems to be a workaround.