IPTV, IGMP and rp_filter | Performance Magic

Ramblings from a Sysadmin

December 6, 2012

IPTV, IGMP and rp_filter

Having solved a very interesting multicast issue at work recently I decided it was once again time to have a go at getting IPTV working from my ISP TPG.

I used to run Bering leaf, but never found a package or could be bothered building igmpproxy (which seemed to be the way to go) for leaf, and so have never really sat down and looked into getting IPTV working properly.

Having moved my primary gateway to Debian on a VM (I bridge the modem via dedicated NIC on the physical server and then a dedicated bridge at KVM level) about a year ago, I always had it in the back of my mind that I should sit down and actually work out how to get IPTV on to my network at home, not sure I will ever watch any of the channels, but integration with MythTV is the next step.

Reading all the information on internet about doing, had gcc and igmpproxy source in hand I was ready, thinking this will be easy, how wrong I was.

I built igmpproxy and copied it over to my gateway, wrote up a config file, and started it in debug mode, immediately noted a few issues something about permission denied. This was pretty quickly resolved by adding a rule to allow all multicast traffic out:

iptables -I OUTPUT -d 224.0.0.0/4 -j ACCEPT

restart igmpproxy and things seem to be starting cleanly.

Good start, or so I thought. I walked through the configuration of the modem setting up a new VPC with the correct VCI and VPI settings. Opening up a couple of ssh sessions, I started tcpdump:

``Having solved a very interesting multicast issue at work recently I decided it was once again time to have a go at getting IPTV working from my ISP TPG.

I used to run Bering leaf, but never found a package or could be bothered building igmpproxy (which seemed to be the way to go) for leaf, and so have never really sat down and looked into getting IPTV working properly.

Having moved my primary gateway to Debian on a VM (I bridge the modem via dedicated NIC on the physical server and then a dedicated bridge at KVM level) about a year ago, I always had it in the back of my mind that I should sit down and actually work out how to get IPTV on to my network at home, not sure I will ever watch any of the channels, but integration with MythTV is the next step.

Reading all the information on internet about doing, had gcc and igmpproxy source in hand I was ready, thinking this will be easy, how wrong I was.

I built igmpproxy and copied it over to my gateway, wrote up a config file, and started it in debug mode, immediately noted a few issues something about permission denied. This was pretty quickly resolved by adding a rule to allow all multicast traffic out:

iptables -I OUTPUT -d 224.0.0.0/4 -j ACCEPT

restart igmpproxy and things seem to be starting cleanly.

Good start, or so I thought. I walked through the configuration of the modem setting up a new VPC with the correct VCI and VPI settings. Opening up a couple of ssh sessions, I started tcpdump:

``

I browsed to the TPG IPTV page, logged in and was greated with the vlc cone. Boo. Not a lot was happening. I could see my join requests in the tcpdumps, but no multicast traffic after that.

Looking at the debug output of igmpproxy, I could see that something was wrong with the address from which the multicast packets were originating from, it basically didn’t like it.

I read the configuration file, and realised I needed to set an altnet for the upstream interface.

Having done that, refreshed the web page, I was now greeted with a screed of multicast packets on one of my tcpdumps, hooray. But why did I not have any packets on the second interface.

Forwarding! I checked iptables FORWARD chain, but couldn’t see any packets hitting it. Packets were entering the mangle and nat PREROUTING chains, but were never getting to FORWARD.

rp_filter was my first thought. I turned that off on the interface where the packets were coming in. Still no luck.

I battled this for another night, before I finally found a post which said, you need to turn this off on the interface of the default route. WTF!?!

As soon as I turned rp_filter off on ppp0, the packets were now being forwarded. Hooray!

I had no idea that rp_filter worked like that, so you learn something new everyday.

Final configuration/changes:

```Having solved a very interesting multicast issue at work recently I decided it was once again time to have a go at getting IPTV working from my ISP TPG.

I used to run Bering leaf, but never found a package or could be bothered building igmpproxy (which seemed to be the way to go) for leaf, and so have never really sat down and looked into getting IPTV working properly.

Having moved my primary gateway to Debian on a VM (I bridge the modem via dedicated NIC on the physical server and then a dedicated bridge at KVM level) about a year ago, I always had it in the back of my mind that I should sit down and actually work out how to get IPTV on to my network at home, not sure I will ever watch any of the channels, but integration with MythTV is the next step.

Reading all the information on internet about doing, had gcc and igmpproxy source in hand I was ready, thinking this will be easy, how wrong I was.

I built igmpproxy and copied it over to my gateway, wrote up a config file, and started it in debug mode, immediately noted a few issues something about permission denied. This was pretty quickly resolved by adding a rule to allow all multicast traffic out:

iptables -I OUTPUT -d 224.0.0.0/4 -j ACCEPT

restart igmpproxy and things seem to be starting cleanly.

Good start, or so I thought. I walked through the configuration of the modem setting up a new VPC with the correct VCI and VPI settings. Opening up a couple of ssh sessions, I started tcpdump:

``Having solved a very interesting multicast issue at work recently I decided it was once again time to have a go at getting IPTV working from my ISP TPG.

I used to run Bering leaf, but never found a package or could be bothered building igmpproxy (which seemed to be the way to go) for leaf, and so have never really sat down and looked into getting IPTV working properly.

Having moved my primary gateway to Debian on a VM (I bridge the modem via dedicated NIC on the physical server and then a dedicated bridge at KVM level) about a year ago, I always had it in the back of my mind that I should sit down and actually work out how to get IPTV on to my network at home, not sure I will ever watch any of the channels, but integration with MythTV is the next step.

Reading all the information on internet about doing, had gcc and igmpproxy source in hand I was ready, thinking this will be easy, how wrong I was.

I built igmpproxy and copied it over to my gateway, wrote up a config file, and started it in debug mode, immediately noted a few issues something about permission denied. This was pretty quickly resolved by adding a rule to allow all multicast traffic out:

iptables -I OUTPUT -d 224.0.0.0/4 -j ACCEPT

restart igmpproxy and things seem to be starting cleanly.

Good start, or so I thought. I walked through the configuration of the modem setting up a new VPC with the correct VCI and VPI settings. Opening up a couple of ssh sessions, I started tcpdump:

``

I browsed to the TPG IPTV page, logged in and was greated with the vlc cone. Boo. Not a lot was happening. I could see my join requests in the tcpdumps, but no multicast traffic after that.

Looking at the debug output of igmpproxy, I could see that something was wrong with the address from which the multicast packets were originating from, it basically didn’t like it.

I read the configuration file, and realised I needed to set an altnet for the upstream interface.

Having done that, refreshed the web page, I was now greeted with a screed of multicast packets on one of my tcpdumps, hooray. But why did I not have any packets on the second interface.

Forwarding! I checked iptables FORWARD chain, but couldn’t see any packets hitting it. Packets were entering the mangle and nat PREROUTING chains, but were never getting to FORWARD.

rp_filter was my first thought. I turned that off on the interface where the packets were coming in. Still no luck.

I battled this for another night, before I finally found a post which said, you need to turn this off on the interface of the default route. WTF!?!

As soon as I turned rp_filter off on ppp0, the packets were now being forwarded. Hooray!

I had no idea that rp_filter worked like that, so you learn something new everyday.

Final configuration/changes:

```

© Greg Cockburn