IGMP-Proxy and IPTV - two Issues
-
Hi,
I have these two issues with the IGMP-Proxy and IPTV (Telekom - Germany. First ~ 10 sec comes via UDP Stream, after ~ 10 seconds the stream switch to multicast (IGMP V3)):
-
I watch to channel 1 for some time, then I switch to channel 2. The after a some seconds (< 10 sec), i want to switch back to Channel 1. After approx. 10 sec. the picture freezes and sound stops this condition stays for ~1-3 min. To get a normal condition faster, I have to switch to another channel, wait for at least 10 sec and then I can switch to channel 1 again and now i can watch channel 1 again.
-
The switch from UDP Stream to multicast is mostly rough. For 1 - 3 sec you´ll get many picture and sound errors.
Thx
-
-
I havn't got the IPTV running but in order to help you, we need ALOT more info on that…
How have you configured the proxy? Logfiles? -
IGMP-Proxy - configuration:
quickleave phyint vr2_vlan8 upstream ratelimit 0 threshold 1 altnet 239.35.0.0/16 altnet 193.158.35.0/24 altnet 93.213.255.254/32 phyint vr1 downstream ratelimit 0 threshold 1 altnet 172.21.50.150/32 phyint pppoe0 disabled phyint vr0 disabled phyint ath0_wlan1 disabled ~
Here some logs (picture and sound freezes at ~00:38):
Jan 4 00:38:17 igmpproxy: Note: RECV Membership query from 172.21.50.254 to 224.0.0.1 (ip_hl 24, data 12) Jan 4 00:38:17 igmpproxy: Note: RECV Membership query from 172.21.50.254 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:38:17 igmpproxy: Note: Removing MFC: 193.158.35.65 -> 239.35.132.11, InpVIf: 2 Jan 4 00:38:11 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jan 4 00:38:11 igmpproxy: Note: RECV V2 member report from 93.213.247.186 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:38:11 igmpproxy: Warn: unknown Mode in V3 report (673189920) Jan 4 00:38:11 igmpproxy: Note: RECV V3 member report from 93.213.247.186 to 224.0.0.22 (ip_hl 24, data 16) Jan 4 00:38:11 igmpproxy: Note: Adding MFC: 193.158.35.65 -> 239.35.132.11, InpVIf: 2 Jan 4 00:38:11 igmpproxy: Note: RECV V2 member report from 172.21.50.150 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:38:10 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jan 4 00:38:10 igmpproxy: Note: RECV V2 member report from 93.213.247.186 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:38:10 igmpproxy: Warn: unknown Mode in V3 report (673189920) Jan 4 00:38:10 igmpproxy: Note: RECV V3 member report from 93.213.247.186 to 224.0.0.22 (ip_hl 24, data 16) Jan 4 00:38:10 igmpproxy: Note: Adding MFC: 193.158.35.65 -> 239.35.132.11, InpVIf: 2 Jan 4 00:38:10 igmpproxy: Note: RECV V2 member report from 172.21.50.150 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:38:09 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jan 4 00:38:09 igmpproxy: Note: RECV V2 member report from 93.213.247.186 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:38:09 igmpproxy: Warn: unknown Mode in V3 report (673189920) Jan 4 00:38:09 igmpproxy: Note: RECV V3 member report from 93.213.247.186 to 224.0.0.22 (ip_hl 24, data 16) Jan 4 00:38:09 igmpproxy: Note: Adding MFC: 193.158.35.65 -> 239.35.132.11, InpVIf: 2 Jan 4 00:38:09 igmpproxy: Note: RECV V2 member report from 172.21.50.150 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:38:07 igmpproxy: Note: RECV Membership query from 172.21.50.254 to 224.0.0.1 (ip_hl 24, data 12) Jan 4 00:38:07 igmpproxy: Note: RECV Membership query from 172.21.50.254 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:38:01 igmpproxy: Note: RECV V3 member report from 93.213.247.186 to 224.0.0.22 (ip_hl 24, data 16) Jan 4 00:37:59 igmpproxy: Note: RECV V3 member report from 93.213.247.186 to 224.0.0.22 (ip_hl 24, data 16) Jan 4 00:37:59 igmpproxy: Note: RECV Membership query from 172.21.50.254 to 224.0.0.1 (ip_hl 24, data 12) Jan 4 00:37:59 igmpproxy: Note: RECV Membership query from 172.21.50.254 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:37:59 igmpproxy: Note: leaveMcGroup: 239.35.132.11 on vr2_vlan8 Jan 4 00:37:59 igmpproxy: Note: RECV Leave message from 172.21.50.150 to 224.0.0.2 (ip_hl 24, data 8) Jan 4 00:37:57 igmpproxy: Note: Removing MFC: 193.158.35.181 -> 239.35.100.2, InpVIf: 2 Jan 4 00:37:56 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jan 4 00:37:56 igmpproxy: Note: RECV V2 member report from 172.21.50.254 to 224.0.0.2 (ip_hl 24, data 8) Jan 4 00:37:56 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jan 4 00:37:56 igmpproxy: Note: RECV V2 member report from 93.213.247.186 to 239.35.100.2 (ip_hl 24, data 8) Jan 4 00:37:56 igmpproxy: Warn: unknown Mode in V3 report (673189920) Jan 4 00:37:56 igmpproxy: Note: RECV V3 member report from 93.213.247.186 to 224.0.0.22 (ip_hl 24, data 16) Jan 4 00:37:56 igmpproxy: Note: Adding MFC: 193.158.35.245 -> 239.35.100.2, InpVIf: 2 Jan 4 00:37:56 igmpproxy: Note: Adding MFC: 193.158.35.181 -> 239.35.100.2, InpVIf: 2 Jan 4 00:37:56 igmpproxy: Note: RECV V2 member report from 172.21.50.150 to 239.35.100.2 (ip_hl 24, data 8) Jan 4 00:37:50 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jan 4 00:37:50 igmpproxy: Note: RECV V2 member report from 93.213.247.186 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:37:50 igmpproxy: Warn: unknown Mode in V3 report (673189920) Jan 4 00:37:50 igmpproxy: Note: RECV V3 member report from 93.213.247.186 to 224.0.0.22 (ip_hl 24, data 16) Jan 4 00:37:50 igmpproxy: Note: Adding MFC: 193.158.35.65 -> 239.35.132.11, InpVIf: 2 Jan 4 00:37:50 igmpproxy: Note: RECV V2 member report from 172.21.50.150 to 239.35.132.11 (ip_hl 24, data 8) Jan 4 00:37:48 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jan 4 00:37:48 igmpproxy: Note: RECV V2 member report from 93.213.247.186 to 239.255.255.250 (ip_hl 24, data 8) Jan 4 00:37:48 igmpproxy: Warn: unknown Mode in V3 report (673189920) Jan 4 00:37:48 igmpproxy: Note: RECV V3 member report from 93.213.247.186 to 224.0.0.22 (ip_hl 24, data 16)
If you need more infos or logs, tell me.
Thx for helping!
-
Do you need more Infos?
-
Just a guess, try taking "quickleave" out of your configuration. It sounds like you've stopped receiving the ch1 stream until your igmp querier sends a general query (typically every 125 seconds), when your box joins the stream again and your playback picks up. There could be some timing bug there (eg. pfsense's igmp proxy doesn't coordinate the quickleave activity with the fact that you re-joined the group). Of course if you have a low bandwidth link you may need quickleave to function without overrunning your bandwidth.
No idea how to resolve your second issue, unicast->multicast transition, I'd guess it has to be sorted out in your endpoint (stb or video player). Just curious, does it work smoothly without pfsense/igmp proxy in the mix?
-
Thx, for the answer.
Just a guess, try taking "quickleave" out of your configuration.
Can you explain, how?
No idea how to resolve your second issue, unicast->multicast transition, I'd guess it has to be sorted out in your endpoint (stb or video player). Just curious, does it work smoothly without pfsense/igmp proxy in the mix?
It worked fine with the Router from my ISP (Speedport 920V, a special Version of a Fritz!Box), so I think it´s a issue of the IGMP-Proxy of pfsense.
-
Just a guess, try taking "quickleave" out of your configuration.
Can you explain, how?
I've not used it offhand, so no (I assume there must be no config option for that, nor direct config editing page). Maybe just ssh to the box, find the config file, edit it and restart the proxy as a test (which might well be undone the next time you reboot or save the config).
No idea how to resolve your second issue, unicast->multicast transition, I'd guess it has to be sorted out in your endpoint (stb or video player). Just curious, does it work smoothly without pfsense/igmp proxy in the mix?
It worked fine with the Router from my ISP (Speedport 920V, a special Version of a Fritz!Box), so I think it´s a issue of the IGMP-Proxy of pfsense.
Or it might have to do with how the firewall works, eg. ignoring/forwarding duplicate packets or the like. You might be able to get a packet dump of such a transition that works with the speedport and another that fails with pfsense and compare them and maybe tell what's going on .. and as such the nature of what would need done to fix it. Alternately (or additionally), try taking a capture of the packets "before" it hits pfsense and after and compare those.