Netflix and pppd
I've been chasing a weird issue with Netflix and pppd. Basically, the Netflix apps in my Roku and Samsung TV will not play reliably when using pppoe. Using tcpdump I can see packets flow, but the app will either stop at 25% or 99% and eventually time out with the "We're having trouble playing this title right now".
If I set up my modem to handle the pppoe connection and do double NAT, it works fine. The problem only comes up when I set up the modem to act as a dumb modem and use pppd to complete the connection. The problem only happens when I am running pppd to set up the connection.
Netflix through a browser works fine.
I am running pppd 2.4.7.
Here's what I've done:
Enabled icmp fully (I don't block any icmp messges) Enabled arp by default
Set up the TV and the Roku to use google DNS instead of dnsmasq DNS forwarding
Set up dnsmasq to tell dhcp clients to use a shorter packet length Disabled QOS
Disabled dns-rebind protection.
Snippet of tcpdump when the whirlygig is stuck at 99%
07:42:47.464150 IP samsungtv.lan.41108 > ipv4_1.lagg0.c023.iad001.ix.nflxvideo.net.www: Flags [.], ack 174241, win 6200, options [nop,nop,TS val 229009 ecr 175479014], length 0 07:42:47.464577 IP ipv4_1.lagg0.c023.iad001.ix.nflxvideo.net.www > samsungtv.lan.41108: Flags [.], seq 174241:175681, ack 286, win 2050, options [nop,nop,TS val 175479056 ecr 228993], length 1440 07:42:47.466836 IP ipv4_1.lagg0.c023.iad001.ix.nflxvideo.net.www > samsungtv.lan.41108: Flags [.], seq 175681:177121, ack 286, win 2050, options [nop,nop,TS val 175479056 ecr 228993], length 1440 07:42:47.468982 IP ipv4_1.lagg0.c023.iad001.ix.nflxvideo.net.www > samsungtv.lan.41108: Flags [.], seq 177121:178561, ack 286, win 2050, options [nop,nop,TS val 175479056 ecr 228993], length 1440 07:42:47.471442 IP ipv4_1.lagg0.c023.iad001.ix.nflxvideo.net.www > samsungtv.lan.41108: Flags [.], seq 178561:180001, ack 286, win 2050, options [nop,nop,TS val 175479056 ecr 228993], length 1440 07:42:47.505174 IP samsungtv.lan.41108 > ipv4_1.lagg0.c023.iad001.ix.nflxvideo.net.www: Flags [.], ack 180001, win 5320, options [nop,nop,TS val 229020 ecr 175479056]
Quoted 10 lines · Yan Seiner
I've been chasing a weird issue with Netflix and pppd. Basically, the Netflix apps in my Roku and Samsung TV will not play reliably when using pppoe. Using tcpdump I can see packets flow, but the app will either stop at 25% or 99% and eventually time out with the "We're having trouble playing this title right now".
If I set up my modem to handle the pppoe connection and do double NAT, it works fine. The problem only comes up when I set up the modem to act as a dumb modem and use pppd to complete the connection. The problem only happens when I am running pppd to set up the connection.
Based on the terms you're using, I'm guessing that the hardware configuration looks like this:
<--wan--> "modem" <--lan1--> Linux <--lan2--> Samsung/Roku
(Is this correct? Is there a Linux box in here or something else? Are there other devices involved?)
In the working case, the "modem" device is configured to terminate PPPoE, PPP, and to provide NAT functionality, and the Linux device separately also provides NAT functionality. So, native TCP/IP is seen on both lan1 and lan2. In the non-working case, the raw PPPoE frames are passed on lan1, and the Linux box is configured for NAT.
Is this much right?
At a guess, it sounds like the "modem" is doing a better job of dealing with the unbelievable horror show that is PPPoE and NAT, and when the Linux box steps into that role, it isn't well-configured by default to deal with it.
What I cannot tell is what you may have tried to do to get this to work.
Have you read through this documentation?
http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/mtu-issues.html
http://lartc.org/howto/lartc.cookbook.mtu-mss.html
http://unix.stackexchange.com/questions/56308/problem-with-path-mtu-discovery-over-pppd
In short, I'm not seeing what this problem has to do with PPP itself -- in most cases, PPP just negotiates link parameters and then steps out of the way -- or the details of the problem you're encountering or what you might have already tried to do to solve the problem.
(Sure, it's possible there's a PPP problem buried in here somewhere. Based on the data provided so far, though, I just don't see it.)
Signature · 1 line
James Carlson 42.703N 71.076W <[email protected]>
Yes, like James, I'd say that your problem is MTU issues with the PPPoE. Aside from the usual mss-clamping solution, you could also lower the MTU on the "lan2" to 1460 or so.
DHCP should tell the other boxes about that, and things may work better.
--
] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
Quoted 4 lines · Michael Richardson
Yes, like James, I'd say that your problem is MTU issues with the PPPoE. Aside from the usual mss-clamping solution, you could also lower the MTU on the "lan2" to 1460 or so.
DHCP should tell the other boxes about that, and things may work better.
Yes, I am forcing the MTU to 1464 via DHCP. However, I tried adding this:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
to my iptables script and that seems to have cured the problem, at least for this morning. Thanks for the nudge.
--Yan
Quoted 6 lines
--
] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
Quoted 6 lines · Yan Seiner
Quoted 4 lines
Yes, like James, I'd say that your problem is MTU issues with the PPPoE. Aside from the usual mss-clamping solution, you could also lower the MTU on the "lan2" to 1460 or so.
DHCP should tell the other boxes about that, and things may work better.Yes, I am forcing the MTU to 1464 via DHCP. However, I tried adding this:
That ought to force the devices to adverise a smaller MSS, which you could investigate in the TCP SYN packets that they send. They might have hard coded 1500, though. (which would be wrong)
--
] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [