troglobit / pimd

PIM-SM/SSM multicast routing for UNIX and Linux
http://troglobit.com/projects/pimd/
BSD 3-Clause "New" or "Revised" License
197 stars 87 forks source link

IPTV via ppp0 Interface #74

Closed sharbich closed 8 years ago

sharbich commented 8 years ago

Hi, if i start pimd i'am see not the ppp0 Interface over "ip mroute show". Here is my ip mroute show (192.168.30.5, 239.255.255.250) Iif: wlan-1 Oifs: lan-1.50 pimreg (192.168.20.25, 239.255.255.250) Iif: lan-1.100 Oifs: lan-1.50 pimreg (192.168.30.2, 239.255.255.250) Iif: wlan-1 Oifs: lan-1.50 pimreg (192.168.1.2, 239.255.255.250) Iif: lan-1.1 Oifs: lan-1.50 pimreg (192.168.1.3, 239.255.255.250) Iif: lan-1.1 Oifs: lan-1.50 pimreg (192.168.10.130, 239.255.255.250) Iif: lan-1.50 Oifs: pimreg (192.168.20.26, 239.255.255.250) Iif: lan-1.100 Oifs: lan-1.50 pimreg (192.168.30.3, 239.255.255.250) Iif: wlan-1 Oifs: lan-1.50 pimreg

Here is my pimd.conf phyint ppp0 enable altnet 193.158.0.0/15 phyint lan-1.50 enable rp-address 62.155.244.180 224.0.0.0/4 spt-threshold packets 0 interval 100 bsr-candidate priority 5 rp-candidate time 30 priority 20 spt-threshold packets 0 interval 100

My Mediareciveer is in the lan-1.50 network. Over the igmpproxy deamon ist the IPTV running. Why it does not go beyond "pimd"? Thanks for helping

troglobit commented 8 years ago

An image, even a simple ASCII drawing, would greatly help me understand your topology.

Have you read my Multicast FAQ and checked the TTL?

sharbich commented 8 years ago

Here is my Network Topology

IPCop FW with PIMD 2.3.2 Internet (ppp0) lan-1.1 192.168.1.0/24 (Transfer Network to the Switch .10) lan-1.50 192.168.10.0/24 (Media Reciever Telekom Entertain IPTV MR300 .130) lan-1.100 192.168.20.0/24 (DMZ - Plex Media Server with DLNA .20) wlan-1 192.168.30.0/24 (Wirekess Network with three Repeater .2/.3/.5)

Which TTL are configure in the pimd.conf for IPTV? Thanks for helping

sharbich commented 8 years ago

When I start the igmpproxy and run "ip mroute show" (193.158.35.243, 239.35.100.10) Iif: ppp0 Oifs: lan-1.50 (192.168.20.20, 239.255.255.250) Iif: unresolved (192.168.20.25, 239.255.255.250) Iif: unresolved (192.168.10.130, 239.255.255.250) Iif: unresolved (192.168.30.2, 239.255.255.250) Iif: unresolved (192.168.1.2, 239.255.255.250) Iif: unresolved I see the ppp0 Interface. When I start pimd and run "ip mroute show" (192.168.30.5, 239.255.255.250) Iif: wlan-1 Oifs: lan-1.100 lan-1.1 lan-1.50 pimreg (192.168.20.26, 239.255.255.250) Iif: lan-1.100 Oifs: wlan-1 lan-1.1 lan-1.50 pimreg (192.168.30.3, 239.255.255.250) Iif: wlan-1 Oifs: lan-1.100 lan-1.1 lan-1.50 pimreg (192.168.1.3, 239.255.255.250) Iif: lan-1.1 Oifs: wlan-1 lan-1.100 lan-1.50 pimreg (192.168.20.25, 239.255.255.250) Iif: lan-1.100 Oifs: wlan-1 lan-1.1 lan-1.50 pimreg (192.168.10.131, 239.255.255.250) Iif: lan-1.50 Oifs: wlan-1 lan-1.100 lan-1.1 pimreg (192.168.20.20, 239.255.255.250) Iif: lan-1.100 Oifs: wlan-1 lan-1.1 lan-1.50 pimreg (192.168.30.2, 239.255.255.250) Iif: wlan-1 Oifs: lan-1.100 lan-1.1 lan-1.50 (192.168.1.2, 239.255.255.250) Iif: lan-1.1 Oifs: wlan-1 lan-1.100 lan-1.50 (192.168.10.130, 239.255.255.250) Iif: lan-1.50 Oifs: wlan-1 lan-1.100 lan-1.1 I see not the ppp0 Interface. Thanks for helping

troglobit commented 8 years ago

I still don't fully understand your setup, and you also seem to have some other issues with your "WAN" network, which I'm unsure I can help with.

Let me start by taking the time to explain a bit about routing in general, and routing of multicast in particular. First off, multicast is like broadcast if it's not managed, so it's inherently dangerous. That's why it by default in most TCP/IP stacks get a TTL of 1 (one) to prevent it from being routed. (Routing of broadcast would be a very dangerous idea)

Incoming multicast stream, e.g. 225.1.2.3 (TTL:2)
|
V 
|      +--------+                   +------+
|      |        |  Same multicast   |      |
+----->| Router |------------------>|  TV  |
       |        | routed => TTL:1   |      |
       +--------+                   +------+

For a traffic stream to be routed (unicast or multicast), the TTL of the stream. I.e., the IP TTL field of each packet from the sender, must be >1. Each router it passes on the way to the receiver decrements the TTL with (at least) one. TTL zero does not exist, so for any packet to be routed the TTL must be at least 2.

My qustion, which is what most people stumble upon when attempting to route multicast, is what the TTL of the inbound multicast stream(s) is. It must be >1 ... as I explained above. For more on multicast routing basics, see my HowTo & FAQ.

The command ip mroute show lists the active routes set up by the multicast routing daemon (igmpproxy, pimd, mrouted, or smcroute ... there can be only one running at a time). Both igmpproxy and smcroute are of the "static" routing kind, so they install the multicast routes as soon as they are started. In the former case I believe it installs routes when multicast comes in on some interface, but not sure since I've never used igmpproxy. On the other hand pimd and mrouted are dynamic routing daemon, and only installs a route when someone asks for it.

In your case, to see if pimd has registered ppp0 and is prepared to route to/from it, check the output from cat /proc/net/ip_mr_vif. If it's not listed there, then it is somehow being filtered out by pimd as an unsuitable interface.

But none of this matters if the TTL of the inbound multicast stream is <2. (Judging from your description you also have a DMZ (?), so maybe the TTL in your case must even be >=3 ... dunno, too little information to help you).

sharbich commented 8 years ago

Thanks for your Input I see the pp0 Interface in /proc/net/ip_mr_vif Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote

0 wan-1 0 0 0 0 00000 0200A8C0 00000000 1 wlan-1 750 5 852 5 00000 011EA8C0 00000000 2 lan-1.100 646 4 450 3 00000 0114A8C0 00000000 3 lan-1.1 450 3 600 4 00000 0101A8C0 00000000 4 lan-1.50 936 4 1602 10 00000 010AA8C0 00000000 5 ppp0 0 0 0 0 00000 B8AEA257 B4F49B3E 6 pimreg 0 0 1602 10 00004 0200A8C0 00000000

Here is my static route

default 62.155.244.180 0.0.0.0 UG 0 0 0 ppp0 62.155.244.180 * 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 * 255.255.255.0 U 0 0 0 wan-1 192.168.1.0 * 255.255.255.0 U 0 0 0 lan-1.1 192.168.10.0 * 255.255.255.0 U 0 0 0 lan-1.50 192.168.20.0 * 255.255.255.0 U 0 0 0 lan-1.100 192.168.30.0 * 255.255.255.0 U 0 0 0 wlan-1 192.168.192.0 192.168.20.20 255.255.255.0 UG 0 0 0 lan-1.100

Is my pimd.conf as okay?

phyint ppp0 enable altnet 193.158.0.0/15 ttl-threshold 1 phyint lan-1.50 enable rp-address 62.155.244.180 224.0.0.0/4 spt-threshold packets 0 interval 100 bsr-candidate priority 5 rp-candidate time 30 priority 20

troglobit commented 8 years ago

Your pimd.conf looks overly complex, but did you even stop to check the TTL of the inbound multicast stream? If that's wrong no correct configuration in the world can help you :disappointed:

# These two are only needed if pimd is stared with -N flag
phyint ppp0 enable
phyint lan-1.50 enable
# Used for more complex topologies, but is OK to keep anyway
spt-threshold packets 0 interval 100
# These two are requried in case more PIM routers are available
bsr-candidate priority 5
rp-candidate time 30 priority 20

The default pimd.conf shipped with the distribution is a one-size-fits-all that should work for most use-cases.

sharbich commented 8 years ago

How do I get the TTL out? Here is my tcpdump via ppp0 tcpdump -i ppp0 | grep igmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 20:19:41.785482 IP p57A2AEB8.dip0.t-ipconnect.de > pim-routers.mcast.net: igmp v2 report pim-routers.mcast.net 20:19:49.675999 IP p57A2AEB8.dip0.t-ipconnect.de > igmp.mcast.net: igmp v2 report igmp.mcast.net 20:20:21.943147 IP p57A2AEB8.dip0.t-ipconnect.de > all-systems.mcast.net: igmp query v3 20:20:22.215127 IP 62.155.244.180 > igmp.mcast.net: igmp v2 report igmp.mcast.net 20:20:23.602898 IP p57A2AEB8.dip0.t-ipconnect.de > all-routers.mcast.net: igmp v2 report all-routers.mcast.net 20:20:25.153025 IP p57A2AEB8.dip0.t-ipconnect.de > igmp.mcast.net: igmp v2 report igmp.mcast.net 20:20:28.863292 IP p57A2AEB8.dip0.t-ipconnect.de > pim-routers.mcast.net: igmp v2 report pim-routers.mcast.net 20:20:36.930260 IP p57A2AEB8.dip0.t-ipconnect.de > all-systems.mcast.net: igmp query v3 20:20:38.620201 IP p57A2AEB8.dip0.t-ipconnect.de > igmp.mcast.net: igmp v2 report igmp.mcast.net 20:20:38.810202 IP p57A2AEB8.dip0.t-ipconnect.de > all-routers.mcast.net: igmp v2 report all-routers.mcast.net 20:20:39.767794 IP 62.155.244.180 > all-systems.mcast.net: igmp query v3 20:20:41.934209 IP p57A2AEB8.dip0.t-ipconnect.de > pim-routers.mcast.net: igmp v2 report pim-routers.mcast.net 20:20:42.134435 IP p57A2AEB8.dip0.t-ipconnect.de > igmp.mcast.net: igmp v2 report igmp.mcast.net 20:20:43.494301 IP p57A2AEB8.dip0.t-ipconnect.de > all-routers.mcast.net: igmp v2 report all-routers.mcast.net

troglobit commented 8 years ago

The man page for tcpdump helps:

tcpdump -i ppp0 -v 

IGMP is the control protocol for IPv4 multicast and it is per-link, so you don't want to route that. Use the tcpdump filtering mechanism instead:

tcpdump -i ppp0 -v multicast
sharbich commented 8 years ago

Thank You for your patience. The tcpdump -i ppp0 -v multicast is not going. The interface is not supported. Okay, i have start over the lan-1.50 Interface. I see

20:50:28.689484 IP (tos 0x60, ttl 1, id 34124, offset 0, flags [none], proto IGMP (2), length 56, options (RA)) 192.168.10.130 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 239.35.10.5 is_ex, 0 source(s)] [gaddr 239.35.100.10 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)]

Here ist the tcpdump when the igmpproxy is browsing

21:00:25.345225 IP (tos 0x80, ttl 26, id 0, offset 0, flags [none], proto UDP (17), length 1356) 193.158.35.251.47811 > 239.35.10.5.ndmp: UDP, length 1328

what do I have now in the pimd.conf Configure File?

Verry, verry thanks for helping.

troglobit commented 8 years ago

OK, the multicast group you're probably interested in is 239.35.10.5, with a TTL of 26, which is good news! (I say probably because with the small sample it's only guesswork.)

Now, since pimd is a dynamic routing daemon it will not set up a route unless there is someone on "the other side" requesting the multicast group. Routing takes place on Layer-3, but requesting multicast on a LAN uses Layer-2 (or 2+) with IGMP for IPv4 and MLD for IPv6.

Hence, someone on the "inside" of the PIM router needs to do an IGMP "join" for the group 239.35.10.5 for pimd notice and set up the multicast route (which you can then see with ip mroute show). I don't know what kind of equipment you have on the inside to receive the IPTV, but if it does not send out an IGMP "join" (also called IGMP membership report) routing with pimd will not work and you'll have to set up a static route with smcroute instead. The config for smcroute is slightly more cumbersome, since you have to know the sender IP for multicast routes -- but hey, we know that now, it seems to be sent by 193.158.35.251! :smiley:

So, two options. Continue trying to figure out if your TV or set-top-box sends IGMP join for the group it wants ... (or groups, could be one per channel?). Your best friend here is tcpdump again, but this time you want to see the IGMP packets :sweat_smile: ... the other is to try out smcroute with a static setup, static rules. Again, you have to chose, you cannot run two multicast routing daemons at the same time.

sharbich commented 8 years ago

