Nochmal in-kernel pppoe

Arjan

Arjan

Well-Known Member
Muß mal fragen:

1. Gibt es eine Möglichkeit, den in-kernel pppoe per Hand zu steuern (mhm doof formuliert)
konkret: Ich will ihn bei Bedarf per Hand schlafen legen und wieder neu verbinden lassen.

2. Hier war mal beschrieben, wie man die pf.conf einstellen kann, dass die Maschine auf keine Pakete von aussen mehr reagiert. Aber ich finde es nicht mehr :confused:

Hat jemand einen Tip?


Gruß :cool:
 
if up if down... =) Will heißen, Netzwerkkarte einfach über die skripte aktivieren bzw. deaktivieren. MTU in der pf.conf etc nicht vergessen...
man 4 ppoe beschreibt es eigentlich ausführlich. (man 8 ppoe beschreibt den userland ppoe Kram)
 
Mahlzeit,

in dem zusammenhang (habe die Fragen auch schon in dem anderen Thread gestellt, vll hab ich hier ja mehr Glück =)):

Wie komme ich an die Informationen, die der Provider liefert:

- Peer
- DNS-Server
- MTU (wenn ich das richtig verstanden habe wird die immer auf 1492 gesetzt)
- ... (fals ich noch was vergessen habe =))

MfG Hagen
 
Peer setzt du einfach auf 0.0.0.1, das wird als Wildcard hergenommen und es wird der Peer den dir der Provider liefert eingesetzt, MTU entweder wie in der Manpage beschrieben ( man 4 pppoe ) mit pf anpassen oder auf den "internen" Interfaces ( natürlich nur wenn du pppoe auf einem Router konfigurierst) mit
Code: 
ifconfig interface mtu 1492
anpassen.

DNS ist ein bisschen schwieriger, da um das automatisch einzustellen der Kernel in eine Datei schreiben müsste, was natürlich keine so ideale Lösung wäre, allerdings steht es auf den Internetseite der meisten Provider welche DNS-Server sie haben, wenn du im Moment keinen Internetzugriff hast, einfach 194.25.2.129 hernehmen, das ist ein DNS von T-Online, den ich mittlerweile auswendig weiß ;)

Zum Schluss noch, falls du sie noch nicht gelesen hast, in der manpage (man 4 pppoe ) steht wirklich alles ganz genau drin, sollte eigentlich eine Sache sein die man in 1 Minute am laufen hat.

/dev/urandom
 
Mahlzeit,

das ist klar. Darum geht es aber gar nicht. Ich habe keine Lust regelmäßig beim Provider nachzuschauen, ob die Nameserver sich geändert haben.
Die MTU sollte eigentlich automatisch gesetzt werden (für das pppoe interface).

Den Peer habe ich, gemäß man-page auf 0.0.0.1 gesetzt. Der Wert ändert sich aber auch nie (ifconfig zeigt auch bei bestehender Verbindung als peer 0.0.0.1 an).

Es geht mir darum die Daten wenigstens auslesen zu können (das sie vom kernel nicht gesetzt werden mach nur bei änderung von Dateien sinn, auf dem Interface imho nicht).

MfG Hagen
 
Danke für die Info. Aber ändert leider nichts an der situation. Da ich auf den Systemen eigentlich immer dnscache (djbdns) laufen habe, interessieren mich die dns-server nicht so sehr.
Aber das die MTU nicht automatisch korrekt gesetzt wird (wenn ich mich recht entsinne optionaler bestandteil von ppp), ist schon fast KO-Kriterium. Zumindest unter linux setzt rp-pppoe die MTU sauber.
Das der peer nicht angezeigt wird sehe ich auch nicht gerade als sauber an.

Alles in allem macht das ganze den Eindruck noch in den Kinderschuhen zu stecken. Nur wollte ich eigentlich userland pppoe vermeiden, weil ich den Spass auf nem WRAP system (266Mhz / 128MB) laufen habe, und zusätzlich noch vpns darüber laufen -> jedes freie Mhz ist wichtig =)

Na ja... Harren wir der dinge, die da kommen...
 
Tja, wäre dann aber die erste implementation von OpenBSD, die nicht wirklich zu ende gedacht wäre.
Fakt ist, dass ich wissen möchste, wer mein Peer ist (um bei einem der Beispiele zu bleiben). Wenn ich das nicht sehen kann, ist die Implementation unvollständig.

Ein zuverlässiges System lässt sich, da man die DNS-Server und den MTU Wert des Providers nicht auslesen läßt, mit dieser Implementation ebenfalls nicht realisieren.

Abgesehen davon, länger als Linux? Ich dachte eigentlich die in-kernel implementation von pppoe ist neu... Na ja, dann hab ich da was falsch verstanden.

MfG Hagen

P.S.: Wir reden hier nicht über Komfort, sondern davon, dass eine Implementation nicht den vollen Umfang von pppoe nutzt.
 
openbsd hat kernel-pppoe wirklich noch nicht lange.

unter netbsd ist das ganze ausgereifter. da uebernehmen die interfaces automatisch die mtu des peers, die dns-server lassen sich mit pppoectl abfragen und ipv6 ueber pppoe ging da auch eher.

btw, den peer kriegt doch das ifwatchd-script uebergeben bei jedem connect. ist das unter openbsd nicht so?
 
Hallo,

mir sind keine befehle / möglichkeiten bekannt die genannten Werte auszulesen, deswegen ja auch die Frage... ;-) Weiß jemand wie hier die weiteren Pläne sind? Oder sollte man doch lieber zu userland Lösung greifen und das ganze noch ein bisschen "reifen" lassen?

@uwerler: Das ist ja schon einmal ein Hinweis (auch wenn das die uninteressanteste Information von den dreien ist =)). Wie funktioniert das, wenn pppoe nicht die default route ist oder wenn ich mehrere pppoe Verbindungen habe?

MfG Hagen
 
pZYchO schrieb:
Hallo,

mir sind keine befehle / möglichkeiten bekannt die genannten Werte auszulesen, deswegen ja auch die Frage... ;-) Weiß jemand wie hier die weiteren Pläne sind? Oder sollte man doch lieber zu userland Lösung greifen und das ganze noch ein bisschen "reifen" lassen?

@uwerler: Das ist ja schon einmal ein Hinweis (auch wenn das die uninteressanteste Information von den dreien ist =)). Wie funktioniert das, wenn pppoe nicht die default route ist oder wenn ich mehrere pppoe Verbindungen habe?

MfG Hagen
Zum Vergrößern anklicken....

Gute Frage - muß ich mal testen. Wenn ich was weiß, werde ich es mitteilen.
 
Hi,

ich nutze openbsd 3.9.

pppoe 4:

pppoe sets the MTU on its interface to 1492 as a matter of course.

Liest sich für mich nach eine statischen Einstellung. Das macht auch Sinn, wenn man die vom Provider gelieferter Werte ignoriert, da 1492 das max ist (wie auch in der man page beschrieben).

MfG Hagen
 
Na ja, dann kann ich auch bei Linux bleiben. Bezogen auf das WRAP System würde das bedeuten, dass ich wieder bei null anfange. Dann lebe ich lieber noch ein paar Wochen / Monate mit der userland implementation. Ich kann mir nicht vorstellen, dass die in-kernel Lösung so bleibt.

Trotzdem danke für den Hinweis ;-)

MfG Hagen
 
pZYchO schrieb:
Hi,

ich nutze openbsd 3.9.

pppoe 4:

pppoe sets the MTU on its interface to 1492 as a matter of course.

Liest sich für mich nach eine statischen Einstellung. Das macht auch Sinn, wenn man die vom Provider gelieferter Werte ignoriert, da 1492 das max ist (wie auch in der man page beschrieben).

MfG Hagen
Zum Vergrößern anklicken....

Das ist schon mal nicht so gut. Du solltest die MTU nehmen, die Dein Provider angibt. Und das ist nicht immer 1492.

userland-pppoe kann es wohl automatisch setzen - aber bei meinem 3.9 und meinem Provider will der erst gar keine Connection aufbauen ;'(


Gruss:cool:
 
Na ja, es geht ja eben nicht darum, dass ich die MTU setze, sondern darum, das OpenBSD die setzt, die der Provider übermittelt (ich hoffe, ich darf das so formulieren, ich kenn ppp nicht so genau =)).

Mit welchem Provider kriegst du denn keinen connect? Schon mal die in-kernel implementation ausprobiert? Ich hatte bisher keine Probleme (t-online, arcor, ncore).

MfG Hagen
 
pZYchO schrieb:
Na ja, es geht ja eben nicht darum, dass ich die MTU setze, sondern darum, das OpenBSD die setzt, die der Provider übermittelt (ich hoffe, ich darf das so formulieren, ich kenn ppp nicht so genau =)).

Mit welchem Provider kriegst du denn keinen connect? Schon mal die in-kernel implementation ausprobiert? Ich hatte bisher keine Probleme (t-online, arcor, ncore).

MfG Hagen
Zum Vergrößern anklicken....

userland-pppoe setzt sie, wie der Provider übermittelt; in-kernel bin ich mir nicht sicher, da ich in-kernel benutze, setze ich die MTU in pf.

Freenet will nicht mit meinem useland-pppoe :confused:


Gruss :cool:
 
pZYchO schrieb:
Mahlzeit,

in-kernel setzt sie nicht.

Hast du mal die in-kernel implementation getestet?

MfG Hagen
Zum Vergrößern anklicken....

Steht doch da, daß ich in-kernel benutze :grumble:
Funktioniert tadellos.

Muss ich ja auch nehmen, wenn der userland nicht will.


Gruss :cool:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben