Messages

... and also your network config would be fine

Otherwise look here (its in German)

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 - 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:

Code Select Expand


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

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

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

Thanks Franco,

Hmmmmm - this is one option how to do it ....

However, concept of dpinger creates individual instances per gateway. It would make sense, to allow selective gateway monitoring. Latest when replacing apinger, an individual activation in the gateway screen would more intuitive.

Just my 10 cents

Br br

Thanks a lot, it works!

I have to admit that I never would have looked under firewall.

There is  a dedicated gateway menu under 'system' which also allows to switch Gateway monitoring on/off. What is the concept idea behind to put this tick box under firewall configuration?

Br br

Hi there,

with pleasure i noticed that now a package for dpinger is provided with 18.1.10. Do I assume right that for now no GUI support for   dpinger is provided?

If so is there a safe recommendation how to replace apinger with dpinger via console?

Looking forward to your reply

Br br

Yes, it was - tried the proposal without reboot first, also restart of configd did not change the situation - I simply rebooted and now all is fine ...

Br br

Hmmm,

this only shows 'führe aus, bitte warten', and nothing happens ....

Br br

Thanks Franco,

Will reboot when back home. As I found all files and also the Router Class thought something like that. Interesting enough, 18.1.9 runs normal and also the Router Configis there ...

Dashboard says that 18.1.9. is installed, but I can't likely get away the error message without reboot ?!

BR br

Hi there

Get an error when installing 18.1.9. Installation screen hangs with extracting opnsense-18.1.9 and the following error message appears:

Code Select Expand


[31-May-2018 20:58:01 Europe/Berlin] PHP Fatal error:  Uncaught Error: Class 'OPNsense\Core\Routing' not found in /usr/local/opnsense/mvc/app/config/services_api.php:87
Stack trace:
#0 [internal function]: Closure->{closure}()
#1 [internal function]: Phalcon\Di\Service->resolve(NULL, Object(Phalcon\Di\FactoryDefault))
#2 [internal function]: Phalcon\Di->get('router', NULL)
#3 [internal function]: Phalcon\Di->getShared('router')
#4 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle()
#5 {main}
  thrown in /usr/local/opnsense/mvc/app/config/services_api.php on line 87

Any idea how to fix that?

Br br

Hi

at least in my case https://forum.opnsense.org/index.php?topic=4918.0 it turned out at the end to be a hardware issue with the board which could only be fixed by RMA the board to Supermicro (see https://forum.opnsense.org/index.php?topic=5869.msg25622#msg25622)

See also here for a little bit more in depth description https://forum.opnsense.org/index.php?topic=5063.0

Since then, it is rock solid stable. I also experimented a lot around with the sysconf settings in /boot/loader.conf.local before with no sustainable success

Br br

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

 Hi Jeen

Hmm - wenn der pop Host per ping erreichbar ist und fetchmail 'connected' sagt würde ich mal auf ein TLS/SSL Thema tippen .... Was sagt denn fetchmail -vvv (Erhöhung des loglevel)?

Br br

Hi all,

the same procedure as every year - but this time with progress:  igmpproxy in 17.7 now working with Telekom Entertain and Opnsense behind a Fritzbox as Router. Several topics dealt with that over the last 18 months eg https://forum.opnsense.org/index.php?topic=1968.0,https://forum.opnsense.org/index.php?topic=5295.0.

Over the last year there has been some updates of igmpproxy coming from pfsense space and fed back to freebsd ports, eg https://redmine.pfsense.org/issues/6099. Also, the problems with the correct aging of mcast routes in the table seems to be fixed now. Although not knowing whether all of them are fully reflected in the igmpproxy plugin of the current Opnsense release 17.7.11, I could make it work at least for Telekom Entertain 1.0 (NOT yet proven for the new Telekom Entertain TV 2.0) at least for the following configuration:

                                                                                 ----
                                                                            +-+ S +------> DMZ   <-----> Client
                                                                            |   | W |
Telekom ISP <--> Fritzbox 3490 <--> Opnsense <--+-+ I  +------> LAN    <-----> Client
                                                                            |   | T  |
                                                                            +-+ C +------> WLAN <-----> Client
                                                                                | H  |
                                                                                 ----
The switch supports IGMPv3 snooping and provides separated networks for DMZ, LAN, WLAN via untagged VLANs

After installation of the igmpproxy plugin, the following upstream networks should be configured:

• 193.158.0.0/15
• 87.140.0.0/15
• 224.0.0.0/4

The downstream networks should contain the networks of the LAN side interfaces accordingly.

The resulting /usr/local/etc/igmpproxy.conf should look like eg

Code Select Expand


##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint igb1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4
altnet 87.140.0.0/15

phyint igb0 downstream ratelimit 0 threshold 1
altnet 192.168.X.0/24

phyint igb2 disabled
phyint igb3 disabled


Indeed you can also configure more downstream interfaces (in my case disabled here) important is to have ONE single upstream interface with the shown networks .... At the moment, I don't have yet a BNG network connection (migration announced for Q1), might be that then the upstream networks needs to be adapted.

Then, some firewall rules need to be configured:
On WAN interface:

• IPv4 IGMP from all sources, all ports to dest 224.0.0.0/4, all ports, activate extension
• IPv4 UDP from all sources, all ports to dest 224.0.0.0/4, all ports, activate extension

On LAN

• activate also extensions on all general rules

Then, very important, under Interfaces->WAN, the box 'block private networks' may NOT be ticked. Otherwise, Opnsense igmpproxy does not see the IGMP Queries from the Fritzbox anymore which prevents in time answers with member reports from the Opnsense and the Fritzbox stops the UDP stream after 2-3 mins.

In my config, TV can be seen stable on all devices in my LAN and WLAN with the vlc player. Thanks to IGMPV3 snooping capable switch, the additional traffic load on the LAN is neglectible ....

I will go for testing of direct connected Opnsense to Draytec Modem (leave out fritzbox) in the next step; as well I am currently working on a full igmpv3 implementation on the downstream side (this seems to be a prerequisite to make Entertain TV 2.0 work)...

Br br