Diskussion:PPP over Ethernet

Zur Entwicklung von PPPoE kam es, weil die Provider den Kunden auch zeitbasierte Tarifmodelle anbieten wollten, obwohl DSL ja technisch eine Standleitung ist. Auch basierte die gesamte Abrechnungsstruktur der ISPs bis dahin auf PPP und RADIUS-Servern, die man natürlich nicht wegwerfen oder sonstwie großartig ändern wollte. Ganz nebenbei haben die meisten ISPs nicht so viele IPs wie Kunden, hier ist die bei PPP mögliche dynamische IP-Vergabe (zum Leidwesen vieler Geeks) sehr von Vorteil und auch dringend notwendig. Und nicht zuletzt waren die Kunden an das manuelle "Einwählen" gewöhnt, durch den Einsatz von PPPoE bleibt auch beim Kunden alles beim Alten. PPPoE portiert nicht einfach ein par Features von PPP auf Ethernet (was inhaltlich eigentlich schon wieder falsch ist weil PPP unabhängig vom Medientyp funktioniert), sondern macht aus einer Standleitung nach außenhin wieder eine Wählverbindung. Also ein Rückschritt in die Steinzeit, abgesehen von der Geschwindigkeit.

Aktuelle Bausteine für die serielle Schnittstelle erreichen etwa 1 MBit/s, die angegebenen 192 kBit/s sind aber auch bei den Standard-UARTs (8250/16550) falsch: dort war das technische Limit 115.200 Bit/s. Woher die 192 kBit/s kommen weiß wohl nur der Originalautor.

PPPoE hat seinen Namen auch nicht von der früher üblichen Methode, die Modems über Ethernet an den Rechner anzukoppeln: Vielmehr ist es so, dass der Backbone des DSL-Netzes mit ATM betrieben wird und der Access Concentrator mit den Modems über die LAN-Emulation von ATM (LANE) spricht. Ethernet kommt also nicht nur zwischen PC und Modem zum Einsatz, sondern ist eine der Grundlagen des gesamten DSL-Netzes. Das DSL-Modem selbst kennt gar keine Protokolle, sondern stellt lediglich eine Ethernet-Brücke zwischen dem Rechner und dem DSL-Backbone dar. Inzwischen gibt es auch DSL-Modems die über USB angebunden werden, die natürlich genau so funktionieren wie über Ethernet angebundene Modems: Hier würde die Begründung gar keinen Sinn mehr machen.

Der letzte Absatz über die verringerte MTU bei Verwendung von PPPoE ist inhaltlich richtig.

IP-Fragmentierung

Dazu hab ich dann doch einen Kommentar, mit der Bitte um Diskussion:

"Bei PPPoE verringert sie sich jedoch wegen eines zusätzlichen Headers von 8 Byte auf 1492 Byte. Falls der TCP/IP-Treiber die Größe beim Senden nicht ermitteln kann, werden trotzdem 1500 Byte große Datenpakete erzeugt. Dies ist normalerweise kein Problem, da das Internet-Protokoll das Paket fragmentieren kann. Fragmentierung wird wegen des erforderlichen Aufwandes jedoch zunehmend im Internet abgeschaltet, so dass ohne besondere Maßnahmen manche Webserver nicht zugänglich erscheinen."

Dass das abgeschaltet wird stimmt m.E. nicht. Vielmehr gibt es einige DSL-Provider, die dafür sorgen, dass die ICMP Fragmentation occured-Pakete nicht korrekt zurückgemeldet werden so dass die Path MTU Discovery nicht funktioniert. Das ist (Vermutung!) Absicht, um den Anschluss von Routern zu erschweren. Ein Einzelplatz-PC hat keine Probleme, die Anfangsgrösse erhält der PC direkt vom Netzwerktreiber (hier PPPoE-Treiber).

Heutzutage erledigen Router das automatisch, so dass das Erschweren keines mehr ist. Das Manko bleibt jedoch.

Ob Path MTU Discovery aufgrund des Eingriffs einiger DSL-Provider nicht funktioniert, kann ich nicht sagen. Allerdings sind die Packetfilter (Firewalls) bei den Betreibern einiger "großer" Websites (AFAIK AOL) falsch konfiguriert, so dass sie die ICMP-Pakete für PMTU ausgehend nicht zulassen.

Ich würde den entsprechenden Satz daher wie folgt formulieren:

 "Fragmentierung ist aufgrund falsch konfigurierter Packetfilter (Firewalls) teilweise nicht 
  möglich. Dem Benutzer bleibt nur übrig, das Problem mit einer fest eingestellten MTU von 1492 zu 
  umgehen. Allerdings sollte der Benutzer den Betreiber einer so falsch konfigurierten Website auf 
  den Fehler hinweisen."

