Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Igmpproxy is not starting if upstream interface is a pppoe interface #28

Open
micharambou opened this issue Apr 16, 2018 · 13 comments
Open

Comments

@micharambou
Copy link

micharambou commented Apr 16, 2018

I'm running igmpproxy within OPNsense 18.1.6.
Since 0.1_2,1 -> 0.2.1,1 update igmpproxy fails to start if upstream interface in igmpproxy.conf is a vlan tagged pppoe interface.

In my case uppstream Interface is pppoe on a vlan tagged interface.

/usr/local/etc/igmpproxy.conf`

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint pppoe0 upstream ratelimit 0 threshold 1
altnet 224.0.0.0/24
altnet 87.141.215.0/24

phyint igb0 downstream ratelimit 0 threshold 1
altnet 192.168.100.0/24
root@OPNsense:~ # /usr/local/sbin/igmpproxy -d -vv /usr/local/etc/igmpproxy.conf
Searching for config file at '/usr/local/etc/igmpproxy.conf'
Config: Quick leave mode enabled.
Config: Got a phyint token.
Config: IF: Config for interface pppoe0.
Config: IF: Got upstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
Config: IF: Got altnet token 224.0.0.0/24.
Config: IF: Altnet: Parsed altnet to 224.0.0/24.
Config: IF: Got altnet token 87.141.215.0/24.
Config: IF: Altnet: Parsed altnet to 87.141.215/24.
IF name : pppoe0
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 1
Allowednet ptr : 8182b000
Config: Got a phyint token.
Config: IF: Config for interface igb0.
Config: IF: Got downstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
Config: IF: Got altnet token 192.168.100.0/24.
Config: IF: Altnet: Parsed altnet to 192.168.100/24.
IF name : igb0
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 2
Allowednet ptr : 8182b020
Config: Got a phyint token.
Config: IF: Config for interface igb2.
Config: IF: Got disabled token.
IF name : igb2
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
buildIfVc: Interface igb0 Addr: 192.168.100.1, Flags: 0xffff8843, Network: 192.168.100/24
buildIfVc: Interface igb2 Addr: 192.168.200.1, Flags: 0xffff8843, Network: 192.168.200/24
buildIfVc: Interface lo0 Addr: 127.0.0.1, Flags: 0xffff8049, Network: 127/8
buildIfVc: Interface ovpns1 Addr: 10.10.0.1, Flags: 0xffff8051, Network: 10.10.0.1/32
Found config for igb0
Found config for igb2
adding VIF, Ix 0 Fl 0x0 IP 0x0164a8c0 igb0, Threshold: 1, Ratelimit: 0
        Network for [igb0] : 192.168.100/24
        Network for [igb0] : 192.168.100/24
There must be at least 1 Vif as upstream.

It appears that also other users of current OPNSense versions are affected.
https://forum.opnsense.org/index.php?topic=7581.0

However: Downgrading to igmpproxy: 0.1_2,1 as a workaround resolves the issue, while configuration of igmpproxy.conf remains unchanged.

root@OPNsense:~ # opnsense-revert -r 18.1.2 igmpproxy
Fetching igmpproxy.txz: ... done
Verifying signature with trusted certificate pkg.opnsense.org.20171219... done
igmpproxy-0.2.1,1: already unlocked
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	igmpproxy: 0.1_2,1

Number of packages to be installed: 1
[1/1] Installing igmpproxy-0.1_2,1...
Extracting igmpproxy-0.1_2,1: 100%
root@OPNsense:~ # /usr/local/sbin/igmpproxy -d -v /usr/local/etc/igmpproxy.conf
adding VIF, Ix 0 Fl 0x0 IP 0x0164a8c0 igb0, Threshold: 1, Ratelimit: 0
adding VIF, Ix 1 Fl 0x0 IP 0x01000a0a ovpns1, Threshold: 1, Ratelimit: 0
adding VIF, Ix 2 Fl 0x0 IP 0x64968454 pppoe0, Threshold: 1, Ratelimit: 0
joinMcGroup: 224.0.0.2 on igb0
joinMcGroup: 224.0.0.2 on ovpns1
RECV V2 member report   from 192.168.100.1   to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV Membership query   from 192.168.100.1   to 224.0.0.1
RECV Membership query   from 10.10.0.1       to 224.0.0.1
RECV V2 member report   from 192.168.100.3   to 232.0.20.120
Inserted route table entry for 232.0.20.120 on VIF #0
joinMcGroup: 232.0.20.120 on pppoe0
Adding MFC: 87.141.215.251 -> 232.0.20.120, InpVIf: 2
RECV V2 member report   from 192.168.100.3   to 239.255.255.250
Inserted route table entry for 239.255.255.250 on VIF #0
joinMcGroup: 239.255.255.250 on pppoe0
@fichtner
Copy link

To complete this already outstanding report: we have actually used a custom patch on 0.1 to allow VLAN use opnsense/ports@1c9e9c2850670cdc

@pali
Copy link
Owner

pali commented Apr 17, 2018

That is strange. I'm normally using igmpproxy 0.2.1 (top of master branch) with vlan tagged interfaces as both upstream and downstream and it is working fine. But it is on Linux kernel. OPNsense IIRC uses FreeBSD.

I do not have right now any BSD box for multicast routing, so cannot debug where can be a problem. Are you able to bisect which commit broke it?

@pali
Copy link
Owner

pali commented Apr 17, 2018

Config: IF: Config for interface igb2.

Are you sure that you posted correct content of igmpproxy.conf file? Because it does not contain section for igb2.

@pali
Copy link
Owner

pali commented Apr 17, 2018

@fichtner so does it mean that vlan tagged interfaces did not work even for igmpproxy 0.1 on OPNsense?

@fichtner
Copy link

@pali yes, don't think it was in the original 0.1 (see patch mentioned above) so it's likely not found by bisect. I could try to apply said patch again on top of 0.2.1 but I was under the impression VLAN was working in 0.2, we did a couple of user tests and they said it was ok...

@pali
Copy link
Owner

pali commented Apr 17, 2018

Ok, so you have been using patched 0.1 version and after upgrading to unpatched 0.2 it stopped working. Can you check if unpatched 0.1 really does not work? If yes, then there is no regression and no need to bisecting. But somebody with BSD knowledge should write proper support for vlan.

@micharambou micharambou changed the title Igmpproxy is not starting if upstream interface is a vlan tagged interface Igmpproxy is not starting if upstream interface is a pppoe interface Apr 17, 2018
@micharambou
Copy link
Author

Further investigations showed that the issue is not caused by a tagged upstream interface but by the pppoe interface itself (no matter if the underlying interface is vlan tagged or not). Sorry for the confusion.

@FrankPoh
Copy link

I can confirm. If Upstream is an PPPOE interface, igmpproxy is not working "At least one FIY has to be..." (Error message). When i change to a static interface, igmpproxy is comming up.

@fichtner
Copy link

This would make sense then... VLAN worked as reported, but we never specifically tested for PPP(oE) because no issues were know. As to whether this is a regression or not that opens up the field again. I'll prepare an unpatched version of 0.1 for the guys to test on their OPNsense to see if this was a regression or not.

@ljpaff
Copy link

ljpaff commented Jul 26, 2018

Dear friends,

I have the same problem on a Watchguard XTM 5Series with PFSense 2.4.3 (FreeBSD). I have an interface named em0 (PPPoE) which has two VLAN configured:

  • em0.6 : Which is for internet connection
  • em0.2 : Which is for IPTv connection.

I have configured igmproxy with interface em0.2 as upstream. When I start igmproxy it fails with "There must be at least 1 Vif as upstream." message. If I change it with a DHCP or Static normal connection it works ok.

Is there any workaround in progress for this issue?

Best Regards

@ljpaff
Copy link

ljpaff commented Jul 31, 2018

Hi,

I found there was a patch for this problem dated 2 years ago. I think this patch is missing:

https://redmine.pfsense.org/issues/6099#note-86

Best regards

@pali
Copy link
Owner

pali commented Jul 31, 2018

It would be great if you cold prepare patches to this upstream project instead of maintaining downstream patches... As from this could benefit more people. I'm not using BSD systems, therefore I cannot develop nor test such system specific patches.

@nivek1612
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants