Dial-On-Demand mode funktioniert nicht.

hoba

Die pfSense macht von sich aus keine DNS-Anfragen (ausser z.B. zum NTP-Zeitablgleich vielleicht oder zum DynDNS-Server-update). Wieso sollte Sie das tun? Aus Langeweile?

Und bzgl. dem "override DHCP/PPP on WAN", das funktioniert genauso, wie es soll.

Viel wahrscheinlicher ist, daß wir ggf. die Dial-On-Demand-Option entfernen werden. Das ist ein Überbleibsel von m0n0wall. pfSense war nie für Dial-On-Demand konzipiert worden. Keine der Services berücksichtigen diese Einstellung obwohl mir nicht direkt Probleme damit auffallen bis auf das angesprochene Gatewayping zur Qualitätsüberwachung, was sich aber abstellen läßt (siehe oben).

nostra

Dial-On-Demand-Option entfernen finde ich eigentlich weniger gut.
Einen Grund wozu man es braucht nannte ich ja bereits im ersten Post. Auch gibt es noch Leute die keine Flatrat haben, die werden das sicherlich auch nicht begrüßen.

Ich habe eben nochmal etwas getestet.
Nachdem ich DynDns deaktiviert habe, scheint es zu funktionieren und er wählt sich nicht mehr ein.
Als ich es gestern getestet hatte, da hatte ich sicherlich noch nicht das mit dem Eintrag für den Gatewayping zur Qualitätsüberwachung gemacht.
Also scheinen beides zusammen, die Qualitätsüberwachung und DynDns die verursacher zu sein.
Ich werd es morgen früh sehen, ob der Router über Nacht offline war.

Das es bei deaktivierten "override DHCP/PPP on WAN" und aktiven DynDns funktionierte, also der Router sich nicht einwählte lag sicherlich daran, dass er mangels DNS Server auch keine DynDns Abfrage sarten konnte.

Sollte also DynDns der Verursacher sein, dann ist da doch hoffentlich eurerseits noch was zu machen, damit dieser Service nicht selbstständig eine Verbindung herstellt, denn deaktivieren wäre eigentlich auch nicht das Ideale.

hoba

Wenn es nur die 2 Sachen sind sollte sich was machen lassen, ich warte auf Deinen Bericht. Also Marsch, Marsch, offline gehen zum Testen ;)

nostra

So alles klar.
DynDNS und auch die von dir erwähnte Qualitätsüberwachung sind die Übeltäter.

Heute nach dem einschalten des PCs konnte ich dann in der Router Log sehen, dass er sich gerade eine neue IP geholt hatte, also die ganze Nacht offline war.
Ich habe dann auch nochmal meinen fake Gateway vergeben und nach meinen voreingestellten 20 min. ging der Router dann auch offline und blieb es auch.
Nun habe ich aus dem config.xml script nochmal den Eintrag <use_rrd_gateway>127.0.0.1</use_rrd_gateway> entfernt, um zu testen ob eventuell nur dyndns schuld ist, die config eingespielt, rebootet blablabla und siehe da schon ging er nicht mehr offline.

Folglich sind dyndns UND Qualitätsüberwachung die Übeltäter.

Ich hoffe ihr bekommt das hin und geht nicht einfach den leichten Weg und entfernt stattdessen die Dial-On-Demand-Option.

hoba

Ok, danke schon mal für die Analyse. Das sollte dann irgendwie machbar sein denke ich.

nostra

Weil wir gerade bei Bugs sind, dann hätte ich noch zwei für dich.

Seit RC2 ist im Konsolenmenü Punkt 12 verschwunden.
"Neu einlesen der IPs" oder so.
Funktionieren tut Punkt 12 immer noch, nach Eingabe von 12 wird es neu eingelesen. Punkt 12 fehlt einfach nur in der Auflistung.

Dann ist mir noch aufgefallen, dass seit es die Mini-Embedde updates gibt, das dieses nicht so richtig hin haut.

Spiele ich z.B. auf meine CF Card per Kartenleser im PC, pfSense.img.gz vom 26-Sep-2006 auf, so kann ich ja zum Beispiel für das Update vom 27-Sep-2006 das mini update nutzen, also "pfSense-Mini-Embedded-Update-1.0-SNAPSHOT-09-27-06.tgz".
Dieses kann ich dann per Webmenü direkt mit pfsense einspielen. Das klappt auch soweit, nur im Konsolen-Menü werden mir nach dem reboot nicht mehr die Punkte 1-11 angezeigt. Das Menü bleibt bei "Bootup complete" hängen (auch nach wiederholten reboot).
Danach sollte dann ja eigentlich das Menü kommen

Bootup complete
hier bleibt es dann nach dem mini update und dem reboot stehen
FreeBSD/i386 (xxxx.xxxxx.org) (console)

*** Welcome to pfSense 1.0-SNAPSHOT-09-27-06-embedded on xxxxx ***

LAN* -> sis0 -> 192.168.100.250
WAN* -> sis1 -> 62.x.x.x(PPPoE)

pfSense console setup

0) Logout (SSH only)
1) Assign Interfaces
2) Set LAN IP address
3) Reset webConfigurator password
4) Reset to factory defaults
5) Reboot system
6) Halt system
7) Ping host
8) Shell
9) PFtop
10) Filter Logs
11) Restart webConfigurator

Auch ein blindes eingeben der Punkte wie es z.B. oben mit dem Punkt 12 beschrieben ist funktioniert dann bei keinem der Punkte.
Will ich weiterhin das Konsolen-Menü, bleibt nur wieder der komplette CF flash mit dem aktuellen pfSense.img.gz vom 27-Sep-2006

Alles andere, also im Webmenü fünktioniert aber fehlerfrei.

Für was ist eigentlich das "pfSense-Full-Update-1.0-SNAPSHOT-09-27-06.tgz". ich hatte die CF damit geflasht, aber danach war sie nicht bootfähig und als update per Webmenü (so wie mit dem mini update) wird es aber auch nicht genommen.

hoba

Ok, schauen wir uns an, aber die Option 12 ist absichtlich entfernt worden.

nostra

Nochmal bezugnehmend auf deine Aussage.

Viel wahrscheinlicher ist, daß wir ggf. die Dial-On-Demand-Option entfernen werden.

Solltet ihr das tatsächlich mal entfernen, dann findet ja auch keine automatische Einwahl mehr statt, wenn ich z.B. den Browser starte.
Jedes mal, wenn die Verbindung, aus welchen Gründen auch immer getrennt ist, müsste man dann das Webmenü von pfsense starten und unter "Interfaces" die Verbindung von "Hand" herstellen und das kann es doch nicht sein.
Hier in DE haben die wenigsten Leute eine Standleitung, die meisten haben DSL per Einwahl, also PPPoE mit Benutzernahme und Passwort und folglich Einwahl.
Also wenn ihr mal was entfernt, dann vielleicht das man die Zeit festlegen kann, aber doch bitte nicht Dial-On-Demand an sich.

Wurden die besprochenen Probleme dyndns und Qualitätsüberwachung eigentlich schon in RC3 aufgenommen? Im Change Katalog kann ich jedenfalls nichst dazu finden.

hoba

Du musst gar nichts machen um die Verbindung wieder herzustellen, der Router ist Daueronline und wählt sich nach Zwangstrennung sofort wieder ein, wenn kein Dial on Demand benutzt wird.

Die angesprochenen "Probleme" wurden nicht in RC3 berücksichtigt. Es gibt dafür einen Workaround (config.xml modifizieren, kein dyndns benutzen). Das kam einfach etwas zu spät für RC3.

Das Konsolenproblem sollte jedoch behoben sein.

nostra

Nein ist er eben nicht, wenn die Verbindung einmal getrennt wurde.
Nur wenn sie einmal steht ist es eine Dauerverbindung.
Ich habe es vor deinem Post extra nochmal getestet, Häkchen bei Dial-On-Demand raus, Verbindung getrennt und mit dem Browser Webseiten aufgerufen. Es passiert nichts, es wird keine Verbindung autom. aufgebaut, wenn Dial-On-Demand deaktiviert ist.
Daueronline bleibt es nur, wenn man einmal die Verbindung von "Hand" hergestellt hat.
Des weiteren frag ich mich, was passiert nach der 24 Stunden Zwangstrennung von T-Com ohne Dial-On-Demand, wählt er sich dann wieder von alleine ein, wenn z.B ein up/download läuft, habe da so meine Zweifel.

Außerdem gibt es noch andere Gründe, weshalb die Verbindung beendet werden könnte, Stromausfall, Provider Störungen, DSL Störungen etc.
In allen fällen müsste dann die Verbindung erstmal von "Hand" aufgabaut werden, weil es nur durch den Aufruf das Browsers etc. ja ohne Dial-On-Demand nicht mehr geht.
Was wäre in solchen Fällen dann, in einem Firmennetzwerk oder einem großen privaten Netzwerk, wo mehrere fremde Haushalte dranhängen?
Ohne admin keine Einwahl mehr, oder soll der admin allen Anwendern den Zugriff auf den Router gewähren, damit diese im Fall der Fälle eine Verbindung wieder herstellen können, ich danke dann kann man den Router auch gleich abbauen, wenn Hinz und kunz Zugriff auf ih haben.

Eben habe ich es auch nochmal versucht, bei getrennter Verbindung und deaktivierten Dial-On-Demand, wird autm. keine Verbindung wieder hergestellt.
An sich sagt ja der Name auch alles.
Dial-On-Demand = Wäle auf Befehl/ Anforderung

nostra

Ok ich habe es eben nochmal getestet, nach dem Stecker ziehen, was ja einem Stromausfall entspricht und dem folgenden reboot, wird tatsächlich auch ohne Dial-On-Demand eine Verbindung wieder hergestellt, egal ob vor dem "Stromausfall" eine Verbindung bestand oder nicht.
Nur was wäre bei Provider- oder DSL Störungen? Habe ich gezielt von "Hand" getrennt, wird ja auch nichts mehr aufgebaut.

hoba

DSL-Störung ist kein Thema, er versucht es solange, bis es klappt, wenn kein Dial on Demand genutzt wird.

nostra

Na dann bin ich ja beruhigt.
Aber bis jetzt habt ihr es ja noch nicht entfernt und ich hoffe ihr werdet es auch in Zukunft nicht tun, denn schaden tut es ja niemanden und ich brauche es, meine Gründe kennst du ja.

hoba

Ich sehe noch einen anderen nutzen des Dial on demand für ein spezielles CARP-Setup (failover). Wenn es sich irgendwie fixen läßt wird es nicht entfernt.

nostra

Na und wenn es sich nicht fixen lässt, dann nehmt eben einfach nur die "Idle Time out" raus, die nicht richtig mit dyndns und Qualitätsüberwachung arbeitet und setzt sie intern auf null, also unendlich.
Im Fall der Fälle, dass eine Einwahl nötig ist, weil disconnected ist, warum auch immer (z.B. der admin hat von "Hand" wegen Wartungsarbeiten disconnected aber vergessen neu zu connecten), kann so eine Verbindung aufgebaut werden.
Und wer will kann ja dann per config.xml die zeit verändern.

Und wenn ihr es doch ganz entfernen solltet, dann lasst wenigstens die Möglichkeit es per config.xml hinzuzufügen und bearbeiten zu können.

hoba

Ich glaube da ist ein Verständnisproblem, was der idle timeout macht und das dial on demand. Wenn wir es wirklich entfernen sollten, dann wird nur die GUI-Einstellung entfernt. Das Backend bleibt bestehen, also würde man es über die config.xml wieder aktivieren können…aber läßt Du uns erst mal die Zeit daran zu arbeiten bevor wir Eventualitäten besprechen, die dann doch nicht zustande kommen? ;)

nostra

Es gibt Grund zur Freude.
Den Tag, bevor ich von dir den Tipp mit der Qualitätsüberwachung bekam, hatte ich mein dyndns auf "dyndns (custom)" umgestellt, weil ich ja vor deinem Tipp alles möglche versucht hatte.
Dann gabst du mir den Tip mit der Qualitätsüberwachung und ich ließ mein dyndns in diesem Modus, wofür auch immer der ist.
Das fiel mir nun gestern auf, weil ich gestern dyndns brauchte und es wieder aktivierte, aber meine IP nicht wirklich bei dyndns in diesem Modus aktualisiert wurde (mittlerweile habe ich rausgefunden, das "costum Modus" ein kostenpflichtiger Dienst ist).

So nun habe ich mein dyndns wieder auf "dyndns dynamic" umgestellt und was ist das Ergebnis?
In diesem Modus sorgt dyndns nicht mehr dafür das der Router die Verbindung hält, bzw. neu aufbaut :-).
Nur im für mich falschen "custom Modus" hat er das getan.

Der einzig Schuldige war also die Qualitätsüberwachung.

hoba

Danke für das Update. Vmtl. wird es für 1.0 eine Info geben den rrd gateway in der config.xml zu verbiegen. Diese beiden Features Vertragen sich nicht miteinander.

Das mit dem Custom (wenn man's nicht hat) kann natürlich zu Problemen führen weil er es immer wieder probiert nachdem es ja nicht geklappt hat.

nostra

Hallo hoba,

wie sieht es bei der neuen Final aus, muss ich bei der die "Qualitätsüberwachung" auch wieder umbiegen oder habt ihr was gemacht, damit es nun auch damit funktioniert?

hoba

Du brauchst weiterhin den Eintrag in der config.xml.