[PPPoE] Kernel-mode: MTU wordt genegeerd

[Arnout]

Ik wil graag m'n PPPoE verbinding verbeteren door gebruik te gaan maken van PPPoE | kernel mode. Tot nu toe maak ik gebruik van user-space pppd + pppoe.

In de kernel de bijbehorde optie aangezet.
Van samba.org de 2.4.2b3 versie van pppd gedownload (deze ondersteund standaard pppoe kernel mode zonder patch).
Gecompiled, en over de oude pppd heengezet (pppoe executable komt te vervallen).

/etc/ppp/options:

code:

lock 
mtu 1462
mru 1462
noauth
persist
maxfail 0
defaultroute
name "c73706xx@wanadoo"
plugin pppoe.so

Maakt keurig verbinding, dus ik blij. Totdat ik na een paar dagen erachter kom dat asus.com.tw wel heel lang down is, en ik met lynx op de server gewoon op die site kan komen. Zo ook met t-mobile en smartftp.com. Deze sites zijn onbereikbaar.

Nu ging er bij mij direct al een lampje branden bij de combo "pppoe" en "bepaalde sites niet bereikbaar".

Nader onderzoek geeft aan dat dit met de MTU "onderhandeling" te maken heeft. TCPdump geeft idd aan dat deze sites niet goed reageren omdat de mtu te hoog is.
Terwijl ik in options wel de juiste MTU aangeef (voor casema is het max 1464, maar 1462 is altijd safe). Ping met de No Fragment flag gaat tot 1464bytes.

Hij lijkt dus de MTU waarde te negeren bij kernel mode pppoe. Bij user-space pppoe gaat het wel goed, hierbij geef ik CLAMPMSS de waarde 1452 (maximaal wat mogelijk is).

Ik heb ook nog een 2.4.1 source gepatched met de pppoe patch, maar dit geeft zelfde resultaat. Wel verbinding, maar bepaalde sites no reponse.

In beide gevallen geeft ifconfig een MTU aan van 1492, dit is op zich niet fout.
De CLAMPMSS optie voegt een -m parameter aan pppoe toe (user-space), dit houdt in dat pppoe actief kijkt naar MTU "onderhandelingen" en dit verlaagt tot 1452.

Wie heeft dit werkend? ('t is een Wanadoo Cable Premium verbinding met COM21 modem).

[Verwijderd]

mtu heeft niet zoveel zin om aan te klooieen kan beter tcp windowsize vergroten.

[balk]

ik heb toevallig een vergelijkbaar probleem, maar dan TUDelft PPPoE. www.sony.nl is bijvoorbeeld niet bereikbaar, evenals https://www.abnamro.nl/
Ik was ook al aan het klooien met kernel-mode pppoe

MrWeedy, zou je iets beter willen beschrijven wat je bedoelt met je tip?

[Verwijderd]

Dit hele verhaal blijkt een grote berg onzin te zijn. Mijn excuses daarvoor.

offtopic:
Ik had _precies_ hetzelfde probleem. Ik was er zelf al achter dat het met MTU te maken had maar heb Casema gebeld voor de precieze details.

Ze gaven mij instructies om de MTU in windows op "laag" te zetten. Na wat zoekwerk bleek dit de waarde 576 te zijn. Deze op mijn server + al mijn clients ingesteld (win2000, winXP, win98, linux (familie vindt linux toch niet zo fijn )) en TADA! het werkte.

Ik weet er verder technisch gezien weinig vanaf maar je zou het eens kunnen proberen. Aangezien het op allemaal verschillende OS'en werkt vermoed ik dat dit toch een algemeen werkende waarde is.

Abbo: Casema basic(?)( het standdaard abbo iig) met COM21 (Motorola).

Er zijn mensen die beweren dat zo'n lage waarde een negatief effect heeft op de snelheid maar indertijd heb ik eens wat dieper gezocht en bleek dit effect minimaal of in zijn geheel niet aanwezig (links zou ik echt niet meer weten).

Liever 1% minder performance dan 5% niet werkende sites! Sites die bij mij niet werkte waren oa: www.informatique.nl, www.sony.nl, www.google.com (soms, heel vreemd maar heeeel lastig) enzovoorts.

Succes.

[ Voor 6% gewijzigd door Verwijderd op 08-10-2003 20:18 ]

[balk]

Skin: zo'n lage waarde had ik nog niet geprobeerd, maar dat werkt wel! Ik kan echter niet mijn eth devices veranderen want dan klapt ppp eruit

Nu nog even ontdekken hoe ik standaard bij ppp de MTU's lager kan zetten. Maar dat is van minder belang
[update]
en ook dat is gelukt, beetje init scripts hacken.
* balk kan met een gerust hart gaan slapen

[ Voor 21% gewijzigd door balk op 08-10-2003 00:10 ]

[Arnout]

Verwijderd schreef op 07 oktober 2003 @ 23:34:
mtu heeft niet zoveel zin om aan te klooieen kan beter tcp windowsize vergroten.

MTU-waarde is juist essentieel bij PPPoE.

Verwijderd schreef op 07 October 2003 @ 23:56:
Ze gaven mij instructies om de MTU in windows op "laag" te zetten. Na wat zoekwerk bleek dit de waarde 576 te zijn. Deze op mijn server + al mijn clients ingesteld (win2000, winXP, win98, linux (familie vindt linux toch niet zo fijn )) en TADA! het werkte.

Windows?
Ik heb hier een linux nat-gateway die:
- perfect werkt met user-space pppoe
- niet goed werkt met kernel-mode pppoe

Dus het probleem speelt zich af op de server, het lijkt me niet de bedoeling aan client te gaan sleutelen, en dat wil ik eigenlijk vermijden.

Abbo: Casema basic(?)( het standdaard abbo iig) met COM21 (Motorola).

COM21 en Motorola? Je hebt of een COM21 of een Motorola. Motorola = L2TP, dus geen PPPoE. Plaatje van de modem die ik heb: plaatje

balk schreef op 08 October 2003 @ 00:07:
Nu nog even ontdekken hoe ik standaard bij ppp de MTU's lager kan zetten. Maar dat is van minder belang :)[/ME]

Options file misschien?

Ik start ppp dus zo:

pppd eth1
waarbij hij de instellingen uit options haalt.

Allemaal bedankt voor jullie antwoord, ik wacht nog even op iemand die pppoe in kernel mode heeft draaien met de juiste MTU.
Ik ben niet de enige: http://www.voy.com/41165/2588.html

[AlterEgo]

Misschien snap ik het niet helemaal.
Ik gebruik rp-pppoe om verbinding te maken, maar dat maalt verder niet uit.
direct nadat je verbinding gemaakt hebt, kan ik mijn mtu automagisch aanpassen door "ifcondig ppp0 mtu 1452" in /etc/ppp/ip-up te zetten.
Resultaat bereikt, toch

[balk]

MetHod schreef op 08 October 2003 @ 10:01:
Options file misschien?

Ik start ppp dus zo:

pppd eth1
waarbij hij de instellingen uit options haalt.

Allemaal bedankt voor jullie antwoord, ik wacht nog even op iemand die pppoe in kernel mode heeft draaien met de juiste MTU.
Ik ben niet de enige: http://www.voy.com/41165/2588.html

bij mij draait ie in kernel mode (scheelt heel veel CPU kracht). Ik start pppoe via een init script, maar dan pakt ie niet de mtu instellingen van /etc/ppp/pppoe.conf
een regeltje 'ifconfig ppp0 mtu 576' na het starten van pppd en alles werkt als een zonnetje.

AlterEgo schreef op 08 October 2003 @ 10:59:
Misschien snap ik het niet helemaal.
Ik gebruik rp-pppoe om verbinding te maken, maar dat maalt verder niet uit.
direct nadat je verbinding gemaakt hebt, kan ik mijn mtu automagisch aanpassen door "ifcondig ppp0 mtu 1452" in /etc/ppp/ip-up te zetten.
Resultaat bereikt, toch

precies!

[ Voor 24% gewijzigd door balk op 08-10-2003 13:25 ]

[Arnout]

Ok, ik ga de oplossing van AlterEgo proberen, mahja, dan blijft 't wel vaag waarom hij dat niet direct vanuit de options file doet (of via de pppd invocatie).

[AlterEgo]

Balk, of iemand anders: wat zijn volgens jullie de voordelen van kernel-mode pppoe boven userspace (roaring penguin)?

CPU? rp-pppoe heeft niet veel nodig, het komt in de buurt van nul:

code:

 %CPU %MEM          TIME COMMAND
  0.0  0.1           0:00 /bin/sh /usr/sbin/adsl-connect
  0.0  0.1           0:00 /usr/sbin/pppd pty /usr/sbin/pppoe -p /var/
  0.2  0.0           0:11 /usr/sbin/pppoe -p /var/run/pppoe.conf-adsl

Andere argumenten?

[ Voor 15% gewijzigd door AlterEgo op 08-10-2003 14:35 . Reden: layout fix0red ]

[Arnout]

AlterEgo schreef op 08 oktober 2003 @ 14:33:
Balk, of iemand anders: wat zijn volgens jullie de voordelen van kernel-mode pppoe boven userspace (roaring penguin)?

Bij volledige link belasting vreet pppoe wel degelijk veel processor kracht. Ikzelf heb een AMD K6-400 en deze gaat al gauw richting 10% voor pppoe bij 100kb/s. Vooral als je peer-to-peer programma's gebruikt welke veel kleine paketten versturen wil het wel oplopen.

Verder kwam ik deze interessante test tegen: http://www.jraitala.net/comp/articles/2002/pppoe/

Point-to-Point Protocol over Ethernet (PPPoE) is used by many Internet Service Providers (ISP) because it eases the administration on the server side. However, on the client side it can be a pain because PPPoE adds to CPU overhead if a userland implementation is used and not many operating systems support kernel-side PPPoE.

Dit wekte mijn interesse voor kernel mode pppoe.

[ Voor 24% gewijzigd door Arnout op 09-10-2003 08:22 ]

[balk]

Als ik rp-pppoe gebruik kom ik niet boven de 1.2 MB/s, met kernel mode toch al gauw 5 MB/s. Als ik een snellere server had gehad had het nog sneller gekund. Als je 100 mbit wil verstoken over rp-pppoe moet je toch al gauw richting een 1GHz machine terwijl met kernel mode die eis lager is. Ik heb een p233 als servertje staan.

[Arnout]

Niks ten nadele van jullie, maar ik was niet helemaal zeker dat dit de juiste oplossing was (het "hard" aanpassen van de MTU van de PPPoE interface). Dit kan voor de lokale machine misschien wel helpen, maar die werkte toch al goed, het ging bij mij om de GeNATte machines (iptables dus). Omdat het een verbinding betreft die ook door anderen gebruikt wordt had ik nog geen mogelijkheid gehad om te gaan testen.

Ik ben verder gaan zoeken naar de kern van dit probleem.

Grafisch weergegeven is dit exact het probleem:


bron

Om dit probleem op te lossen dient de PPPoE gateway actief naar "onderhandelingen" te kijken wat betreft de MTU waarde, en zo nodig aan te passen. Dit monitoren en corrigeren wordt ingeschakeld met de optie "enable tcpmssfixup".

As of December 2000, ppp now understands the option tcpmssfixup which implements what tcpmssd does below. This version of ppp is included in FreeBSD >= 4.3. This feature is enabled by default, but you can still add it anyway:

enable tcpmssfixup

Helaas, dit werkt alleen voor FreeBSD, niet voor Linux (tenminste, niet kernel-mode).

Verder zoeken leverde de oplossing:

On Tue, 22 Jan 2002, Dan Langille wrote:

> After reading
> http://www.daemonnews.org/200101/pppoe.html#pmtu, I discovered that ppp
> has an option tcpmssfixup which implements what tcpmssd does.

Note: For Linux users out there, this is a FreeBSD-specific option,
and will not work on Linux. On Linux 2.4, you need the tcpmss
iptables module if you are using kernel-mode PPPoE, or the "-m" option
to rp-pppoe if you are not.

--
David.

Het is dus een kwestie van een iptables module toevoegen...

Kernel 2.4.22:

CONFIG_IP_NF_MATCH_TCPMSS:

This option adds a `tcpmss' match, which allows you to examine the MSS value of TCP SYN packets, which control the maximum packet size for that connection.

en:

CONFIG_IP_NF_TARGET_TCPMSS:

This option adds a `TCPMSS' target, which allows you to alter the
MSS value of TCP SYN packets, to control the maximum size for that
connection (usually limiting it to your outgoing interface's MTU
minus 40).

This is used to overcome criminally braindead ISPs or servers which
block ICMP Fragmentation Needed packets. The symptoms of this
problem are that everything works fine from your Linux
firewall/router, but machines behind it can never exchange large
packets:
1) Web browsers connect, then hang with no data received.
2) Small mail works fine, but large emails hang.
3) ssh works fine, but scp hangs after initial handshaking.

