OPNsense Forum
Archive => 15.7 Legacy Series => Topic started by: bringha on January 05, 2016, 07:08:34 pm
-
Hello,
I am trying since a while to make my IPTV (Entertain from Deutsche Telekom) working with the VLC player with some Apple clients. While several articles show how to achieve this by directly connecting over a VDSL Modem and XXsense (eg https://blog.tausys.de/2014/10/16/telekom-iptv-mit-pfsense/ (https://blog.tausys.de/2014/10/16/telekom-iptv-mit-pfsense/)), I have to rely my Internet connection on a Fritzbox for several reasons. Many others have given up here, however I feel still some hope to be pretty close to a solution ... :o
I notice now that the igmpproxy of opnsense seem to show a behavior which prevents a stable igmp stream for more than 2 minutes. After that, the stream freezes; about 5-8 min later, another 2 min of TV can be seen on the client until the same happens again.
On the LAN side, I see the expected multicast behavior:
192.168.x.254 opnsense -> 224.0.0.1: Opnsense sends general IGMP Membership Query
192.168.x.22 client -> 239.35.10.4: Client sends membership report for group 239.35.10.4 (i.e. German 1st TV program)
As opnsense' igmpproxy is only supporting IGMP V2 on the LAN side, this look OK to me, and this sequence is repeated every 120 sec. This means, that the client is reporting every 2 min, that it still wants to belong to this igmp IPTV group. So far so good ....
The - according to my understanding - strange behavior happens on the WAN side of opnsense: As said, in my configuration, it is connected with a fritz box. I also read about the igmpproxy that on the WAN side, igmpproxy speaks IGMPv3 as also the fritzbox does. I also read that igmpproxy shall behave LIKE A CLIENT. What I see is:
192.168.y.1 fritzbox -> 224.0.0.1: Fritzbox sends general igmp membership query
192.168.y.100 opnsense -> 224.0.0.22: IGMPv3: opnsense sends a Membership Report/Leave group 239.35.10.4 (why????)
and immediately after
192.168.y.100 opnsense -> 224.0.0.22: IGMPv3: opnsense sends a Membership Report/join group 239.35.10.4 (why????)
After that, it does only sporadically or even not at all answers on the general igmp queries from the fritzbox for the IPTV stream; naturally, after 2 min, the fritzbox disconnects the igmp Data stream (UDP) with the TV data and sends from its side a leave group.
At least to me this sounds like a reasonable explanation pattern for the seen behavior. Not understood is indeed, why the stream starts after 5-8 min again and why then suddenly the igmpproxy again sends a join request...What might trigger it?
I would have expected, that for EACH membership report for the IP TV channel on the LAN side, also a membership report is generated on the WAN side. Does anybody here has seen the described behavior? Is this something what could be corrected with a config modification?
My igmpproxy.conf look as follow
##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint xn1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4
phyint xn0 downstream ratelimit 0 threshold 1
altnet 192.168.x.0/32
phyint xn2 disabled
phyint xn3 disabled
Looking forward to your reply
Br br
-
Hi there,
I'm absolutely no authority on the igmp proxy, but FWIW, I've checked the system and the service and configs at least do what they are supposed to.
Upon further research, there seems to be a multicast flooding issue happening, can you record traffic to see if you can confirm this?
Something I've found was this: https://www.reddit.com/r/PFSENSE/comments/3npl9p/iptv_igmp_proxy_issues/
Cheers,
Franco
-
Franco,
thanks for your answer - meanwhile I am a bit more progressed in the analysis.
No, there is no multicast flooding visible on the LAN. The problem lies obviously somewhere else:
When running the igmproxy in DEBUG mode, the mcast group for IPTV program at 239.35.10.4 (German ARD TV) is joined accurately
Current routing table (Insert Route):
-----------------------------------------------------
#0: Src: 0.0.0.0, Dst: 239.255.255.246, Age:1, St: I, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000001
#2: Src: 0.0.0.0, Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001
-----------------------------------------------------
RECV V2 member report from 192.168.1.254 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.1.191 to 239.35.10.4
Should insert group 239.35.10.4 (from: 192.168.1.191) to route table. Vif Ix : 0
No existing route for 239.35.10.4. Create new.
Found existing routes. Find insert location.
Inserting at beginning, before route 239.255.255.246
Inserted route table entry for 239.35.10.4 on VIF #0
Joining group 239.35.10.4 upstream on IF address 192.168.2.100
joinMcGroup: 239.35.10.4 on xn1
A few ms later, the stream source sends the route activation request and starts the stream:
Current routing table (Insert Route):
-----------------------------------------------------
#0: Src: 0.0.0.0, Dst: 239.35.10.4, Age:2, St: I, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.246, Age:1, St: I, OutVifs: 0x00000001
#2: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000001
#3: Src: 0.0.0.0, Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001
-----------------------------------------------------
Route activate request from 193.158.35.251 to 239.35.10.4
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Adding MFC: 193.158.35.251 -> 239.35.10.4, InpVIf: 1
130 sec later, the igmpproxy sends a membership query on the LAN side as it should:
Current routing table (Insert Route):
-----------------------------------------------------
#0: Src: 193.158.35.251, Dst: 239.35.10.4, Age:1, St: A, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.246, Age:2, St: I, OutVifs: 0x00000001
#2: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000001
#3: Src: 0.0.0.0, Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001
-----------------------------------------------------
RECV V2 member report from 192.168.1.191 to 239.35.10.4
Should insert group 239.35.10.4 (from: 192.168.1.191) to route table. Vif Ix : 0
Updated route entry for 239.35.10.4 on VIF #0
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Adding MFC: 193.158.35.251 -> 239.35.10.4, InpVIf: 1
And here according to my understanding the misbehavior start (correct me if I'm wrong) :
Neither the aging counter is increased again to 2 NOR the positive report leads to a membership report on the WAN side to the next router (in this case the fritzbox, which by the way sends every 30-60 sec. an membership query from its end which is never answered for 239.35.10.4)
Current routing table (Insert Route):
-----------------------------------------------------
#0: Src: 193.158.35.251, Dst: 239.35.10.4, Age:2, St: A, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.246, Age:2, St: I, OutVifs: 0x00000001
#2: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000001
#3: Src: 0.0.0.0, Dst: 224.0.0.251, Age:1, St: I, OutVifs: 0x00000001
-----------------------------------------------------
About to call timeout 18 (#0)
About to call timeout 9 (#0)
SENT Membership query from 192.168.1.254 to 224.0.0.1
Sent membership query from 192.168.1.254 to 224.0.0.1. Delay: 10
Created timeout 19 (#0) - delay 10 secs
(Id:19, Time:10)
Created timeout 20 (#1) - delay 115 secs
(Id:19, Time:10)
(Id:20, Time:115)
RECV Membership query from 192.168.1.254 to 224.0.0.1
RECV V2 member report from 192.168.1.191 to 239.35.10.4
Should insert group 239.35.10.4 (from: 192.168.1.191) to route table. Vif Ix : 0
Updated route entry for 239.35.10.4 on VIF #0
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Adding MFC: 193.158.35.251 -> 239.35.10.4, InpVIf: 1
Consequently, the stream is stopped by the sender/the fritzbox then, as no prolongation of the stream is requested. I assume a correlation that the IPTV route is the only one where the originAddr field is >0 (see rttable.c, line 652). All other route entry lead to a reaction of opnsense when a query is sent on the WAN interface)
Interesting enough, this cycle ist restarted automatically every 15-30 min. You see then on the WAN side suddenly a new join request, no clue what triggers it (might be a timer or so).
As igmpproxy-0.1 is code from 2009 (although a bunch of patches are documented in git) and I read somewhere that igmpproxy is not cascading, it would be great to modernize it to
- full IGMPv3 implementation on the LAN side
- Enable cascading with standard configurations
Perhaps a worth feature request ;). Alternatively it might be an option to consider mrouted as additional service in opnsense
Sorry for the long message, but the issue is somewhat more tricky ....
Br br