[os-igmp-proxy] igmproxy not working since 18.1.3 - There must be at least 1 Vif as upstream

[rx-tx]

Hello,
i am running OPNsense 18.1.3 with igmpproxy plugin 1.3 together with german telekom IPTV service.
The solution already worked with OPNsense 18.x just fine. After upgrading to 18.1.3 i recognized that the igmpproxy service does not come up.
The error in the log file is:

igmpproxy[20043]: There must be at least 1 Vif as upstream.

The igmpproxy service configuration is not changed, so there is one upstream interface (outside_pppoe) and one downstream interface (inside_untagged).

Maybe there is an issue with VLAN tagging, because the PPPoE interface is a tagged interface within an APU board. I tested to choose an untagged interface for the igmp upstream interface and the service started successfully. As soon as i switch back to my tagged PPPoE interface the service cannot start with the above error message.

Also tried to re-create the igmp configuration, but no change.

Any ideas or things i can check?

[fichtner]

igmpproxy was revived after many years of no updates. Unfortunately, several "forks" existed that did things slightly different. For now you can bring it back with:

# opnsense-revert -r 18.1.2 igmpproxy

The better question: what is your upstream interface setup like? We would like to report this upstream.

[rx-tx]

Just verified - same issue with 18.1.4.

Installed igmpproxy from 18.1.2 and it works again.
Did not see anything related to igmpproxy in the release notes for 18.1.3.

The configuration is as follows:

a) physical interface - tagged (IEEE 802.1Q) ethernet interface w/ VLAN ID 7

igb2_vlan7: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=400000<TXCSUM_IPV6>
ether 00:0d:b9:xx:xx:xx
inet6 fe80::20d:b9ff:fexx:xxxx%igb2_vlan7 prefixlen 64 scopeid 0x9
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT )
status: active
vlan: 7 vlanpcp: 0 parent interface: igb2
groups: vlan

b) PPPoE on top of igb2_vlan7 (OUTSIDE_PPPOE)
see attached screenshot

c) igmpproxy configuration (upstream interface):

OUTSIDE_PPPOE upstream 224.0.0.0/4, 193.158.0.0/15

[rx-tx]

Just verified with 18.1.5 and included igmpproxy 0.2.1 from https://github.com/pali/igmpproxy/tree/0.2.1 - same issue.
Workaround with "opnsense-revert -r 18.1.2 igmpproxy" helps.

[micressor]

Same problem with 18.1.8. I haven't tested the workaround yet.

[thomasnilsen]

Any update on this? Not beeing able to use igmpproxy is a huge disadvantage.

I run 18.7 and when I try to perform "opnsense-revert -r 18.1.2 igmpproxy" I get, "Fetching igmpproxy.txz: .. failed".

[fichtner]

Yep, somebody is working on it: pali/igmpproxy#38

# pkg add -f https://pkg.opnsense.org/FreeBSD:11:amd64/18.1/MINT/18.1.2/OpenSSL/All/igmpproxy-0.1_2,1.txz

[thomasnilsen]

I tried updating and now I get a different error mesage.

adding VIF, Ix 0 Fl 0x0 IP 0x01ca000a re1_vlan202, Threshold: 1, Ratelimit: 0 There must be at least 2 Vif's where one is upstream.

My upstream interface should be re0_vlan102 and for my config it seems allright. Probably another thing that is worked on to be fixed or?

@fichtner Tried tearing down the config and rebuilding in oposite direction. Now with downstream defined before upstream in my config igmpproxy is starting! So there is some logical faults in the code for checking presence of interfaces. 👍

[rx-tx]

Just for information: Working configuration at the moment:
OPNsense 18.1.13_1-amd64 + os-igmp-proxy 1.3_1 (with opnsense-revert -r 18.1.2 igmpproxy)

[ljpaff]

@thomasnilsen Did the patch worked in your machine? Could you give me feedback please?

@fichtner There is a rollback in config.c, Please take care about it. If you are doing packages, please make another one with the change.

[thomasnilsen]

@ljpaff I found that pkg add -f https://pkg.opnsense.org/FreeBSD:11:amd64/18.1/MINT/18.1.2/OpenSSL/All/igmpproxy-0.1_2,1.txz worked for me. I had one issue with the VLAN I get multicast on did not have a IP set on the interface. Therefore igmpproxy did not want to start. I fixed that with a dummy ip address.

Things seemed fine to me when I fixed this, but I was unable due to lack of time to fully test this..

[nivek1612]

Note I have the same issue but I'm not using a pppoe interface. I'm a VLAN Tagged interface to Orange France for their IPTV service, the connection is established over VLAN 838 PCP 4 using DHCP. So I believe this isn't just PPPOE related. Regressing to v1.2 of IGMProxy and all is well

[fichtner]

@nivek1612 would you mind trying this version? https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/igmpproxy-0.2.1_1,1.txz

[nivek1612]

I'm not back in France at the minute and dont want to try over VPN just in case I break something :-) so let me ask one of the other guys to try

[fichtner]

no worries. I'll push this update in 18.7.3. I've harmlessly bumped MAX_IF from 40 to 100 to see if that makes a difference. I don't understand the upstream patch and this seemed the only thing that would imply a difference in parsing...

[nivek1612]

For what its worth I have just set up this version of IGMPproxy

https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/igmpproxy-0.2.1_1,1.txz

on my UK system which uses PPPOE and I can now start the IGMPproxy service where as before I could not. I cant fully test it as I dont have access to the Orange IPTV service here in the UK

[fichtner]

@nivek1612 ok... so far so good. Due to a mistake on my side this update won't make the 18.7.3 cut, but that also gives time for others to comment. I also published the CFT in the relevant forum thread. :)

[fichtner]

Due to a build mixup the proposed fix did not make it into 18.7.3 but will be included in 18.7.4.