# [solved] pppoe wows!

## gordonb3

I've tried just about everything, but I can't seem to get this working. When I start the PPPoE connection using `rc-config start net.ppp0`, most of the internet is unreachable. It looks like an MTU/MRU issue, but adding this to the net conf file doesn't change a thing. When starting the PPPoE connection with `pppoe-start` everything works like it should, but I don't really want to initialize this connection using a local.d script.

Can anyone hint what could be wrong? This is my last non-working config:

```
config_ppp0="ppp"

link_ppp0="eth0"

plugins_ppp0="pppoe"

username_ppp0="mac@myprovider"

password_ppp0="default password"

pppd_ppp0="

       maxfail 10

       noauth

       lcp-echo-interval 5

       lcp-echo-failure 12

       debug

       noipdefault

       defaultroute

       ipcp-accept-remote

       ipcp-accept-local

       holdoff 3

       noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp

       912600

       lock

       nocrtscts

       mru 1492

       mtu 1492

"

```

Last edited by gordonb3 on Wed Aug 05, 2015 12:17 pm; edited 1 time in total

----------

## Roman_Gruber

i used to use pptp in the past.

and for the config files you need to check what other linux / windows users use in their settings regarding your network provider. I assume you need it to get your connection to the internet right?

i never needed those in the past

       mru 1492

       mtu 1492 

off topic: the easiest way to see if the network is running and working is to start it by hand on every log in as user. Takes 2 seconds and you know instantly that it works and how it works. And I never had any issues in the past and I did that for years on every reboot by hand.

did you check your dns and route / gateway? 

ping 4.4.4.4 works?

ping google.com works?

----------

## NeddySeagoon

gordonb3,

I have

```
modules="iproute2"

config_eth2="null"

config_ppp0="ppp"

link_ppp0="eth2"

plugins_ppp0="pppoe"

pppd_ppp0="defaultroute"

dns_servers_ppp0="212.23.6.100

                  212.23.3.100"

username_ppp0='my username'

password_ppp0='sekrit password'
```

That gets me connected to my ISP over a BT wholesale VDSL link, using the BT provided 'modem' which is what I'm supposed to use.

The static nameservers are just a degree of paranoia on my part.  They are not public and will not work for you.

----------

## gordonb3

I should probably explain better. Some web pages I can access, others time out. As far as I can see there is no difference between the net.ppp0 configuration and the pppoe-start userland activation, yet with the latter I can access every page (including this one) and when using the other I'm very much restricted. It can't be a router issue, because then the pages that do work wouldn't as well, which is what got me to MTU/MRU. However, even with lower values there's still no response.

----------

## NeddySeagoon

gordonb3,

Ahh, the mtu setting of 1492 can be important.  Transmitting packets bigger than this using PPPoE will cause fragmentation.

The route mtu should be auto discovered and used but is it?

Test with 

```
ping -M do -s <packetsize> <target>
```

You will get an error when test packets cannot be sent over the route without fragmentation.

```
$ ping -M do -s 1466 google.com

PING google.com (216.58.209.238) 1466(1494) bytes of data.

From router (192.168.100.253): icmp_seq=1 Frag needed and DF set (mtu = 1492)
```

That's my router complaining.

Some sites don't like fragmented packets and its bad for both your latency and data rate.  You may need to set the mtu yourself and it might be lower than 1492

Read 

```
man ping
```

----------

## gordonb3

Got it. May try again tomorrow if I can afford the downtime. Must note though that the MTU/MRU settings were not in there when I started. I only added them when I discovered that several web pages were unreachable.

----------

## gordonb3

Doesn't work.

As it turns out, mtu 1492 and mru 1492 are in fact the values used when starting the pppoe connection using pppoe-start. Process listing shows something interesting though.

pppoe-start:

```
root     12939  0.5  0.4   2816  2064 pts/0    S    12:43   0:00 /bin/sh /usr/sbin/pppoe-connect /dev/fd/63

root     12954  0.2  0.3   2888  1944 ?        Ss   12:43   0:00 /usr/sbin/pppd pty /usr/sbin/pppoe -p /var/run/-pppoe.pid.pppoe -I eth0 -T 80 -U  -m 1412    noipdefault noauth default-asyncmap defaultroute hide-password nodetach mtu 1492 mru 1492 noaccomp nodeflate nopcomp novj novjccomp user xx-xx-xx-xx-xx-xx@provider lcp-echo-interval 20 lcp-echo-failure 3

nobody   12955  0.1  0.2   2000  1524 ?        S    12:43   0:00 /usr/sbin/pppoe -p /var/run/-pppoe.pid.pppoe -I eth0 -T 80 -U -m 1412

```

net.ppp0:

```
root     14316  0.0  0.3   2988  1872 ?        Ss   12:48   0:00 /usr/sbin/pppd plugin rp-pppoe.so unit 0 user xx-xx-xx-xx-xx-xx@provider remotename ppp0 linkname ppp0 plugin passwordfd.so noipdefault noauth default-asyncmap defaultroute hide-password noaccomp nodeflate nopcomp novj novjccomp lcp-echo-interval 20 lcp-echo-failure 3 debug mtu 1492 mru 1492 maxfail 10 ipcp-accept-remote ipcp-accept-local holdoff 3 noccp nobsdcomp passwordfd 0 defaultmetric 4005 persist connect true eth0

```

Also: I'm getting a warning that says "net.ppp0 has started, but is inactive". But again: I can reach some parts of the web at this point.

It seems these are in fact two completely different PPPoE implementations, the working one having ppp access an external pseudo tty script (increasing latency) and the non working version being a plugin that allows the ppp daemon to access the link directly.

----------

## gordonb3

Solved it!

Quite unexpectedly. The problem was not on my side, but is in fact caused by my ISP and firewalls on the servers that fail to respond (including this forum). The number 1412 in the parameter listing for the pseudo tty put me on track. Although the mtu is 1492, the actual message segment size is a lot smaller. Smaller even than the normal rule of thumb to subtract 40 indicates.

The solution is to add a firewall rule that enforces the use of the correct message segment size. A technique known as MSS-clamping.

```
iptables -I FORWARD 1 -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1412
```

I do still have the issue of the warning that net.ppp0 is inactive. Investigating the logs this message is being returned while the link is still being initialized. Is there a way to let the net script wait longer for the link to be established?

----------

