[SOLVED] Multicast & mythtv tuning issues with kernel>2.6.30

Phoenix84 · n00b Joined: 29 May 2010 Posts: 5

I've been using Gentoo for many years, but I recently set up a new machine as a mythtv box. I originally set it up with kernel 2.6.29. I have an Hauppauge PVR 1600 (which I don't use anymore), and I have second NIC for my IPTV service. It seems something changed in the kernel configuration between 2.6.30 and 2.6.31, because I can no longer tune ANY capture card in mythtv after upgrading.
I originally saw this issue when 2.6.31 first came out, but though it was a regression or some odd configuration with my capture card, so I ignored it. However now I have my IPTV service (using multicast) and the EXACT same issue appears as the dvb card. I've been searching and fighting this issue for almost 6 months, and have gotten nowhere. This has also happens with kernel .32, .33, .34 and mythtv .21, .22, .23.

The steps I take to upgrade my kernel are as follows:
copy .config from currently running kernel into new directory
run make menuconfig (I've also tried running make oldconfig first)
verify various drivers are still available (multimedia tree changed between those version, so I have to reselect my V4L drivers for my PVR1600).
Rebuild and reboot

About the multicasting:
I successfully followed the mythtv wiki entry for the IPTV service I use, and it works perfectly under 2.6.30. I can test by using mplayer on the multicast address and can watch the stream from there. However when I go ANY kernel > 2.6.30, I get the following error:

Hu · Administrator Joined: 06 Mar 2007 Posts: 23082

Phoenix84 · n00b Joined: 29 May 2010 Posts: 5

Thanks for replying.

Hu · Administrator Joined: 06 Mar 2007 Posts: 23082

For small configuration bits (<= 30 lines), you can post it here in a [code] block. For large postings, such as .config files or build logs, post them to a pastebin and provide a link here. For the .config, please post a comment-stripped version. You can remove comments using grep -e '^[^#]' .config.

Phoenix84 · n00b Joined: 29 May 2010 Posts: 5

Thanks!

I've uploaded the .config for the kernel 2.6.30 I'm running that works: http://pastebin.com/tzY8MSi3

I've also included the .config for 2.6.31 that doesn't work: http://pastebin.com/0AmkfAbF

I also included diff of the two configs (just to be thorough): http://pastebin.com/njG5AF7g

Mostly, things were added to the new kernel, and only a handful were removed:
CONFIG_UNEVICTABLE_LRU
CONFIG_DMAR_GFX_WA
CONFIG_COMPAT_NET_DEV_OPS

Other options look like they were either renamed, or disabled in my config during the upgrade:
CONFIG_STACKTRACE
CONFIG_NOP_TRACER
CONFIG_RING_BUFFER
CONFIG_TRACING
CONFIG_BLK_DEV_IO_TRACE
CONFIG_BINARY_PRINTF

Here's the successful tcpdump (IP's masked to protect the innocent

):

Hu · Administrator Joined: 06 Mar 2007 Posts: 23082

None of that looks suspicious. I would expect that multicast IPTV would not require any kernel video support, since applications could receive the traffic directly off the network. The only remaining problem I can think of is that you built some key component as a module and 2.6.30 happens to load it, but 2.6.31+ happen not to load it. Check the lsmod output of each kernel to see if there is a difference in what modules are loaded.

Phoenix84 · n00b Joined: 29 May 2010 Posts: 5

Phoenix84 · n00b Joined: 29 May 2010 Posts: 5

Found it!
It actually was the rp_filter setting. In 2.6.31, rp_filter calculation code was changed, see: http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-09/msg04929.html

Anyway, I originally had in my /etc/conf.d/local.start:
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter

I guess that wasn't good enough, so I instead put those in /etc/sysctl.conf (better place anyway), and put this in local.start instead:
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter

And now everything works!

Thanks for your help!

Hu · Administrator Joined: 06 Mar 2007 Posts: 23082

Good to see that you found a solution. You might be able to use loose filtering instead of strict filtering, to get some of the benefit without breaking the stream entirely. However, although disabling rp_filter is sometimes necessary for asymmetric routing, since you appear to be using symmetric routing, it seems likely that the problem here is that your routes are set incorrectly. Disabling the filter allows it to work since you do not need to send anything, so you do not notice that the kernel is routing traffic out the wrong interface. As mentioned in the thread you referenced, the 2.6.30 kernel mishandled the rp_filter, so the routes have probably been wrong for a very long time and you never noticed until 2.6.31 fixed the check.