Dial-On-Demand mode funktioniert nicht.

hoba

bzgl. Mail: Ja, habe scheint daran zu liegen, daß Du selbst Dein eigenes Profil sehen kannst.

Du hast zwar den Gateway Deines Clients verbogen, damit er nicht mehr an die pfSense geht, aber DNS ist vmtl. immer noch die pfSense. Also wenn irgendein Programm/Task von Windows denkt mal irgendwas anfragen zu müssen geht das an die pfSense und dann weiter an den ISP DNS. Verbiege den DNS auf Deinem Client auch mal bitte, daß DNS und Gateway keines Clients mehr auf die pfSense verweisen. Hier gilt us u.U. auch vorhandene Accesspoints o.ä. zu prüfen (siehst Du ja aber dann im pftop).

nostra

So, nun hab ich es glaub ich.
Du hattest fast Recht.
In meiner NIC unter DNS habe ich 5 DNS Server meines ISP eingetragen und als sechste und letzte die IP das Routers.
Dadurch wurden in Tera Term–>pftop die DNS Abfragen angezeigt.
Nachdem ich in der NIC die Router IP entfernt habe, war nur noch eine Kommunikation PC<--->Router zu sehen (bei wieder gefakten Gateway). Allerdings fandem immer noch die automatischen Verbindungen statt, in Tera Term-->pftop wurde diesbezüglich aber nichts angezeigt, nur eben die bereits erwähnten lokalen Verbindungen PC<--->Router

Mit Putty komm ich leider nicht zurecht.
Ich starte Putty unter "Session" trage ich rechts die IP des Routers ein SSH ist schon vorausgewählt, nun klick ich auf "Open", eine "DOS" Konsole öffnet sich und nach einer Weile kommt ein error popup, mit der Meldung das keine Verbindung hergestellt werden kann.
Es kommt weder eine Benutzernahme noch Passwort Abfrage.
Was mache ich mit Putty also falsch, bzw was muss ich machen, damit das Funktioniert. Muss ich im Router noch was einstellen, damit ich mich per SSH mit ihm verbinden kann?

So die Lösung des ganzen scheint nun folgende zu sein.

In meiner NIC also für DNS die IP des Routers entfernt (wäre bei ausgeschalteten PCs irrelevant)
Dein Script von gestern <use_rrd_gateway>127.0.0.1</use_rrd_gateway>, welches aber dann auch erst in Verbindung mit folgenden Punkt funktioniert.
Unter "System: General Setup"
Allow DNS server list to be overridden by DHCP/PPP on WAN
deaktiviert.
Hatte ich Gestern zwar auch schon versucht und ohne Erfolg, zu dem Zeitpunkt hatte ich aber Punkt 1. und 2. noch nicht gemacht.

An dieser Stelle gleich nochmal eine andere Frage.
Pfsense ist im Webmenü, teilweise sowas von lahm, dass man die Krätze bekommt.
Ich konnte das Ganze schon mit einer besseren/schnelleren CF Card beschleunigen. Weiterhin konnte ich die ganze Sache auch noch mit
Diagnostics–>Edit File-->/boot/loader.conf

beschleunigen, indem ich folgende Werte von null auf eins gesetzt habe.
hw.ata.atapi_dma="1"
hw.ata.ata_dma="1"

Sicher hätte es bei einem der beiden gereicht, da ich aber nicht genau weiß als was das wrapboard meine CF-Card behandelt, ob als ATA (HDD) Laufwerk oder Atapi (CD-ROM) Laufwerk und ich keinen Bock hatte das noch auszutesten, habe ich einfach beide auf eins gesetzt und gut.
Seit dem läuft meine CF-Card im UDMA33 Modus, was auch ein wenig mehr Speed brachte.

Gibt es noch ein paar Dinge, mit dem man pfsense etwas schneller machen kann?

Ps: Mit der E-Mail stimmt, ist so das man nur selbst den e-mail Butten sieht, obwohl das eigentlich wenig Sinn macht.
Hatte mich eben mal testweise mit anderen Namen und e-mail Adresse registriert und angemeldet und da konnte ich in meinen nostra Posts nicht meine e-mail Adresse sehen.
Diese zweiten Account habe ich aber mittlerweile wieder gelöscht.

nostra

Hm, habe eben mitbekommen, dass bei deaktiviertem
Allow DNS server list to be overridden by DHCP/PPP on WAN

dem Router selbst keine DNS Server IP vom ISP mehr autom. zugeordnet wird.
Das ist natürlich weniger schön.
Ok man könnte nun im Router selbst die IPs für die DNS Server eintragen, sollten da aber mal nicht mehr aktuell sein, dann ist man gelinkt.
Ok man ist auch gelinkt, wenn man sie in der NIC fest einträgt und sie mal nicht mehr aktuell sind, aber dafür hatte ich als letzten DNS Server in der NIC den Router eingetragen, sozusagen mein fallback für die DNS Server, fallen meine eingetragenen aus, bleibt immer noch der Router selbst und der sollte durch die autom. DNS Server Zuordnung immer eine aktuelle DNS IP haben.
Bei deaktiviertem "Allow DNS server list to be overridden by DHCP/PPP on WAN" fällt das aber nun leider flach.

Ich denke, da muss in einer neuen Version von pfsense was getan werden, damit der Router sich nicht wegen seiner ständigen DNS Anfragen selbst mit dem I-Net verbindet.
Ähnlich eben wie beim Time Server oder bei DynDNS, ist der Router offline startet er zwar auch die anfragen, aber wählt sich nicht selbstständig ein.
Das ist mir vorhin nur in der System log aufgefallen, dass immer die genannten Abfragen gestartet wurden, es dann aber eine error Meldung gab, weil der Router offline war.
Oder es kam zu den error Meldungen und dem nicht Einwählen, weil der Router auf Grund des deaktivierten "Allow DNS server list to be overridden by DHCP/PPP on WAN" und dem daraus fehlenden DNS Server gar nicht verbinden könnte.
Denn ohne DNS Server konnte er ja kaum dyndns.org und Time-Server rztime1.rz.tu-bs.de in eine IP umsetzen und hatte folglich auch keinen Grund sich einzuwählen.

Langsam wird mir das mit den vielen wenn und abers zu konfus.
Ich denke am besten wäre es wohl, wenn sich die Entwickler dieses Problems annehmen und in einer neuen Version fixen.

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.