Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IGMP-Proxy and IPTV - two Issues

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    7 Posts 3 Posters 9.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      Beerman
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • J
        jlepthien
        last edited by

        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?

        | apple fanboy | music lover | network and security specialist | in love with cisco systems |

        1 Reply Last reply Reply Quote 0
        • B
          Beerman
          last edited by

          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!

          1 Reply Last reply Reply Quote 0
          • B
            Beerman
            last edited by

            Do you need more Infos?

            1 Reply Last reply Reply Quote 0
            • jnorellJ
              jnorell
              last edited by

              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?

              1 Reply Last reply Reply Quote 0
              • B
                Beerman
                last edited by

                Thx, for the answer.

                @jnorell:

                Just a guess, try taking "quickleave" out of your configuration.

                Can you explain, how?

                @jnorell:

                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.

                1 Reply Last reply Reply Quote 0
                • jnorellJ
                  jnorell
                  last edited by

                  @Beerman:

                  @jnorell:

                  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).

                  @Beerman:

                  @jnorell:

                  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.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.