Here is the Multicast Address List for IPTV http://grinch.itg-em.de/entertain/faq/allgemein/multicastadressliste/ Must I installation smcroute? Here is the Log when pimd is running on the Interface who the Mediareciever is running.

tcpdump -i lan-1.50 -v | grep 192.168.10.130 tcpdump: listening on lan-1.50, link-type EN10MB (Ethernet), capture size 262144 bytes 192.168.10.130.h323hostcallsc > 87.141.142.14.ap: UDP, length 134 87.141.142.14.ap > 192.168.10.130.h323hostcallsc: UDP, length 65 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.h323hostcallsc > 87.141.142.14.ap: UDP, length 134 192.168.10.130.cap > 193.158.35.239.43962: UDP, length 113 193.158.35.239.43962 > 192.168.10.130.cap: UDP, length 50 192.168.10.130 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 239.35.10.4 is_ex, 0 source(s)] [gaddr 239.35.100.10 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)] 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 239.35.10.4 is_ex, 0 source(s)] [gaddr 239.35.100.10 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)] 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.cap > 193.158.35.243.43962: UDP, length 113 193.158.35.243.43962 > 192.168.10.130.cap: UDP, length 50 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.35.10.4 to_in, 0 source(s)] 192.168.10.130 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.35.10.4 to_ex, 0 source(s)] 192.168.10.130 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.35.10.4 to_ex, 0 source(s)] 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 239.35.10.4 is_ex, 0 source(s)] [gaddr 239.35.100.10 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)] 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.cap > 193.158.35.239.43962: UDP, length 113 193.158.35.239.43962 > 192.168.10.130.cap: UDP, length 50 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 22:50:27.049076 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.130 tell 192.168.10.1, length 28 22:50:27.067024 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.130 is-at 00:23:a2:89:17:76 (oui Unknown), length 46 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130.optima-vnet > 239.255.255.250.us-cli: UDP, length 1273 192.168.10.130 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 239.35.10.4 is_ex, 0 source(s)] [gaddr 239.35.100.10 is_ex, 0 source(s)]

troglobit commented 8 years ago

OK, I'm not sure what else I can do to help you. I've invested quite a lot of time to try to tell you about multicast, how routing multicast works, tools to help you debug and possible alternatives to pimd.

Like I said, pimd should work out of the box, no extra config needed, if multicast data comes in on one interface and is requested by a receiver using IGMP (control protocol) on another interface.

It is still unclear to me if you have the required multicast stream(s) actually coming in on ppp0. If you don't then pimd is not for you. Then you probably need to look at igmpproxy instead, which could be what is required to forward the IGMP join from your local LAN to ppp0 to tell the multicast sender to start forwarding the requested group. This is something pimd doesn't do.

I'm sorry, but I do not think I can help you anymore.

sharbich commented 8 years ago

Unfortunately, the igmpproxy can supported one upstream interface. I have two Interfaces with sends multicast. IPTV via ppp0 and Plex Mediaserver via lan-1.100. When the igmpproxy start i can see Television, not see Stream's from Plex Media Server. When I start PIM I can see the stream from Plex Mediaserver. The Television stop after 5 second. Because the first Stream is unicast and after then send the transmitter multicast. I sit so long on this problem. Thanks for your helping.

By the Way here is the ip mroute show Input when the igmpproxy is running

(193.158.35.175, 239.35.100.10) Iif: ppp0 Oifs: lan-1.50 (193.158.35.239, 239.35.100.10) Iif: ppp0 Oifs: lan-1.50 (193.158.35.251, 239.35.10.4) Iif: ppp0 Oifs: lan-1.50

sharbich commented 8 years ago

When I start pimd in the Debug Modus I see the folling Information.

23:55:41.349 Received IGMP v2 Membership Report from 87.162.174.184 to 224.0.0.22 23:55:41.349 accept_group_report(): igmp_src 87.162.174.184 ssm_src 224.0.0.22 group 224.0.0.22 report_type 22 23:55:41.349 accept_group_report(): al_pv=2 23:55:41.349 Set delete timer for group: 224.0.0.22 23:55:41.349 Not creating routing entry for LAN scoped group 224.0.0.22

Why the pimd can not a routing entry?

troglobit commented 8 years ago

IGMP, the control protocol, uses several reserved multicast addresses. The 224.0.0.22 is one such address used for registering multicast group memberships. Actually the whole 224.0.0.* is reserved and is link-local only, i.e. only for the local LAN -- so none of those groups are to be routed, hence the message above.

I don't think I can help you anymore, I feel you may need a very custom setup to get this working the way you want and that is not something I can support you with.