OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: frank_p on March 13, 2018, 08:55:44 pm
-
Update to V18.1.4 went great. Thanks for that big job !!
FW run without any issue.
BUT
After Update to V18.1.4 (it run), i updated some hours later one of my firewall alias. After reload, the rules, the IGMPProxy (V1.3) is not longer starting (message in logfile: igmpproxy[62733]: There must be at least 1 Vif as upstream.
Config of IGMPProxy is not changed.
Can't find the issue.
Does anybody knows that issue?
-
Hi,
how does your config file look like?
can you check whether your /usr/local/etc/igmpproxy.conf has a valid upstream config?
Br br
-
The config is not changed since months. So i guess, this should work under updated conditions also.
Please find attached the upstream parameter in ipgmproxy.conf.
quickleave
phyint pppoe0 upstream ratelimit 0 threshold 1
altnet 232.0.0.0/8
altnet 239.0.0.0/8
altnet 217.0.119.194/16
altnet 193.158.35.0/24
Just to add:
This runs in Telekom-Germany enviroment:
Connection via Draytec modem.
Networktype = BNG.
Modem is not making any manipulation.
pppoe session is opened from opensense
VLAN Tagging makes opensense.
br
frank
-
Hi frank,
That would relates to another thread I had responded... Since 18.1.4, igmpproxy is not working anymore while on VLAN... VLAN is by me set on the interface of the VM and not in OPNSense. That was working on 18.1.3.
I've here temporarily disabled the VLAN and it seems to be working again
Cheers,
Nick
-
So OPNsense-terminated VLAN is not working in the 0.2 imgpproxy version? It's a bit of a surprise because I asked several testers with a use case to try this...
In any case, we can report this upstream, but I need a tester who is willing to work with the author.
https://github.com/pali/igmpproxy/issues
Also, it should work if you do this:
# opnsense-revert -r 18.1.2 igmpproxy
Cheers,
Franco
-
Thanks Nivok.
Same effect with Tagging in OpnSense or Tagging in Modem.
IGMPProxy is coming with the error"There must be at least 1 Vif as upstream."
@Franco:
Not sure what the root cause is. But no difference where i do the tagging.
Interessting that it stopped working after i updated a firewall rule (this rule has nothing to do with IPTV)
I have no testing platform, but probably i can support somehow....
br
Frank
** Update**
reverted to V1.2 -> Igmpproxy is coming up and running
-
Hi Nivok,
does your upstream- interface is a pppoe-interface ?
I changed the upstream-interface to an interface which is not pppoe, and igmpproxy started.
It seems to me, that igmpproxy is not starting when the upstream-interface is linked to an pppoe-interface.
br
frank
-
does your upstream- interface is a pppoe-interface ?
Hi Frank,
Nope, the IPTV is not on a pppoe upstream, but my second WAN is, maybe it is causing the issue... I haven't tested yet the downgrade of igmpproxy, will do it over the weekend... Also these days (since 18.1.4) I have loads of weird phenonemals with opnsense which almost always means I've to reboot... That's something else, but if I for instance re-tag my if with VLAN, then opnsense "somehow" looses the gateway untill restart (even though tagging is done on the switch/hypervisor side)
Cheers,
Nick
-
Same problem here. My igmpproxy.conf:
quickleave
phyint igb0 downstream ratelimit 0 threshold 1
altnet 192.168.1.0/24
phyint igb1_vlan2 upstream ratelimit 0 threshold 1
altnet 172.0.0.0/8
phyint pppoe0 disabled
phyint igb1_vlan3 disabled
Cheers!
-
Would someone with the ability to test open a ticket with the author? https://github.com/pali/igmpproxy/issues
We do have an older patch set where this works as intended, maybe pali will spot the required change?
https://github.com/opnsense/ports/commit/1c9e9c2850670cdc2cd34c4a3bfa2b3faa981e17#diff-1261a7dfce4c25aa9003f5bf9d836136
I will provide test builds...
Cheers,
Franco
-
Franco, all tester,
apologize that i am not able to test, or to provide test enviroment.
Not sure how some testing activities run.
Is the new fork V0.2 supporting IGMPV3 and VLAN ?
regards, Frank
-
If I disable the OpenVPN server, igmpproxy can be started manually (or rebooting) with no problem so, maybe, it's not VLAN related.
Cheers,
-
Yep, same for me.
-
same here....
-
I can confirm the issue.
Upstream Interface pppoe on a vlan tagged interface. Downgrading igmpproxy resolves the issue. However - igmpproxy.conf remains unchanged since prior update.
root@OPNsense:~ # cat /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
System Log:
Apr 17 01:15:51 igmpproxy[41961]: There must be at least 1 Vif as upstream.
Apr 17 01:15:51 igmpproxy[74057]: select() failure; Errno(4): Interrupted system call
Apr 17 01:15:42 pkg-static: igmpproxy upgraded: 0.1_2,1 -> 0.2.1,1
-
It looks more like an issue with PPP instead of VLAN? At least igmpproxy shouldn't care whether a VLAN is under the PPP or not.
Cheers,
Franco
-
You are right.
It appears that i forgot one more step to investigate the issue.
I just changed upstream interface configuration to a non tagged pppoe Interface -> igmpproxy init failed.
However, changing upstream interface to a tagged non pppoe interface (e.g. static configuration) brought igmpproxy back to life.
I will change the failure report on Github...
-
This is the same error-pattern i have. PPPOE Upstream interface = not starting, static upstream interface = starting. I confirmed in git.
-
Thanks guys, as promised in the upstream ticket here is an unpatched version of igmpproxy prior to pali's fork:
# pkg add -f https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/igmpproxy-0.1_2,1.txz
It will not work with VLAN, but chances for PPP(oE) are 50-50 so we can see if this is a new bug or still a missing feature that our VLAN patch somehow fixed at the same time.
Cheers,
Franco
-
I have tried that package and the problem is still there while openvpn server is active so we're in the 'bad' 50... ;)
Cheers,
-
Can you post your igmpproxy config file for reference?
Thanks,
Franco
-
You posted already, I see. No changes there since that post?
-
No, no changes. The igmproxy configuration is the same for one year.
Cheers,
-
Appears to be fixed in 18.1.8
-
There was no patch to address this yet, not sure what changed for you?
Cheers,
Franco
-
Yes I'm somehow confused too.
I just made an upgrade to 18.1.8 on a previous installation and reset to factory defaults to get a clean start.
After setting up the configuration i was suprised, that igmpproxy came up without any issues...
root@OPNsense:~ # cat /usr/local/etc/igmpproxy.conf
##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint pppoe0 upstream ratelimit 0 threshold 1
altnet 87.141.215.0/24
altnet 224.0.0.0/24
phyint bridge0 downstream ratelimit 0 threshold 1
altnet 192.168.100.0/24
phyint igb0 disabled
phyint igb2 disabled
root@OPNsense:~ # igmpproxy -h
Usage: igmpproxy [-h] [-n] [-d] [-v [-v]] <configfile>
-h Display this help screen
-n Do not run as a daemon
-d Run in debug mode. Output all messages on stderr. Implies -n.
-v Be verbose. Give twice to see even debug messages.
igmpproxy 0.2.1
root@OPNsense:~ # opnsense-update
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (18 candidates): 100%
Processing candidates (18 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Nothing to do.
Your system is up to date.
Am I missing something?
-
I have just upgraded to 18.1.8 and the problem is still there. No changes.
Cheers,
-
Same here... no changes. IGMPProxy isn't comming up.
best
Frank
-
Same here, igmpproxy 0.2.1 on a PPPoE upstream is not starting.
After reverting to igmpproxy 0.1, igmpproxy starts, but it only supperts IGMP v2, but for Deutsche Telekom EntertainTV I need IGMP v3, which means igmpproxy 0.2.1.
Best solution would be to fix the problem in the upstream-release of igmpproxy for FreeBSD.
As a dirty workaround, I will try this idea when I am back home today:
1. Setup an virtual IP on the ethernet Interface for the PPPoE-connection.
2. Brigde virtual IP and PPPoE, which should give me a static Interface as upstream for igmpproxy 0.2.1
3. igmpproxy 0.2.1 hopefully starts and provides LAN side IGMP v3
best regards,
Sven
-
Hi SEi
has it worked? as workaround?
regards
Frank
-
Hello Frank,
sorry for my late answer.
I was not lucky, igmpproxy 0.2.1 does not start with a Bridge Interface as upstream.
As a workaround, I switched my DSL modem to router mode and bypassed my opnsense Firewall with a weird VLAN to my media Receiver. So my media Receiver has a direct Internet Connection as only device.
At the Moment I cannot do anything other than wait and hope for a working igmpproxy >= 0.2.1 for PPPoE Interfaces.
Regards
Sven
-
Thank you Sven.
ok... i twas a little chance to get this run.
I like to help, but have no testing machine or 2nd connection.
So waiting... my new iptv box (v3) from telekom is waiting here...
@Franco: can we do something to support the development of the new version to igmpV3 as this is the new standard from German Telekom...
best
Frank
-
Hi Frank,
Basically I lack the connectivity to work on this directly. So far nobody seems interested, but there was an old contact who may be able to help. I'll try to ping him now...
Cheers,
Franco
-
Thank you. :)
-
Hi there,
not to throw water in the wine: Much likely you won't get Telekom Entertain v3 up and running with igmpproxy: Telekom Entertain v3 needs full upstream and downstream igmpv3 which igmpproxy is currently not supporting. It is doing igmpv3 on uplink and igmpv2 on downlink only.
Nevertheless, to get a little bit more insight what might happen is to start the igmpproxy with the -d -v options from terminal. It gives you some output right at the beginning what kind of VIF it is getting from kernel. Might be that this can be a hint where it hangs ...
Perhaps you can post the output then ..
Br br
-
just to summarize. it means, we have two issues:
- igmpproxy is not starting, when upstream devide is pppoe
- igmpproxy is not supporting igmpv3
correct?
does anyone knows, what alternative instead of igmpproxy, other router have implemented? (e.g speedports from telekom, or fritzbox's). That kind of boxes are working.
br
frank
-
Correct
igmpproxy uses upstream the kernel internal multicast router/igmp protocol implementation which supports igmpv3. Downstream it has an igmpv2 implementation. I am working since a while on an architectural redesign however am just stuck due some missing freebsd kernel documentation items.
All Fritzbox and Speedports support igmpv3 implicetly, connecting the receiver to them works fine
Nevertheless would love to see the debug output of the igmpproxy on your system to get some more insights where to improve the igmpproxy
Br br
-
Ok understand....
Thank you (!) for your effort and time you invest into the re-design.
attached the output of starting igmpproxy manually from shell (217.248.64.9 is assigned as current wan ip, 192.168.2.1 is assigned as lan-interface of the fw):
igmpproxy -d -v /usr/local/etc/igmpproxy.conf
adding VIF, Ix 0 Fl 0x0 IP 0x0102a8c0 re1, Threshold: 1, Ratelimit: 0
adding VIF, Ix 1 Fl 0x0 IP 0x010a000a ovpns1, Threshold: 1, Ratelimit: 0
adding VIF, Ix 2 Fl 0x0 IP 0x010b000a ovpns2, Threshold: 1, Ratelimit: 0
adding VIF, Ix 3 Fl 0x0 IP 0x0940f8d9 pppoe0, Threshold: 1, Ratelimit: 0
joinMcGroup: 224.0.0.2 on re1
joinMcGroup: 224.0.0.2 on ovpns1
joinMcGroup: 224.0.0.2 on ovpns2
RECV V2 member report from 192.168.2.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV Membership query from 192.168.2.1 to 224.0.0.1
RECV Membership query from 10.0.10.1 to 224.0.0.1
RECV Membership query from 10.0.11.1 to 224.0.0.1
RECV V2 member report from 192.168.2.49 to 239.255.255.250
Inserted route table entry for 239.255.255.250 on VIF #0
joinMcGroup: 239.255.255.250 on pppoe0
RECV unk: 0x22/0x00 from 217.248.64.9 to 224.0.0.22
ignoring unknown IGMP message type 22 from 217.248.64.9 to 224.0.0.22
The source address 192.168.2.45 for group 239.255.255.250, is not in any valid net for upstream VIF.
RECV V2 member report from 192.168.2.84 to 239.254.127.63
Inserted route table entry for 239.254.127.63 on VIF #0
-- following repeats until i stopped the manual start ----
RECV V2 member report from 192.168.2.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV unk: 0x22/0x00 from 217.248.64.9 to 224.0.0.22
ignoring unknown IGMP message type 22 from 217.248.64.9 to 224.0.0.22
---------------------------------------------------------------------------------------
regards
Frank
-
Ok - can you tell me which Network your
192.168.2.0
10.0.x.x
are?
Your 192.168.2.1 is the IP Address of What?
Anyway, your igmpproxy does not recognize the upstream vif properly ...
In my config (no pppoe upstream) it look like:
root@OPNsense:~ # /usr/local/sbin/igmpproxy -d -v /usr/local/etc/igmpproxy.conf
adding VIF, Ix 0 Fl 0x0 IP 0x0101a8c0 igb0, Threshold: 1, Ratelimit: 0
adding VIF, Ix 1 Fl 0x0 IP 0x6502a8c0 igb1, Threshold: 1, Ratelimit: 0
joinMcGroup: 224.0.0.2 on igb0
joinMcGroup: 224.0.0.22 on igb0
RECV V2 member report from 192.168.1.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.1.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
(...)
// Here it start to join the entertain group for ARD
RECV V2 member report from 192.168.1.83 to 239.35.10.4
Inserted route table entry for 239.35.10.4 on VIF #0
joinMcGroup: 239.35.10.4 on igb1
Adding MFC: 193.158.35.251 -> 239.35.10.4, InpVIf: 1
The IGMP message was local multicast. Ignoring.
// Upstream igmpv3 report:
RECV V3 member report from 192.168.2.101 to 224.0.0.22
(..)
// Client membership report for ARD
RECV V2 member report from 192.168.1.83 to 239.35.10.4
Updated route entry for 239.35.10.4 on VIF #0
Adding MFC: 193.158.35.251 -> 239.35.10.4, InpVIf: 1
The IGMP message was local multicast. Ignoring.
RECV V2 member report from 192.168.1.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
(..)
BR br
-
Not sure, how i can change the issue to identify VIF correctly.
Current config:
192.168.2.0 = internal network
10.0.x.x = OpenVPN Server
192.168.2.1 = IP Adress of LAN Interface opnsense
192.168.2.3 = MediaReceiver Telekom (old one igmpV2 not new EntertainTV)
192.168.2.25 = other client
Config of opnsense via GUI
Name Type Values Description
LAN downstream 192.168.2.3/32, 192.168.2.25/32 IPTV Downstream
WAN upstream 232.0.0.0/8, 239.0.0.0/8, 217.0.119.194/16, 193.158.35.0/24 IPTV Upstream
regards
Frank
-
I am surprise about all the challanges here. For me it is working fine. I also watch the new Telekom IPTV with IGMP V3. My IGMP proxy starts without issues. I have a Vigor 130, I front of my Opnsense box, acting as the Modem.
-
so let's find the differences then.
Can you post your igmpproxy.conf and describe your configuration more in detail please.
frank
-
... and also your network config would be fine
Otherwise look here (its in German)
https://forum.opnsense.org/index.php?topic=4785.0 (https://forum.opnsense.org/index.php?topic=4785.0)
You can see in your log: igmp type 0x22 is not known (this is a igmpv3 membership report)
Br br
-
Ok,
this is my igmpproxy.conf:
##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint pppoe1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4
altnet 239.32.0.0/16
altnet 87.141.0.0/15
phyint igb1 downstream ratelimit 0 threshold 1
altnet 192.168.3.0/24
phyint igb2 disabled
-
My Topology is:
Telekom Magenta L --> Draytek Vigor 130 acting as Modem --> APU 2C4 / Opnsense 18.1.10 --> LAN Switch TP-Link TL-SG108E with IGMP Snooping enebaled --> TVHeadend/Centos Linux on Intel NUC --> Kodi TVH Client on Rasperrry PI.
It is working like a charm.
-
Hi gliddie,
Your config is indeed a fair and valid option to stream TV via Entertain (tv) in your network, however Imho it is a different story:
I understood that frank wanted to use its new Entertain TV Box.
Getting access to Entertain via Kodi/tvheadend works via different mechanisms currently as I understand it:
If I remember correctly,
- tvheadend does not support igmpv3 either
- tvheadend does not yet support fully SSM
- Trying to access the new streams in the Entertain 87.XX range 'fall back' to the old Entertain addresses in the 193.X/232.X (ie Entertain v1) range
- Some had even reported that only using the ffmpeg pipe mechanisms of tvheadend brought Entertain V2 up. But this might have been fixed already with a newer version of tvheadend
(has been a while ago that I dealt with it)
Indeed you can watch tv via 'Entertain TV contract' then in your network but not yet fully using the foreseen technology mechanisms for Entertain TV technology platform. If you don't care - fine!
The official Entertain tv box requires mandatorily full igmpv3 support including source specific queries.
Br br
-
Yes, i like to run the same configuration as today. But with the new entertainbox from telekom, instead of the current old one from them.
having this said, i would love to see igmpproxy V3 ready. I think the issue is there anyhow, because the V3 platform is as replacement of the old microsoft based box and infrastructure, a least a year active.
Telekom is replacing the old v2 platform very aggressive. Every new contract, and also every contract change, leads to the V3 platform. V2 has no further sales approval, means it is stopped for sales since a year or so.
-
Interesting ;) TVHeadend ist working with IGMP V3 and SSM.
Long time I had been using the old IGMP V2 Multicast Streams.
If I try the IGMP V3 stream with VLC it is working, as well as with TVHeadend.
I have no single IGMP V2 Address configured in my TVHeadend.
Am not using the Telekom Boxes, as I only watch a little bit TV.
And with TVHeadend and Kodi, I am a lot more flexible :)
-
rtp://87.141.215.251@232.0.20.35:10000 is "Das Erste HD".
It is from the new Entertain TV. I am just watching it through VLC on my Smartphone.
This would not work, if IGMP V3 would not be working with the recent IGMP Proxy in Opnsense.
-
hmmm.... seeking for the root cause....
just to confirm my configuration.
EntertainZuhause L mit Entertain TV Plus
Vigor NIC 132 (same as 130 but PCI-E Card) running in bridge mode
OPNsense 18.1.10-amd64 - dialing in using pppoe
(OLD) igmpproxy 1.3_1
Telekom Media Receiver 303
I am currently running old Entertain. Have not switched on the new Media Receiver 401, because if i would switch it on, my telekom port will be automatically reconfigured for the new Entertain TV stream. I would not have a fall back to the current situation, that Telekom streams the old Entertain TV platform.
I have the effect, that the new igmpproxy version is NOT starting up. It seems that the pppoe interface is the issue.
So i have not further idea how to close the configuration gap between your an my configuration. I dont see a difference.... beside the fact, that your igmpproxy.conf has differences.
I also understood, the old and new igmpproxy version is not supporting igmpv3... but your is working... so i am confused here....
-
Thank you Gliddie :)
I changed the following:
- VLAN Tagging (7) moved from FW to modem
- Actual IGMPproxy version 2.1 installed (is shown as v1.3 in software overview of the FW)
PPPOE dialin is doing OPNSense and works perfect
IGMPproxy is not comming online starting with an normalem system start.
I need to stop OpenVPNServer first.
After stoping OpenVPNServer, i start IGMPproxy manualy via WebGUI.
I am running now in that configuration the actual IGMPproxy serving an MediaReceiver 303 - IGMPv2
Currently, i don't connect the new MediaReceivers streaming the new EntertainTV based on IGMPv3. Because, i assume IGMPProxy is not providing the full needed functionality (V3 down and up stream) that the new MediaReceiver requires.
Again, a big thank you.
-
No Problem,
Have ordered the Telekom MediaReceiver 401 yesterday.
Will give it a try ;)
I'll report the result after testing.
-
Cool :)
Thank you (!)
-
Just to say...
This post is not a post pro pfsense, but probably a hint into a direction to make igmpproxy run on opnsense.
It seems that pfsense 2.4.0 is working with igmpproxy and EntertainTV.
https://www.administrator.de/link/pfsense-2-4-0-telekom-entertaintv-2-0-funktionieren-344304.html
also a other software, instead of igmpproxy, call MC-Proxy is mentioned.
regards
frank
-
Yes, this is a linux based igmp proxy solution which also support SSM and even IPv6 MLD. Some folks out of pfsense have started to port it to freebsd and made compilable however I could not find it publicly available as a working release as in the article below is said that it did not work as the kernel interface linux/freebsd is too different; see also
https://forum.netgate.com/topic/98494/pfsense-2-3-mit-telekom-entertain/20 (https://forum.netgate.com/topic/98494/pfsense-2-3-mit-telekom-entertain/20)
Btw. the not yet complete freebsd port you can find on GitHub:
https://github.com/ViToni/mcproxy (https://github.com/ViToni/mcproxy)
Br br
-
Hi gliddie,
kannst Du schon was zu den Erfahrungen mit dem neuen Receiver sagen?
gruss
Frank
-
Hi, I wish I could.
Haven't received the kit yet.
Just checked the order status on Telekoms Webpage and it looks like delivery is due in July 14.
Can't wait to get it :)
I'll let you know as soon as I have received the box.
Have a nice day,
Gliddie
-
Hi.
I would also get the word in this thread.
My ISP also offers IPTV but there is no documentation.
The only thing I have is a VLC playlist.
A few month ago a FritzBox was fully functional.
But I used it only a few times.
Now with OPNsense I would reactivate this.
My setup is DHCP on WAN side.
A VLAN 142 for VoIP and a VLAN 141 for IPTV.
The information for the IPTV VLAN comes from the default FritzBox settings which my ISP offers for download.
Now I used a manual for DTAG but I could not get it work.
Systemmessages are:
igmpproxy[130]: select() failure; Errno(4): Interrupted system call
igmpproxy[43443]: There must be at least 1 Vif as upstream.
If I select the WAN interface instead of the IPTV VLAN as upstreaming interface the igmpproxy will start.
But also no TV channel comes up.
-
Hi,
I have just received the Mediareceiveder 401 from Telekom and connected it.
Will begin testing now.
Lets see ....
Greetings,
Gliddie
-
Ok, I will need a moment to get the box booting up.
1.) At the first start it is looking for an tftp server, to grab its firmware ==> We will need a tftp proxy on opnsense. Else a fresh unboxed MR401 will not start. Also future firmwareupgrades would not work .
2.) Then the box is trying to reach 4 different NTP Servers. And then it stops starting up with an error message stating it cannot contact the NTP servers.
Next step, if my wife gives me time to play: I'll connect the box to the Telekom Router and capture some sniffer traces from the boot process. I just like to see which traffic is running back and forth to build the required firewall rules.
Let's see, I'll be back later today or tomorrow.
Cheers,
Gliddie
-
Last update for today:
My Media Receiver 401 is working with the latest version from Opnsense and the igmp proxy from that version.
==> IGMP V3 SSM must be working with that version from IGMP proxy.
Am just wathc ZDF HD, since 10 Minute and the picture is clear and stable.
Zapping works well.
Will now test it over a longer time period and see, if it stays stable.
By the way, I still receive the old IGMP V2 and V3 streams. So far Telekom did not change anything on my circuit, since I had plugged in the Media Receiver 401.
Will be back in a few days after testing it a longer time.
Have a nice weekend,
Gliddie
-
Ok,
besides the usual Firewall rules for IGMP, nothing special is required for the Media Receiver 401.
Mine was not starting, as I had an NTP server handed out by my DHCP server.
The MR401 doesnt seam to like NTP servers, other then the Telekom ones.
After disable option 42 and 4 on my dhcp, the MR401 is booting fine now.
Conclusion:
The Media Receiver 401, which requires IMGP V3 SSM, does work with the actual Opnsense version and the igmp proxy which does come with the last version.
Things to consider:
- this igmp proxy version does not recognize virtual upstream interfaces.
==> If you have to tag your upstream interface with a VLAN, do that on the modem, infront of your opnsense box. - Somehow there might be a conflict with the OpenVPN Server. igmp proxy does not start, if you run an Open VPN Site to Site tunnel. I dont have that issue with my IPsec Tunnel.
- The MR401 grabs his firmware files from an TFTP server at Telekom. ==> You will need to run a tftp proxy on Opnsense, if you like to be able to upgrade firmware. If you start your MR401 the first time, it will not boot up, if it cannot reach the TFTP server.
Ok. enough for today, Will give the box my wife for testing it a few days :-)
Have a nice weekend,
Gliddie
-
Hi Giddie,
wow.... this is fabuoulus.
I will give it a try....weekend next week..
thank you very much to figure it out.
how do you have set up the TFTP proxy on opnsense?
thanks again.
I will let you know next week, the outcome of my results.
Frank
-
Hello Frank,
II did plugin the MR401 to a Telekom router and did let it grab the firmware that way.
After that I plugged it back to my Opnsense box.
FreeBSD comes with a tftp proxy, which we would need to enable. So opnsense could proxy the tftp queries to Telekoms server. There is no plugin for that in opnsense.
I haven't figured out yet how to get that tftp proxy up and running. Am working on it.
For the moment you would need to use a Fritz Box or Telekom router for the very first start.
After that you can remove these and begin using Opnsense with the MR401.
I'll be back soon...
Gliddie
-
Hey,
I am now using the MR401 since 2 weeks.
Only firmware upgrades are not possible, since I am struggling with the tftp proxy.
Everything else has been working great.
No issues with watching TV.
Did you try it Frank?
-
Hej great news ! :)
i am waiting to one of my friends to connect the MR401 with his speedport. (I have no, since i am using a draytec 132 as endpoint for my VDSL line.
I think i can come back mid of August with results. As far as i have it, i will post it here.
Thanks Giddie,
Best regards
Frank
-
FYI, upstream progress: https://github.com/pali/igmpproxy/pull/38
-
That's good news. Thank you for the info.
-
Seems upstream are concentrating on the problems being due to PPPOE
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
I have added the above info to the upstream link
-
Would someone with the issue please try this version?
# pkg add -f https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/igmpproxy-0.2.1_1,1.txz
Cheers,
Franco
-
I found an different solution, outside the opnsense box. Means... i am out... sorry.
-
Initially I wanted to push this update with 18.7.3 today but forgot to update the ports for building so this above version will be in 18.7.4. Further feedback until 18.7.4 is released is appreciated.
Cheers,
Franco
-
Hello Franco,
igmpproxy-0.2.1_1,1 seems to solve the problem described here:
https://forum.opnsense.org/index.php?topic=9631.msg43820#msg43820
VLAN interfaces are now added by the IGMP proxy.
But behind my VLAN switch IPTV still doesn't work. I don't know if the problem is with my complex switch (which overwhelms me) or with the IGMP proxy. I will occasionally try a simpler switch.
root@OPNsense:~ # /usr/local/sbin/igmpproxy -d -vvvv /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 igb0.
Config: IF: Got upstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
Config: IF: Got altnet token 77.109.129.0/19.
Config: IF: Altnet: Parsed altnet to 77.109.129/19.
IF name : igb0
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 1
Allowednet ptr : 2082b000
Config: Got a phyint token.
Config: IF: Config for interface igb1_vlan101.
Config: IF: Got downstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
Config: IF: Got altnet token 192.168.101.0/24.
Config: IF: Altnet: Parsed altnet to 192.168.101/24.
IF name : igb1_vlan101
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 2
Allowednet ptr : 2082b020
Config: Got a phyint token.
Config: IF: Config for interface igb1_vlan99.
Config: IF: Got disabled token.
IF name : igb1_vlan99
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface igb1_vlan103.
Config: IF: Got disabled token.
IF name : igb1_vlan103
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
Config: Got a phyint token.
Config: IF: Config for interface igb1_vlan10.
Config: IF: Got disabled token.
IF name : igb1_vlan10
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
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
Config: Got a phyint token.
Config: IF: Config for interface igb1.
Config: IF: Got disabled token.
IF name : igb1
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 0
Allowednet ptr : 0
buildIfVc: Interface igb0 Addr: xxx.xxx.xxx.xxx, Flags: 0xffff8843, Network: 85.195.255/24
buildIfVc: Interface igb1 Addr: 192.168.111.1, Flags: 0xffff8843, Network: 192.168.111/24
buildIfVc: Interface igb2 Addr: 192.168.102.1, Flags: 0xffff8843, Network: 192.168.102/24
buildIfVc: Interface lo0 Addr: 127.0.0.1, Flags: 0xffff8049, Network: 127/8
buildIfVc: Interface ovpns1 Addr: 10.0.8.1, Flags: 0xffff8051, Network: 10.0.8.1/32
buildIfVc: Interface ovpns2 Addr: 10.0.9.1, Flags: 0xffff8051, Network: 10.0.9.1/32
buildIfVc: Interface igb1_vlan99 Addr: 192.168.99.1, Flags: 0xffff8843, Network: 192.168.99/24
buildIfVc: Interface igb1_vlan101 Addr: 192.168.101.1, Flags: 0xffff8843, Network: 192.168.101/24
buildIfVc: Interface igb1_vlan103 Addr: 192.168.100.1, Flags: 0xffff8843, Network: 192.168.100/24
buildIfVc: Interface igb1_vlan10 Addr: 10.0.0.1, Flags: 0xffff8843, Network: 10.0.0/24
Found config for igb0
Found config for igb1
Found config for igb2
Found config for igb1_vlan99
Found config for igb1_vlan101
Found config for igb1_vlan103
Found config for igb1_vlan10
Found upstrem IF #0, will assing as upstream Vif 2
adding VIF, Ix 0 Fl 0x0 IP 0xeaffc355 igb0, Threshold: 1, Ratelimit: 0
Network for [igb0] : 85.195.255/24
Network for [igb0] : 77.109.129/19
adding VIF, Ix 1 Fl 0x0 IP 0x0165a8c0 igb1_vlan101, Threshold: 1, Ratelimit: 0
Network for [igb1_vlan101] : 192.168.101/24
Network for [igb1_vlan101] : 192.168.101/24
Got 262144 byte buffer size in 0 iterations
Joining all-routers group 224.0.0.2 on vif 192.168.101.1
joinMcGroup: 224.0.0.2 on igb1_vlan101
Joining all igmpv3 multicast routers group 224.0.0.22 on vif 192.168.101.1
joinMcGroup: 224.0.0.22 on igb1_vlan101
SENT Membership query from 192.168.101.1 to 224.0.0.1
Sent membership query from 192.168.101.1 to 224.0.0.1. Delay: 10
Created timeout 1 (#0) - delay 10 secs
(Id:1, Time:10)
Created timeout 2 (#1) - delay 21 secs
(Id:1, Time:10)
(Id:2, Time:21)
RECV V2 member report from 192.168.101.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.101.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV Membership query from 192.168.101.1 to 224.0.0.1
RECV V2 member report from 192.168.101.200 to 224.0.2.3
Should insert group 224.0.2.3 (from: 192.168.101.200) to route table. Vif Ix : 1
No existing route for 224.0.2.3. Create new.
No routes in table. Insert at beginning.
Inserted route table entry for 224.0.2.3 on VIF #1
Joining group 224.0.2.3 upstream on IF address xxx.xxx.xxx.xxx
joinMcGroup: 224.0.2.3 on igb0
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from xxx.xxx.xxx.xxx to 224.0.2.3
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.101.30 to 224.0.0.251
Should insert group 224.0.0.251 (from: 192.168.101.30) to route table. Vif Ix : 1
No existing route for 224.0.0.251. Create new.
Found existing routes. Find insert location.
Inserting after route 224.0.2.3
Inserted route table entry for 224.0.0.251 on VIF #1
Joining group 224.0.0.251 upstream on IF address xxx.xxx.xxx.xxx
joinMcGroup: 224.0.0.251 on igb0
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from xxx.xxx.xxx.xxx to 224.0.0.251
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.101.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
About to call timeout 1 (#0)
Aging routes in table.
Current routing table (Age active routes):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:1, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:1, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from 192.168.101.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
About to call timeout 2 (#0)
SENT Membership query from 192.168.101.1 to 224.0.0.1
Sent membership query from 192.168.101.1 to 224.0.0.1. Delay: 10
Created timeout 3 (#0) - delay 10 secs
(Id:3, Time:10)
Created timeout 4 (#1) - delay 21 secs
(Id:3, Time:10)
(Id:4, Time:21)
RECV Membership query from 192.168.101.1 to 224.0.0.1
RECV V2 member report from 192.168.101.99 to 224.0.0.251
Should insert group 224.0.0.251 (from: 192.168.101.99) to route table. Vif Ix : 1
Updated route entry for 224.0.0.251 on VIF #1
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:1, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:1, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from 192.168.101.200 to 224.0.2.3
Should insert group 224.0.2.3 (from: 192.168.101.200) to route table. Vif Ix : 1
Updated route entry for 224.0.2.3 on VIF #1
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:1, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:1, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from 192.168.101.20 to 224.0.0.252
Should insert group 224.0.0.252 (from: 192.168.101.20) to route table. Vif Ix : 1
No existing route for 224.0.0.252. Create new.
Found existing routes. Find insert location.
Inserting after route 224.0.0.251
Inserted route table entry for 224.0.0.252 on VIF #1
Joining group 224.0.0.252 upstream on IF address xxx.xxx.xxx.xxx
joinMcGroup: 224.0.0.252 on igb0
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:1, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:1, St: I, OutVifs: 0x00000002
#2: Dst: 224.0.0.252, Age:2, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from xxx.xxx.xxx.xxx to 224.0.0.252
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
About to call timeout 3 (#0)
Aging routes in table.
Current routing table (Age active routes):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000002
#2: Dst: 224.0.0.252, Age:1, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from 192.168.101.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV Membership query from 85.195.255.1 to 224.0.0.1
RECV V2 member report from xxx.xxx.xxx.xxx to 224.0.0.251
The IGMP message was from myself. Ignoring.
RECV V2 member report from xxx.xxx.xxx.xxx to 224.0.2.3
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.101.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report from xxx.xxx.xxx.xxx to 224.0.0.252
The IGMP message was from myself. Ignoring.
About to call timeout 4 (#0)
SENT Membership query from 192.168.101.1 to 224.0.0.1
Sent membership query from 192.168.101.1 to 224.0.0.1. Delay: 10
Created timeout 5 (#0) - delay 10 secs
(Id:5, Time:10)
Created timeout 6 (#1) - delay 115 secs
(Id:5, Time:10)
(Id:6, Time:115)
RECV Membership query from 192.168.101.1 to 224.0.0.1
RECV V2 member report from 192.168.101.20 to 224.0.0.252
Should insert group 224.0.0.252 (from: 192.168.101.20) to route table. Vif Ix : 1
Updated route entry for 224.0.0.252 on VIF #1
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000002
#2: Dst: 224.0.0.252, Age:1, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from 192.168.101.10 to 224.0.0.251
Should insert group 224.0.0.251 (from: 192.168.101.10) to route table. Vif Ix : 1
Updated route entry for 224.0.0.251 on VIF #1
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000002
#2: Dst: 224.0.0.252, Age:1, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from 192.168.101.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.101.200 to 224.0.2.3
Should insert group 224.0.2.3 (from: 192.168.101.200) to route table. Vif Ix : 1
Updated route entry for 224.0.2.3 on VIF #1
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000002
#2: Dst: 224.0.0.252, Age:1, St: I, OutVifs: 0x00000002
-----------------------------------------------------
About to call timeout 5 (#0)
Aging routes in table.
Current routing table (Age active routes):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000002
#2: Dst: 224.0.0.252, Age:2, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from 192.168.101.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
About to call timeout 6 (#0)
SENT Membership query from 192.168.101.1 to 224.0.0.1
Sent membership query from 192.168.101.1 to 224.0.0.1. Delay: 10
Created timeout 7 (#0) - delay 10 secs
(Id:7, Time:10)
Created timeout 8 (#1) - delay 115 secs
(Id:7, Time:10)
(Id:8, Time:115)
RECV Membership query from 192.168.101.1 to 224.0.0.1
The IGMP message was local multicast. Ignoring.
RECV V2 member report from 192.168.101.99 to 224.0.0.251
Should insert group 224.0.0.251 (from: 192.168.101.99) to route table. Vif Ix : 1
Updated route entry for 224.0.0.251 on VIF #1
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000002
#2: Dst: 224.0.0.252, Age:2, St: I, OutVifs: 0x00000002
-----------------------------------------------------
RECV V2 member report from 192.168.101.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.101.10 to 224.0.0.252
Should insert group 224.0.0.252 (from: 192.168.101.10) to route table. Vif Ix : 1
Updated route entry for 224.0.0.252 on VIF #1
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 224.0.2.3, Age:2, St: I, OutVifs: 0x00000002
#1: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000002
#2: Dst: 224.0.0.252, Age:2, St: I, OutVifs: 0x00000002
-----------------------------------------------------
^Cselect() failure; Errno(4): Interrupted system call
Got a interrupt signal. Exiting.
clean handler called
Removing route entry for 224.0.2.3
Leaving group 224.0.2.3 upstream on IF address xxx.xxx.xxx.xxx
leaveMcGroup: 224.0.2.3 on igb0
Removing route entry for 224.0.0.251
Leaving group 224.0.0.251 upstream on IF address xxx.xxx.xxx.xxx
leaveMcGroup: 224.0.0.251 on igb0
Removing route entry for 224.0.0.252
Leaving group 224.0.0.252 upstream on IF address xxx.xxx.xxx.xxx
leaveMcGroup: 224.0.0.252 on igb0
All routes removed. Routing table is empty.
Shutdown complete....
root@OPNsense:~ #
-
Hey,
I am now using the MR401 since 2 weeks.
Only firmware upgrades are not possible, since I am struggling with the tftp proxy.
Everything else has been working great.
No issues with watching TV.
Did you try it Frank?
Hi @gilddie, Hi to everyone,
I'm currently not able to get the MagentaTV IPTV working on my BNG based FTTH connection. I run my OPNSense directly connected to the FTTH Modem with an VLAN 7 Tagged Interface which is used by my PPPoE based WAN interface. I have tried several FW-Rulesets and also configured the IGMP-Proxy but the IPTV stream starts to stuck after round about 30 seconds streaming.
Could someone post his detailed FW-Rulesset and IGMP-Proxy settings that he/she used to get IPTV working on a Telekom based link using a OPNSense FW?
Thanks for any help in advance - I can post a more detailed config of my current setup if needed,
Cheers,
FillFeile
-
Hey,
To me it sounds like your network. Might be flooded by the Multicast packets.
Are you having a managed switch between your receiver and the firewall?
I highly recommend to use a managed switch which does support "IGMP Snooping"
Regards,
Gliddie
Gesendet von meinem S61 mit Tapatalk