Workaround: activate this option and add a rule to your firewall
configuration like:

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

Check! dat klinkt als DE oplossing...

_{Raar alleen dat hier ZO weinig over bekend is, op een gegeven moment had ik maar één hit bij google...}

[AlterEgo]

Ik ben dus maar gaan spelen met kernelmode pppoe.
En inderdaad: het "voelt" sneller; meetbaar is het niet echt op een dikke computer en met Wanadoo kabel Maar P2P software en ander spul met veel connecties gebruiken minder CPU.

Het heeft ook de al genoemde nadelen:
Ipt-tcpmss is niet De oplossing, maar het scheelt wel.
Het semi-handmatig aanpassen van de mtu scheelt ook, maar nog steeds heb ik (enkele) sites gevonden die het niet lekker doen tenzij je de mtu echt heel laag zet.
En het is alles bij elkaar best een hoop geconfigureer

Best-of both worlds: rp-pppoe met kernel-mode pppoe ondersteuning:
Installeer ppp-cvs ( http://www.samba.org/samba/cvs.html ) (de 2.4.2-beta weigerde).
cvs -d :pserver:[e-mail]:/cvsroot login (password:cvs)
cvs -z5 -d :pserver:[e-mail]:/cvsroot co ppp
en compileren maar.
Vervolgens rp-pppoe opnieuw compileren, en in /etc/ppp/pppoe.conf aangeven:
LINUX_PLUGIN=/etc/ppp/plugins/rp-pppoe.so
/etc/ppp/plugins/rp-pppoe.so is een symlink naar /usr/lib/pppd/2.4.2b3/rp-pppoe.so
/usr/lib/pppd/2.4.2b3/pppoe.so is ook een te maken symlink naar /usr/lib/pppd/2.4.2b3/rp-pppoe.so (dit lijkt me een cvs-foutje (?).
adsl-start
en totnutoe ben ik er tevreden mee: prima snelheid en nauwelijk overhead.

[Arnout]

Ok, inmiddels getest en m'n beschreven oplossing werkt.

Omdat een alternatief op AlterEgo's HOWTO nooit weg is bij deze mijn setup:
1. in kernel de opties CONFIG_IP_NF_MATCH_TCPMSS en CONFIG_IP_NF_TARGET_TCPMSS aanzetten (en natuurlijk alle ppp opties behalve multilink en vooral PPPoE).
2. download de cvs of de 2.4.2b3 source van samba.org (allebei hebben PPPoE support)
3. configure, make, make install
4. in pap-secrets je username en wachtwoord voor de PPPoE verbinding
5. in options minimaal je username, noauth en plugin rp-pppoe.so
6. in je firewall opnemen: iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu (om de hierboven beschreven shit te voorkomen).
7. start ppp: pppd eth1 (of maak even een mooi init.d script)

En voilà: casema/wanadoo pppoe kernel mode zonder problemen en razendsnel.

Nu Casema zo lang mogelijk buiten de deur houden met hun motorola modems!

[AlterEgo]

Method, kun jij de volgende URL bereiken met kernel-mode alleen?
http://www.aex.nl/veilig/...oorkeur%2Easp%3Ftaal%3Dnl

[Arnout]

AlterEgo schreef op 09 October 2003 @ 20:40:
Method, kun jij de volgende URL bereiken met kernel-mode alleen?
http://www.aex.nl/veilig/...oorkeur%2Easp%3Ftaal%3Dnl

Ja, die kan ik bereiken. Heb net even uitgebreid zitten testen; alle sites die problemen gaven (o.a. t-mobile.nl, smartftp.com en asus.com.tw) doen het nu goed.

Hier de tcpdump van het verkeer tussen www.aex.nl en de server (ppp0).

[AlterEgo]

Thanks MetHod.

Ik had de braindead ISP rule toegevoegd aan mijn firewall script, maar daar stond al zoiets, en dat conflicteerde Alles werkt nu.