.. was meiner Meinung nach reiner POV (d.h. nicht neutraler Standpunkt) ist. Das muss man natürlich unbedingt neutraler formulieren. (Hinweis: Aussagen wie "falsch konfiguriert", "bleibt nur übrig" sollten sich nicht in einer Enzyklopädie finden, denn es ist nicht unsere Sache zu entscheiden, was falsch und was richtig ist. Firewalls müssen in erster Linie vor Angriffen schützen. In neuerer Zeit hat sich die "Policy" "default deny" durchgesetzt, wobei hier dann eventuell zuviel geblockt wird. Konkret: welcher Standard (=RFC) ist hier - möglicherweise - verletzt, um die Aussage falsch zu begründen?) --Hubi 19:03, 8. Okt 2005 (CEST)

Dass es falsch ist, per gesetztem Don't-Fragment-Bit ICMP-Fragmentation-Needed-Packete explizit anzufordern, diese aber dann reaktionslos zu droppen (und genau das ist in aller Regel der Kern des Problems der betroffenen Server bzw. ihrer Firewalls), liegt eigentlich auf der Hand. Wenn dann (wie üblich) auch noch MTUs jenseits des IPv4-Minimums (68 Bytes) oder gar des TCP-Standards (576 Bytes) verwendet werden, wird jede Kommunikation im Allgemeinen unmöglich. RFC 2923 (Abschnitt 2.1) spricht ausdrücklich von Fehlkonfiguration: »These situations can almost always be blamed on a misconfiguration within the network, which should be corrected«, und warnt vor Workarounds, die zwangsläufig Performance kosten und das eigentliche Problem ungelöst lassen.

Ich lösch den Absatz ersatzlos, weil er wie gesagt weitgehend falsch ist, weil das Problem längst nicht mehr so akut ist wie damals, dass man es in einem Artikel über PPPoE (das mit dem eigentlichen Problem nichts zu tun hat) erwähnen müsste, weil obiger Vorschlag nicht nur in der Tat POV, sondern auch nicht viel richtiger ist, und weil ich auch zu wenig zitierfähige Informationen über den aktuellen Stand (z.B. gefixt oder Workaround?) hab. Die effektive MTU ist übrigens bei PPPoE keineswegs immer 1492 Bytes; viele ISPs verwenden heute in ihrem Netz weitere Protokollschichten, die sie weiter reduzieren. --89.61.236.182 06:40, 3. Jan. 2008 (CET)

T-DSL mit verschiedenen Providerern und Netzen:

Wie funktioniert die Einwahl bei einen anderen Provider (nicht T-Com Backbone) ? Ich sehe immer nur einen AC-Name bei der Einwahl.

T-Com tunnelt dich über ihren AC zum anderen Provider durch. Insofern läuft es doch über den T-Com-Backbone, jedenfalls auf PPP-Ebene. IP-mäßig siehst beim Traceroute schon beim ersten Hop nur den Fremdprovider. --Matthäus Wander 01:46, 29. Jul 2005 (CEST)

Sehr detailiert unter Diskussion:Broadband_Remote_Access_Server 84.173.202.133 11:27, 5. Jan. 2007 (CET)

Hat jemand Erfahrung mit ML-PPPoE? Gibt es solch einen Protokoll Stack?

WsPPPoE

Was ist WsPPPoE ?

PPPoE_Client_PC

Ich hatte Probleme mit Linux und dem Arcor-Zyxel Router. Ich kontne bestimmte Seiten nicht öffnen, die in der URL einen Port hatte (bei mir war es bsp: http://irgendwas.de:8484/ ). Nach Aktivierung von

PPPoE Pass-Through
  PPPoE + PPPoE_Client_PC (ja/nein)

konnte ich wieder alles ansurfen. Toll, aber was ist "PPPoE_Client_PC". Auf der Hilfe- des Routers ist leider auch nix drauf. Grüße --Hand der Rose 15:44, 7. Nov. 2006 (CET)

PPPoE und Abhörsicherheit?

Ist der PPPoE Header eigentlich abhörsicher? Sprich kann jemand aus einem mitgesnifften Header das Passwort und die Userkennung extrahieren?

Nur dein Login wird im Klartext übertragen. Dein Passwd kann nicht gelesen werden. Da kommt es eher zum Beispiel auf die "Knackbarkeit" des MD5-Algos an.

Wenn der Algo knackbar ist, kann man aus der Challenge, die der Server an deinen PC sendet und der Antwort auf die Challenge das Passwort errechnen. Siehe Artikel Point-to-Point Protocol - Appaloosa 18:24, 10. Dez. 2006 (CET)

Auch das ist leider nicht ganz richtig. Da unterm Strich PPP zur Anwendung kommt, kommt es auf den benutzten Authentifizierungsmechanismus an. Bei der Anwendung von PAP wird sehrwohl das Passwort im Klartext übermittelt.--Darten 16:26, 7. Feb. 2008 (CET)

Tiefgehender Artikel, aber einfachste Dinge werden nicht klar.

Hallo, hier werden fachliche Dinge diskutiert, die nur wenige verstehen. Aber die einfachsten Dinge werden nicht klar. Nämlich:

• Habe ich dann einen PPPOE, wenn ein oder mehrere Computer über Ethernet an einen Router angeschlossen sind und der Router die Internetverbindung herstellt?
• Oder habe ich dann PPPOE, wenn ein einzelner Computer über Ethernet und dann über ein Modem ins Internet geht? Der PC managt also die Internet Verbindung in diesem Falle selbst.

So etwas sollte gleich zu Anfang des Artikels geklärt werden, da der großen Menge der unbedarften User dieses Einordnungsmerkmal als erstes über den Weg laufen dürfte. Weiter hinten ist der Weg dahin mit zuviel nicht verstehbarer Fachterminologie gepflastert, so dass man dorthin nicht vorzudringen vermag. -- 84.132.126.109 09:03, 28. Jul. 2007 (CEST)

Name hat nichts mit LANE zu tun, LANE findet keine Anwendung bei ADSL

PPPoE geht über jedes Ethernet. Daher hat die Namensgebung auch nichts mit üblichen oder unüblichen "ADSL-Stacks" zu tun. Richtig bleibt, dass auch bei ADSL PPPoE auf Ethernet-Frames aufsetzt. Diese Ethernet-Frames werden aber nicht mit Hilfe von LANE übermittelt! LANE ist ein viel zu aufwendiges Gebilde nur um darüber ein paar Ethernet-Frames via ATM zu verschicken. Die klassischen ADSL-Modem-Router macht daher zu keinem Zeitpunkt bei einem LANE mit, obwohl sie das ATM-Netz logisch abschließen.--Darten 16:22, 7. Feb. 2008 (CET)

An dieser Stelle bedarf es, meiner Meinung nach, eines Literaturverweises. Denn wenn nun kein LANE zum Einsatz kommt (was ich auch für zweifelhaft halte), warum wird denn überhaupt PPPoE verwendet. Warum dann nicht PPPoA, bzw. PPP direkt in ATM Zellen gepackt. Denn soweit mir bekannt ist, läuft über viele ADSL Anschlüsse ja ATM und nicht Ethernet, warum dann also ein PPPoE, und wenn PPPoE wie läuft dies auf der ATM- Stecke?

Im Labor haben wir einen IP-DSLAM von Zyxel untersucht, der auf der Teilnehmeranschlussseite ATM fährt, und auf der Seite zum Backbone über Gigabitethernet verfügt. Dieses Gerät verfügt über einen Modus, in dem er die PPP(oA) Pakete der ATM Seite (zum Endteilnehmer) in PPPoE Pakete zum BRAS (Broadband Remote Access Server) wandelt. Ich glaube aber nicht, dass diese Lösung flächendeckend eingesetzt wird, zudem dabei ja auch der Endteilnehmer nicht über PPPoE kommuniziert.

212.202.186.35 11:38, 11. Mai 2008 (CEST)

Falsche Angaben unter dierser Kategorie: Typfeld des Ethernet-Frames

Hallo Leute.
Kann bitte jemand die korrekten Werte für alle Felder eingeben.
Die Angabe eines 16bit Wertes für das "Typfeld des Ethernet-Frames"
ist FALSCH.
DANK an den der nachbessert.
-- 93.220.29.222 21:51, 2. Jun. 2009 (CEST)

Keine Ahnung was du möchtest. Jedenfalls stimmen die Werte:

http://www.iana.org/assignments/ethernet-numbers

Diese Werte sind laut Wireshark und dem oben genannten Link immer noch 16 Bit bzw. 2 Byte lang - Appaloosa 23:32, 2. Jun. 2009 (CEST)

PPPoE-Fehler: Internet Synchronisierung verloren.

Bei TDSL-Problemen meldet die FRITZ!Box: PPPoE-Fehler: Internet Synchronisierung verloren.

Was bedeutet das? Wann tritt der Fehler auf? Wie wird der Fehler behoben? (nicht signierter Beitrag von 91.49.124.79 (Diskussion) 07:35, 4. Dez. 2012 (CET))