1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

iptv via tomato

Discussion in 'Tomato Firmware' started by bogderpirat, Apr 19, 2009.

  1. bogderpirat

    bogderpirat Network Guru Member

    hi guys,

    i've been trying for months now to get iptv working behind my WRT54GL with tomato, but to no avail. i thought i'd ask you guys if you can give me any directions on how to debug things.

    i have this media receiver box supplied by my ISP (t-home) that, behind the isp's original router, gets the tv channels just fine. when their router is used, i can also use videolan client to view several channels using specific udp/rtp-adresses.
    another option that makes iptv work is if i just attach a linux-running laptop to the modem and dial out (pppoe) manually. again, using vlc will make iptv work.
    i am also reading that dd-wrt allows you to use iptv as well. but screw them, i want my tomato!

    there are several articles on the internet by people who have succeeded in configuring linux debian routers to permit iptv, like here and here (german.

    as you will read there, or if you take a look at the dd-wrt forums, t-home gears their routers with igmp proxies that will receive a multicast data stream from the internet and distribute it on the LAN to devices that subscribe to a certain group on the igmp proxy. tomato has such a proxy, it is enabled as soon as you enable "allow multicast" under advanced->firewall in your webif. that does not work though.


    what i have tried so far are the following things:
    1. some time ago (last year i think), forums user kornaz posted a compiled binary of igmpproxy in one of victek's mod's threads. this was the url. he said he'd gotten his iptv to work with it, but tests on my side, indiscriminantly following his instructions in the .conf file, had no success. these instructions entailed disabling multicast, then manually accepting the connections using iptables rules. those are also listed on the first link two paragraphs back. i have done this both trying out tomato's built-in igmprt as well as the above compilation.

    2. disabled multicast, restarted the router, entered my LAN ip as the DMZ. this, from what i'm understanding, forwards every and all kind of traffic to my pc (which is running no software firewall). theoretically, this should give me the ability to view iptv via vlc, as hooking up a laptop to dial out manually as described above allowed me to watch iptv even without an igmp proxy. however, nothing shows up.

    3. there are a couple of other combinations i've tried getting this to work, but as previously mentioned to no avail. i have taken a look at the source code's kernel .config file, it shows that multicast support is being compiled for it, so that can't be it.
    i have also enabled the logging of blocked connections and i'm showing this kind of entry every 15 seconds:
    , where SRC= equals my dialin gateway and DST appears to be the ip that multicast traffic is coming from. i am suspecting that the firewall drops these packets for some reason, but have no idea how to make it stop doing that, or why it isn't doing that when i allow multicast traffic via the webif.


    as you might be figuring by now, i'm at a loss on how to progress further. anyone got any ideas?
     
  2. bogderpirat

    bogderpirat Network Guru Member

    is tomato's kernel maybe dropping multicast packets despite being configured to include multicast routing?

    how would i debug that? anyone?
     
  3. bogderpirat

    bogderpirat Network Guru Member

    my isp just recently moved me over to their new architecture - moving the iptv access from the regular (vlan7-tagged) internet connection to a separate one that is tagged as vlan8. this gives me new hopes on solving this issue.

    i created a vlan8 device using the nvram variables vlan8hwname and vlan8ports:
    Code:
    nvram set vlan8hwname=et0
    nvram set vlan8ports="4t 5"
    nvram commit
    reboot
    alright, upon reboot, i get my vlan8-device.

    the isp has a dhcp-server running on that vlan, so i use busybox's udhcpc to obtain a lease:
    Code:
    # ifconfig vlan8 up
    # udhcpc -i vlan8
    udhcpc (v1.13.3) started
    udhcpc: exec /usr/share/udhcpc/default.script: No such file or directory
    Sending discover...
    Sending select for 93.215.208.161...
    Lease of 93.215.208.161 obtained, lease time 86400
    udhcpc: exec /usr/share/udhcpc/default.script: No such file or directory
    #
    great, so apparently, he's getting the lease. when i however ifconfig vlan8, the obtained ip apparently doesn't stick to the adaptor.

    the tcpdump'd dhcp packet looks like so:
    Code:
    20:37:27.936075 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp]
    20:37:27.995170 IP (tos 0x0, ttl 255, id 15816, offset 0, flags [none], proto UDP (17), length 407) 93.215.223.254.bootps > 93.215.208.161.bootpc: [no cksum] BOOTP/DHCP, Reply, length 379, xid 0x9a529d6a, Flags [none] (0x0000)
              Your-IP 93.215.208.161
              Server-IP 194.25.237.4 [|bootp]
    20:37:28.045035 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp]
    20:37:28.115162 IP (tos 0x0, ttl 255, id 15819, offset 0, flags [none], proto UDP (17), length 407) 93.215.223.254.bootps > 93.215.208.161.bootpc: [no cksum] BOOTP/DHCP, Reply, length 379, xid 0x9a529d6a, Flags [none] (0x0000)
              Your-IP 93.215.208.161
              Server-IP 194.25.237.4 [|bootp]
    
    why won't the ip stick? am i missing something about the topology of busybox?
     
  4. mstombs

    mstombs Network Guru Member

    The ifconfig and routes are performed in the script which you do not have. You can create one in the jffs partition (or temporarily in /var to test). I posted an example (copied from somewhere else!) for vlan2 in this thread

    http://www.linksysinfo.org/forums/showthread.php?t=54665
     
  5. bogderpirat

    bogderpirat Network Guru Member

    finally someone breaks the monologue! :D

    thanks a lot for your response. i have adapted the script to my needs and saved on a cifs share to copy it over from to the device. udhcpc however doesn't seem to invoke it correctly - or rather not at all:
    Code:
    # udhcpc -i vlan8 -s /var/vlan8.sh
    udhcpc (v1.13.3) started
    udhcpc: exec /var/vlan8.sh: No such file or directory
    Sending discover...
    Sending select for 93.215.208.161...
    Lease of 93.215.208.161 obtained, lease time 86400
    udhcpc: exec /var/vlan8.sh: No such file or directory
    strangely enough, if i let it invoke /bin/echo, it works. i even symlinked echo to the var directory:
    Code:
    # ls -hal echo vlan8
    lrwxrwxrwx    1 root     root            9 May 29 11:33 echo -> /bin/echo
    -rwxrwxrwx    1 root     root         1.1K May 29 11:08 vlan8.
    echo works, vlan8.sh doesn't.
    is that thing playing with me?

    edit: alright, got it sorted out. stupid notepad++ saved the script in windows format to the cifs folder, hence udhcpc read the first line as "#!/bin/sh^M", ^M being the carriage return control character. thus, it reported the file to be non-existant, which however appears to be the same error message for when it doesn't find a script's interpreter (which here was the case).
     
  6. bogderpirat

    bogderpirat Network Guru Member

    okay, i am somewhat giving up on the issue. i have done so many things now in order to get this working and it still doesn't, despite all the reports of success by other users who have done far less on other architectures.
    i am disclosing my findings and methods so that maybe someone with a bit more wits (or networking knowledge) may be able to end this agony.
    this post contains pieces of information that are probably only of interest for users of my very isp, T-Home. i have marked those by putting [] around them.


    evidently, the dhcp client received an ip on the [vlan8] interface. hence, the vlan-configuration should be valid.

    i made a tcpdump of the dhcp packet and have discovered several options that the dhcp server sends along with the ip ([93.215.208.x for me]) and netmask ([255.255.240.0]). these are essentially a couple of static routes that should be the same for every user of t-home. i have analyzed the tcpdump of the dhcp packet using wireshark - its latest version has a decoder for dhcp packets that also decodes these more special options.
    based on those routes, i have composed a list of commands that will add the latter to the routing table:
    Code:
    /sbin/route add -host 194.25.237.4/32 gw 93.215.223.254 dev vlan8
    /sbin/route add -net 87.140.255.0/25 gw 93.215.223.254 dev vlan8
    /sbin/route add -net 87.141.128.0/17 gw 93.215.223.254 dev vlan8
    /sbin/route add -net 193.158.34.0/23 gw 93.215.223.254 dev vlan8
    /sbin/route add -host 194.25.134.197/32 gw 93.215.223.254 dev vlan8
    /sbin/route add -net 217.6.164.40/31 gw 93.215.223.254 dev vlan8
    /sbin/route add -net 217.6.164.48/29 gw 93.215.223.254 dev vlan8
    /sbin/route add -host 217.6.164.42/32 gw 93.215.223.254 dev vlan8
    /sbin/route add -host 217.6.164.45/32 gw 93.215.223.254 dev vlan8
    /sbin/route add -net 217.6.164.46/31 gw 93.215.223.254 dev vlan8
    /sbin/route add -net 217.6.167.128/26 gw 93.215.223.254 dev vlan8
    so this should take care of anything we learn from the dhcp packet.

    from what i'm understanding in terms of linux' netfilter, we shouldn't have to use iptables to create any rules, since we're not using the ppp-interface to receive data, but instead one that already has established routes (both the ones from the dhcp packet and the one created by ifconfig vlan8 up). if i'm mistaken here (and i very well may be), please let me know. otherwise:
    Code:
    iptables -A INPUT -p igmp -j ACCEPT
    iptables -A wanin -p udp -m udp -d 224.0.0.0/4 -j ACCEPT
    (taken from kornaz' igmpproxy.conf)
    or
    Code:
    iptables -I FORWARD -s 217.0.119.0/24 -d 224.0.0.0/4 -j ACCEPT
    iptables -I FORWARD -s 193.158.35.0/24 -d 224.0.0.0/4 -j ACCEPT
    iptables -I INPUT -d 224.0.0.0/4 -j ACCEPT
    iptables -I FORWARD -d 224.0.0.0/4 -j ACCEPT
    (taken from claus' debian guide on the issue)
    i've tried both, to no avail.

    alright, dhcp and firewall done. this leaves us with the multicast routing question. the most popular solution to this is igmpproxy. both my previous links utilize it; successfully.
    using the mipsel-uclibc-gcc from the WRT54G source, i managed to compile the most current version (0.1-beta4) for the mips architecture. i have uploaded it here. it's quite large compared to the other (older) binaries floating around there (almost 300KiB), but i'm happy i even managed to compile it correctly.
    the program runs fine, even accepts my configuration. the relevant lines should be these (look at the .conf of kornaz' link for a bit of documentation):
    Code:
    quickleave
    phyint vlan8 upstream ratelimit 0 threshold 1 # the "upstream-device"
    altnet 239.35.0.0/16; # isp's iptv servers
    altnet 193.158.35.0/24; # same as above
    altnet 192.168.0.2/24; # subnet of my iptv box
    phyint br0 downstream ratelimit 0 threshold 1 # the "downstream-device"
    now in terms of the correctness of this config, i have tried a LOT of different combinations when at first it wouldn't work, but in terms of logic, these seem to be the correct values (vlan8 being upstream, br0 being downstream).

    now, all should be set up. we have taken everything from the dhcp packet that we can, we have set up (presumably moot) firewall rules and we have configured a multicast routing daemon. after firing up the latter, we should be set.
    Code:
    ./igmpproxy -d -vv ./igmpproxy.conf
    gives us a ****load of debug. alright.

    using the isp's router, you are able to watch certain channels (those that aren't encrypted - in my case the publicly owned tv stations) using VideoLAN client. it understands the RTP protocol and uses it to get udp datagrams.
    as i have everything running though, and am trying to get vlc to open a correct stream, this is what i get from vlc:
    Code:
    ipv4 debug: resolving 239.35.129.11:10000...
    ipv4 debug: resolving :0...
    ipv4 debug: Winsock best interface is 196610
    ipv4 debug: IP_ADD_MEMBERSHIP multicast request
    main debug: using network module "ipv4"
    main debug: removing module "ipv4"
    main debug: using access2 module "access_udp"
    main debug: pre buffering
    aha! it would appear that he's sending a multicast membership. when i however take a look at igmpproxy's debug-output at the same time, there is nothing that would indicate that it is receiving, let alone processing anything of it.
    i have attached a sample of what an igmpproxy debug looks like for me, but there's nothing interesting to see. so you might as well not look at it.


    this has proven to be somewhat of a marlin to my old self. maybe someone else is successful. but i'm done with it.
     
  7. kornaz

    kornaz Addicted to LI Member

  8. bogderpirat

    bogderpirat Network Guru Member

    hey!
    thanks a bunch for your reply, i had already taken a look at your thread. i've tried it out, and it won't give me any result. i've dumped the traffic on my iptv interface and udpxy appears to send out a join request, however nothing else is transferred and thus, 5 seconds later, a leave request is sent.

    in between, there are a couple of ARP requests, but nothing else. as i've posted before, this is beyond me.
     
  9. kornaz

    kornaz Addicted to LI Member

    Check if you're allowing UDP multicast traffic in INPUT chain (_NOT_ in wanin chain, as it was with igmpproxy). I also had this 5 second problem until I finally realized that iptables chain must be changed:

    iptables -A INPUT -p udp -m udp -d 224.0.0.0/4 -j ACCEPT


    kornaz
     
  10. bogderpirat

    bogderpirat Network Guru Member

    hey!
    i'm not getting my iptv packets from the wan(ppp / vlan1)-interface, but rather from a separate interface that is also on the wan port, but tagged with vlan id 8. i have hence always operated with the INPUT chain rather than the wanin chain (ignore the above mentioning of wanin - that was an older attempt).
    i've also tried the iptables rules from your posting in the other thread on a vanilla tomato, but it just won't work.
    an execution of tcpdump doesn't show me any dropped packets, so i'm guessing that's not it.
     

Share This Page