Enable IPTV (IGMP Multicast) - 50$?



  • I posted this to catch all, but no reply. I have switched to VDSL and my ISP automatically enables IP-TV and sends a receiver for the TV programs. However the receiver only works with the router that the ISP gives away. But I love my pfSense! Here is the information I have found so far:

    http://forum.pfsense.org/index.php/topic,626.0.html

    The change has to go into the main pfSense release it seems, since it needs a kernel option. Here is more information:

    http://m0n0.ch/wall/list-dev/showmsg.php?id=3/51

    The Linux people do it differently with a "IGMP proxy":
    http://man-wiki.net/index.php/T-Home_IPTV_without_speedport_W_700V

    Is 50$ enough for developers to consider this?



  • Uhhh, no takers? Any reasons why? Should be "fairly" easy for devs? Compile the kernel with mrouted option and then add the program mentioned in the m0n0wall mailing list?

    Right now I can't use my TV box  :'(



  • i think 50 $  is verry little monny
    for a big thing like a freebsd kernal change



  • @jeroen234:

    i think 50 $  is verry little monny
    for a big thing like a freebsd kernal change

    Would you be a taker for this? It seems the m0n0wall people are already working on it. And it's not a change in the kernel, it's a kernel option before you recompile.
    http://m0n0.ch/wall/list-dev/showmsg.php?id=3/51
    "1. First step is to enable multicast routing in the kernel and recompile. You need to add options MROUTING" to your kernel configuration file for this."

    I did things like that on Linux, but I don't know how to build pfSense. And even if I could, I would end up with a "special" built, unable to install future updates, or I would have to build them myself. This change has to go into the main pfSense distribution. Building the "mrouted" binary and including it into pfsense could be a package then… But IPtv is getting more common now, so this ability is important.



  • Apparently this will be useful for miniupnp as well.

    Are you still interested in this?  Anyone else want to jump in (not for comment, for $$)???



  • Indeed, I am interested. Right now I have to use the little router the ISP sent me, its the only one that can do IGMP multicasts out of the box. Having said that, it seems there are two theoretical ways to enable this:
    a) The method described above, with the kernel option and "mrouted".
    b) Leave everything like it is and use a "IGMP Proxy". It seems there is one here:
    http://potiron.loria.fr/projects/madynes/internals/perso/lahmadi/igmpv3proxy

    Also, I think the solution needs to be integrated with the traffic shaper so that the TV stream always get's enough bandwith.

    And one question: How can I pay the bounty? I don't have paypal and I don't plan on getting it.



  • If this goes to coreteam@ I believe that the Paypal account is setup to handle credit card payments (with a 3% paypal fee).

    –Bill



  • This is driving me nuts. Finally lines are fast enough to do IPTV and all the software is really old and cumbersome. I downloaded the dev iso, rebuilt the kernel with multicast enabled, created an update and installed it on a test harddisk. Then copied mrouted from a FreeBSD installation to pfSense. I'm kinda lost now:

    mrouted -d

    debug level 0x2de (pruning,routing,peers,cache,interface,membership,igmp)
    15:37:40.309 mrouted version 3.9-beta3+IOS12 starting
    15:37:40.310 Getting vifs from kernel interfaces
    15:37:40.311 installing em0 (192.168.1.1 on subnet 192.168.1/24) as vif #0 - rate=0
    15:37:40.311 warning - ignoring ng0, has invalid address (...) and/or mask (255.255.255.255)
    15:37:40.311 Getting vifs from /etc/mrouted.conf
    15:37:40.312 can't forward: only one enabled vif

    Just changed the real IP adress to stars (*) for this message. It seems that darn "ng0" prohibits mrouted to start up…. ARGH.

    Looking on the net doesn't help at all. There are only a handful of people and projects from years ago. I'm bound to that stupid "Deutsche Telekom" router, it's the only router that can do the IGMP right now.



  • do you think that the old router you has actually has two interfaces an ng and an underlying interface.(like windows pppoe over ethernet implementation) don't bind the mroute to the ng but to the interface that the pppoe ng uses
    due to the nature of multicast the ip address of this might not be important to get this back to where you want it



  • Well, that is the question. The router from "Deutsche Telekom" is like a black box. It's called W700V and it seems it's produced by Siemens. More infos in German:
    http://www.kessler-design.com/speedport-w700v/

    The first strange way is the DSL modem from the ISP. The WAN Interface in the router has to be set to VLAN ID 7 which was easy with pfSense.

    But how they did the IGMP stuff, I don't know. And I don't quite understand the mrouted documentation. I can set it to use em0 and em1 interfaces but it doesn't work. mrouted complains about em1 (which is the WAN interface). And ng0 apparently can't bet set. All the different examples seem to be from setups like a university network where no PPPoe is involved.



  • try setting it to vlan id 1 till 6 to get the igmp stream



  • What would be the benefit? The WAN interface HAS to bet set to ID7, otherwise I can't get any connection to the internet.

    Wall socket->VDSL Modem->VDSL Lan Interface (hardcoded to VLAN ID 7)->WAN Interface pfSense



  • if you create a VLAN you have to add it to the available Interfaces.
    so you can add multiple different VLANs to the same physical interface.
    i believe what jeroen234 meant was that you have to add other VLAN-Interfaces on which you can get the IGMP stream.



  • @GruensFroeschli:

    if you create a VLAN you have to add it to the available Interfaces.
    so you can add multiple different VLANs to the same physical interface.
    i believe what jeroen234 meant was that you have to add other VLAN-Interfaces on which you can get the IGMP stream.

    agreed or set the mroute to use the vlan with id7 (so it would be something like binding mroute to vlan0 )



  • Hrm, this is not working. I think you guys still have a misunderstanding. There is a VDSL modem that only "talks" to my WAN interface if it's set to "VLAN ID 7". This works fine for everything except IPTV.
    The TV box simply connects to the providers server, first ten seconds are sent by unicast, after ten seconds the stream switches to multicast.

    Now, I played around with mrouted and it seems there are conditions:

    1. You can't set it to use interfaces like "ng0" or "vlan0". It will only accept physical interfaces like "em0" which is the LAN interface in my case.
    2. The interface needs a IP address. I have just learned that today. Thats why mrouted is complaining about only seeing one interface. For a quick test I gave the WAN interface a IP adress (a private one).
    Then mrouted can be started but of course this won't work, actually doing something.
    The whole thing is kinda out of my league. I hope someone has more ideas.

    mrouted -d 3

    debug level 0xffffffff (packet,pruning,routing,route_detail,peers,cache,timeout,interface,membership,traceroute,igmp,icmp,rsrr)
    16:13:15.140 mrouted version 3.9-beta3+IOS12 starting
    16:13:15.141 created timeout 1 (#0)
    16:13:15.141 Got 232448 byte buffer size in 8 iterations
    16:13:15.141 registering icmp socket fd 4

    16:13:15.141 Getting vifs from kernel interfaces
    16:13:15.142 installing em0 (192.168.1.1 on subnet 192.168.1/24) as vif #0 - rate=0
    16:13:15.143 installing em1 (192.168.3.2 on subnet 192.168.3/24) as vif #1 - rate=0
    16:13:15.143 warning - ignoring ng0, has invalid address (87.152.93.79) and/or mask (255.255.255.255)
    16:13:15.143 Getting vifs from /etc/mrouted.conf
    16:13:15.144 Installing vifs in mrouted…
    16:13:15.145 vif #0, phyint 192.168.1.1
    16:13:15.146 0.0.0.0 advertises new route 192.168.1/24
    16:13:15.146 0.0.0.0 advertises 192.168.1/24 with adj_metric 1 (ours was 32)
    16:13:15.146 assuming querier duties on vif 0
    16:13:15.146 sending query on vif 0
    16:13:15.147 SENT membership query  from 192.168.1.1    to 224.0.0.1
    16:13:15.147 SENT neighbor probe    from 192.168.1.1    to 224.0.0.4
    16:13:15.147 vif #1, phyint 192.168.3.2
    16:13:15.149 0.0.0.0 advertises new route 192.168.3/24
    16:13:15.149 0.0.0.0 advertises 192.168.3/24 with adj_metric 1 (ours was 32)
    16:13:15.149 assuming querier duties on vif 1
    16:13:15.149 sending query on vif 1
    16:13:15.149 warning - sendto to 224.0.0.1 on 192.168.3.2: Operation not permitted
    16:13:15.150 SENT membership query  from 192.168.3.2    to 224.0.0.1
    16:13:15.150 warning - sendto to 224.0.0.4 on 192.168.3.2: Operation not permitted
    16:13:15.150 SENT neighbor probe    from 192.168.3.2    to 224.0.0.4
    vifs_with_neighbors = 0

    Virtual Interface Table
    Vif  Name  Local-Address                              M  Thr  Rate  Flags
    0    em0  192.168.1.1    subnet: 192.168.1/24        1  1      0  querier
                        IGMP querier: 192.168.1.1        (this system)
                          Nbr bitmaps: 0x0000000000000000

    1    em1  192.168.3.2    subnet: 192.168.3/24        1  1      0  querier
                        IGMP querier: 192.168.3.2        (this system)
                          Nbr bitmaps: 0x0000000000000000

    Multicast Routing Table (2 entries)
    Origin-Subnet      From-Gateway    Metric Tmr Fl In-Vif  Out-Vifs
    192.168.3/24                          1    0 C.  1    0*
    192.168.1/24                          1    0 C.  0    1*

    16:13:15.151 created timeout 2 (#0)
    16:13:15.151 created timeout 3 (#1)
    16:13:15.152 created timeout 4 (#2)
    16:13:15.152 RECV membership query  from 192.168.1.1    to 224.0.0.1
    16:13:15.152 ignoring query from 192.168.1.1; querier on vif 0 is still me
    16:13:16.152 about to call timeout 2 (#0)
    16:13:16.152 created timeout 5 (#0)
    16:13:17.153 about to call timeout 5 (#0)
    16:13:17.153 created timeout 6 (#0)
    16:13:18.154 about to call timeout 6 (#0)
    16:13:18.154 created timeout 7 (#0)
    16:13:19.155 about to call timeout 7 (#0)
    16:13:19.155 created timeout 8 (#1)
    16:13:20.156 about to call timeout 3 (#0)
    16:13:20.156 aging forwarding cache entries
    16:13:20.156 sending query on vif 0
    16:13:20.156 SENT membership query  from 192.168.1.1    to 224.0.0.1
    16:13:20.156 sending query on vif 1
    16:13:20.157 warning - sendto to 224.0.0.1 on 192.168.3.2: Operation not permitted
    16:13:20.157 SENT membership query  from 192.168.3.2    to 224.0.0.1
    16:13:20.158 SENT neighbor probe    from 192.168.1.1    to 224.0.0.4
    16:13:20.159 warning - sendto to 224.0.0.4 on 192.168.3.2: Operation not permitted
    16:13:20.159 SENT neighbor probe    from 192.168.3.2    to 224.0.0.4
    16:13:20.159 created timeout 9 (#2)



  • @bob:

    Is 50$ enough for developers to consider this?

    I will add $50 to the bounty.



  • It's been a while since I requested this. I investigated a bit further and the whole problem seems to be the lack of a working IGMP proxy for FreeBSD. Incredible enough, there is none, zero. There is a very old one that was done for FreeBSD 4.x. It does not compile on 6.2. There is mrouted but this one doesn't do "proxy work".
    There is a working proxy for Linux: http://sourceforge.net/projects/igmpproxy
    I have no idea how to convince anyone to port this thing to FreeBSD. They programming stuff is beyond me…
    I even tried to install the Linux compatibility stuff for FreeBSD (on a VMware), but the compiled proxy complains about something in the glibc....



  • I think it will be best to ask the other way: How much would it cost to get this done? What I'd like to see is a IGMP proxy for FreeBSD, open source, maybe with a GPL license? It's really fascinating to see that there is no such program for BSD* and only one for Linux.


Log in to reply