Netflix and pppd

Netflix and pppd

[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.

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]

Re: Netflix and pppd

[James Carlson]

On 12/6/2015 11:27 AM, Yan Seiner wrote:
> 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.)

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Netflix and pppd

[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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: Netflix and pppd

[Yan Seiner]

On 12/6/2015 11:05 PM, Michael Richardson wrote:
> 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

>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>

Re: Netflix and pppd

[Michael Richardson]

Yan Seiner <yan@seiner.com> wrote:
    >> 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  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [