# Kernel PPPoE vs RP-PPPOE

## bigfunkymo

I am using a pppoe DSL provider and I have moved from roaring penguin to the kernel-mode pppoe.  Everything is working well except some websites just stall as they are loading.  I know that RP-PPPoE does a bit of packet mangling because of MTU and MSS limitations and the do not fragment flag. 

The firewall I use, MonMotha's, has an option called BRAINDEAD_ISP that when set to TRUE activates the MSS clamping via the following command line:

```

iptables -t filter -A INETOUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

```

Before enabling this option, I had trouble getting to www.securityfocus.com but now it works fine as it did with rp-pppoe.

My new problem is http://camelotvault.ign.com will work when I connect with roaring penguin but not when i connect with kernel mode pppoe.  MSS clamping with iptables doesnt solve the problem and I don't know what else RP PPPoE does that allows me to connect to that website.

What am I missing here?

----------

## bigfunkymo

Beuller?

Beuller?

----------

## AlterEgo

I have the same experience. 

rp-pppoe: fine

kernel mode pppoe: I had to use the braindead_isp trick, and I had to also lower my mtu:  (/sbin/)ifconfig ppp0 mtu 1452 in order to make everything work OK.

I did not notice any change in performance or processor usage between the two methods, so I went back to the ease of use of the roaring penguin   :Very Happy: 

regards to Les!

----------

## nielchiano

can you tell me HOW you did the switch to kernel-mode? I'd like to get kernel-mode working too...

any links/howtos/...?

thx!

----------

## AlterEgo

Thanks for stealing my old sig; I stole it from someone from SlashDot   :Wink: 

This thread is basically what I used for setting up kernel-mode pppoe.

The config files are tricky: these are mine, so check carefully what you really need:

Select all PPP networking modules in de kernel config. 

Emerge ppp.

Edit /etc/conf.d/net.ppp0:

```

PEER="[i]Wanadoo[/i]"            # Define peer (aka ISP)

DEBUG="no"                # Turn on debugging

PERSIST="no"              # Redial after being dropped

ONDEMAND="no"             # Only bring the interface up on demand?

MODEMPORT="[i]eth1[/i]"          # TTY device modem is connected to

LINESPEED=""              # Speed pppd should try to connect at

INITSTRING=""             # Extra init string for the modem

DEFROUTE="yes"            # Must pppd set the default route?

HARDFLOWCTL="no"          # Use hardware flow control?

ESCAPECHARS="no"          # Use escape caracters ?

PPPOPTIONS=""             # Extra options for pppd

USERNAME=""               # The PAP/CHAP username

PASSWORD=""              

NUMBER=""                

REMIP=""                        

NETMASK=""                      

IPADDR=""                    

# MRU="768"                      

# MTU="768"                      

RETRYTIMEOUT="60"          # PERSIST="yes"

IDLETIMEOUT="60000"        # Idle timeout for when ONDEMAND="yes"

PEERDNS="yes"              # Should pppd set the peer dns?

AUTOCFGFILES="no"

# Directory where the templates is stored

TEMPLATEDIR=/etc/ppp

```

/etc/ppp/options:

```

lock

mtu 1462

mru 1462

noauth

persist

maxfail 0

defaultroute

name "[i]c7246xxx@wanadoo[/i]"  # that is my account name!

plugin pppoe.so

```

/etc/ppp/pap-secrets:

```

# Secrets for authentication using PAP

# client   server   secret         IP addresses

"[i]c7246xxx@wanadoo[/i]"   *   "<password>l"

```

(opt) Touch /etc/ppp/peers/Wanadoo (same name as "peer" in /etc/init.d/net.ppp0).

Add to  /etc/init.d/net.ppp0 (top):

depend() { 

    need net.eth1 

} 

(this eth-connection shold be "up" ).

Start: /etc/init.d/net.ppp0 start 

or rc-update....

Or without the script: pppd eth1.

Firewall-rules to avoid  transmission problems:

modprobe ipt-tcpmss en ipt_TCPMSS

add to firewall-script: 

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS clamp-mss-to-pmtu

Or:  braindead ISP="TRUE" in Monmotha's script.

----------

## bludger

This looks good, but I don't know why you set the mtu and mru to 1462 instead of 1492.  Of course 1462 should work as well, but is a bit of a waste.

----------

## AlterEgo

 *bludger wrote:*   

> This looks good, but I don't know why you set the mtu and mru to 1462 instead of 1492.  Of course 1462 should work as well, but is a bit of a waste.

 

You're right.

But I noticed some sites just were not reachable using 1492.

Don't know why.

----------

## nielchiano

hmm an idea: you might be mixing some things up...

on a PPPoE connection you can send an ehternet packet, maximal PAYLOAD-size of 1500B.

If it's ethernet, native, that's it, you put an IP header in it (20B), take an ICMP header (8B, i think) and that leaves you 1472B for your ping-packet.

If it's a PPPoE, you lose an additional 8B for a PPP-header (inserted betweet ethernet and IP). This leaves 1492B of payload at layer2, but reduces your ping-size to 1464B

Don't know if it's the case, but the numbers seem to...

----------

## bludger

 *AlterEgo wrote:*   

>  *bludger wrote:*   This looks good, but I don't know why you set the mtu and mru to 1462 instead of 1492.  Of course 1462 should work as well, but is a bit of a waste. 
> 
> You're right.
> 
> But I noticed some sites just were not reachable using 1492.
> ...

 

I have been using kernel mode pppoe with mru and mtu set to 1492 for a couple of years now and have had no problems.

----------

## nielchiano

 *bludger wrote:*   

> I have been using kernel mode pppoe with mru and mtu set to 1492 for a couple of years now and have had no problems.

 

me too... except for the "couple of years" part

----------

## bludger

 *nielchiano wrote:*   

>  *bludger wrote:*   I have been using kernel mode pppoe with mru and mtu set to 1492 for a couple of years now and have had no problems. 
> 
> me too... except for the "couple of years" part

 

Well, it has been the standard setup with SuSE for a long time.  I would like to see it cleaned up with gentoo as well, as I think it is preferable to using user mode.

----------

## nielchiano

it makes no sense to keep it in user mode... first ask the kernel to encapsulate everything, then undo part of it, and send it...

it's like translating a text from english to russian, and back to french... instead of doing it in one pass... Also, the kernel is way faster doing this

----------

## AlterEgo

 *nielchiano wrote:*   

> ... Also, the kernel is way faster doing this

 

prove it   :Cool: 

I noticed no speed/ping/CPU usage difference between kernel-pppoe en rp-pppoe on a 1 Mbit line.

----------

## nielchiano

 *AlterEgo wrote:*   

> prove it  
> 
> I noticed no speed/ping/CPU usage difference between kernel-pppoe en rp-pppoe on a 1 Mbit line.

 

I don't know if there is a NOTICABLE impact.

kernel mode:  traffic --> PPPoE

user mode: traffic --> PPP --> PPPoE

You can see that the latter CAN'T be faster then the kernel mode, since it involves 2 translations.

About the "faster", it's not realy true... it's in the sense of latency, not bandwith... the kernel KNOWS if a packets is sent; the user-program should check every now and then; so the kernel will ALWAYS respond faster.

The speed of the translation will be approx equal.

----------

## Gentree

 *Quote:*   

> You can see that the latter CAN'T be faster then the kernel mode, since it involves 2 translations.

 

Without going into the technical details  thoroughly statements like that are meaningless. Life aint that simple.

I doubt any translation arguements will be a determining factor where an external network is concerned.

Anyway , IMHO , pppoe and the like are just not jobs for the kernel. The kernel should run the system, the hardware but (eg the NIC) but not the network. Next you put the GUI into the kernel as well and you end up with windows.

One main thing I like about Linux is the clear separation of tasks.

That's my 2 cts d'euros - which is currently worth more someoneelse's 2 cents worth - so I'm sticking with it.

 :Cool: 

----------

## Stephen Butler

 *Gentree wrote:*   

>  *Quote:*   You can see that the latter CAN'T be faster then the kernel mode, since it involves 2 translations. 
> 
> Without going into the technical details  thoroughly statements like that are meaningless. Life aint that simple.
> 
> I doubt any translation arguements will be a determining factor where an external network is concerned.

 

It all depends on your situation. For example, I'm looking to run this on my firewall, which is an old 486 I've had since about '95 or '96.  In this case, avoiding the context switches associated with running pppoe in userland is very desirable.

Take for example one of the venerable server operating systems: NetWare. You don't talk about "programs" on NetWare, you talk about modules, because every "program" is loaded into the same address space as the OS! Although there are several reasons for doing this, one of them is that it is simply faster. I think putting things like pppoe and iptables (is there even a userland iptables?) in the kernel for a firewall makes perfect sense.

 *Quote:*   

> Anyway , IMHO , pppoe and the like are just not jobs for the kernel. The kernel should run the system, the hardware but (eg the NIC) but not the network. Next you put the GUI into the kernel as well and you end up with windows.

 

Again, it all depends on your application. For a graphics workstation, or a realtime video editing server, placing parts of the graphic subsystem in the kernel makes perfect sense. Although the details are scarce, it wouldn't surprise me to see parts of Apple's new CoreImage implemented as a kext, especially since Apple would like to maintain their reputation as a low latency video platform.

----------

