Verbindungsabbrüche
-
@rico said in Verbindungsabbrüche:
Wenn du wie beschrieben nur die dhclient Binary ausgetauscht hattest kann es daran 100% nicht liegen, wie sollte das etwas verstellen an System oder Config?
Das ist mir durchaus bewusst und so meinte ich es auch nicht. Ich habe eher Richtung anderweitiger Installationen (Packages) oder sonstiger vorgenommener Einstellungen gedacht.
Zu dem Fehler mit dem Supermicro Board kann ich nichts sagen, kenne weder das Board noch diesen Fehler.
Ok, verstehe ich. Mal ein anderer Ansatz: sind die Beep-Töne, die beim Start auf Fehler hinweisen, einigermaßen universell? Bringt es etwas, wenn ich den Fehlercode poste?
Hast du nicht eine andere Maschine zur Verfügung auf die du mal deine aktuelle pfSense Config recovern kannst?
-Rico
Ähm, ich habe hier noch so ein ähnliches Board (jedoch mit nur einem Realtek NIC), evtl. könnte ich mir noch eine PCIe-Karte mit einem Intel-NIC besorgen... aber dann müsste ich viele Dinge umstrukturieren (LAN und WLAN laufen bei mir getrennt, über 2 NIC's).
Ich warte jetzt noch ein paar Tage bzw. bis zum nächsten Absturz, habe gestern nämlich noch RAM ausgetauscht, da ich hier passende und vor ein paar Monaten getestete Module rumliegen hatte.
-
Also mal davon abgesehen dass sich das zum Ende hin sehr nach HW Problemen liest, statt nach Software, wollte ich da noch möglichst kurz zwei drei Punkte loswerden:
@Rico Herzlichen Dank für den Einsatz und das Compilieren und mittesten. Das ist mehr Einsatz als so mancher zeigt, egal in welchem Subforum/Reddit. Da wird dann lieber über Devs gewettert.
Ansonsten hab ich auch viel halbe Wahrheiten gelesen. Dass in diesem Fall OPNsense da schneller reagiert hat, mag durchaus richtig (und gut!) sein. Ist allerdings auch wenig verwunderlich, da durch NL/DE als großes Verbreitungsgebiet da viel mehr Leute theoretisch testen könnten - und es vielleicht auch tun. Aber da bin ich auch enttäuscht von den Usern hier. Da wird über die Devs gescholten und gewettert, dass denen alles egal ist etc. etc. ohne mal über deren Prioritäten nachzudenken und die Tatsache, dass die das bei sich vielleicht schlicht nicht nachstellen konnten weil das wieder eine typische deutsche Baustelle ist/war? Und wenn man dann sowohl das Ticket wie auch Upstream einen Fix gefunden hat -> warum nicht einfach mal das Ticket aktualisieren und drauf hinweisen? Das Ticket war btw auf "Future Fix" geflaggt, weshalb es dann auch bei Bugs einer spezifischen Version nicht auftaucht. Aber anstatt sich die betroffenen vielleicht im Redmine anmelden und da reporten - lieber mal auf die Entwickler schimpfen. Ist irgendwie typisch deutsch geworden, diese Schimpferei. Schade das. Ich schreibe hier ausdrücklich niemanden spezifisch rein, denn es hätte jeder Betroffene, der einen der Threads gelesen hatte machen können. Hat aber niemand.
Lange Rede kurzer Sinn: Abwarten, ob es jemand vom Dev Team aufgreift, ich habe mit meinem Redmine Account gerade das Ticket aktualisiert und auch den Fix von FreeBSD verlinkt und darauf hingewiesen, dass es schön wäre, wenn das jemand in einen Snapshot bauen würde, damit man es für ein Future Release testen und ausrollen kann. Dann muss man das auch zukünftig nicht händisch bauen.
Ansonsten könnte theoretisch @Rico auch einen Pull Request einreichen - gebaut hat ers ja anscheinen schonmal ;) Wäre also einen Versuch wert und seis nur, dass mans ggf. als Kommentar aufs Ticket dazu schreibt, damit man das ganze Thema nochmal anschiebt. Wenn aber 2 Jahre lang auch niemand mehr auf das Ticket reagiert wundert mich nicht, dass das keine Priorität hatte.Grüße
Jens -
Da ich von dem Problem überhaupt nicht betroffen bin kann ich selbst leider nichts testen und habe von dem her auch keine Requests eingereicht oder weitere Kommentare geschrieben.
Da muss einer ran der das Problem hat, im Optimalfall ohne weitere Nebenkriegsschauplätze.
-Rico
-
@Rico Geht mir leider - trotz Unitymedia ;) - auch so, daher kann ich da auch so gar nichts zu sagen. Leider. Und da der Patch auch Upstream nicht wirklich durch ist, halten die Entwickler erstmal die Füße still, da es schon einmal Probleme nach einem Patch des DHClients gab und das dann effektiv sehr viele betroffen hatte. Da kann ich Zurückhaltung schon verstehen, wenn man einen wichtigen Dienst auf WAN Seite nicht kaputt-patchen möchte. Schade, dass sich da auf das FreeBSD Ticket hin kaum was tut und die betroffene Menge anscheinend doch sehr gering ist.
-
@jegr said in Verbindungsabbrüche:
Also mal davon abgesehen dass sich das zum Ende hin sehr nach HW Problemen liest, statt nach Software
Nicht ganz korrekt. Das Problem mit dem DHCP Client ist schon mal ein Softwareproblem, was u.a. weiter oben durch mehrere Nutzer bestätigt wurde. Mein Hardwareproblem kam leider dazwischen, was für einige Irritationen sorgte, mehr nicht.
Ist aber hoffentlich nicht mehr relevant.@Rico Herzlichen Dank für den Einsatz und das Compilieren und mittesten. Das ist mehr Einsatz als so mancher zeigt, egal in welchem Subforum/Reddit.
Da gebe ich dir absolut Recht. @Rico ist mein Held und ich bin ihm unendlich dankbar, dass er sich als unbetroffener in diese Sache so reingehangen und mir eine Problemlösung angeboten hat.
Aber da bin ich auch enttäuscht von den Usern hier. Da wird über die Devs gescholten und gewettert, dass denen alles egal ist etc. etc. ohne mal über deren Prioritäten nachzudenken und die Tatsache, dass die das bei sich vielleicht schlicht nicht nachstellen konnten weil das wieder eine typische deutsche Baustelle ist/war?
Du magst Recht haben, ich habe einfach meinen Frust rausgelassen, weil mich das in den letzten (Feier-)Tagen so massiv geärgert hat und ich das Gefühl hatte, dass sich keiner dafür interessiert (was auch teilweise ja stimmt - wohl mehr tatsächlich aufgrund der Problematik, dass nur eine Handvoll Nutzer betroffen ist und sich dann auch kaum einer zu Wort meldet).
Das Problem bei mir persönlich ist einfach, dass ich die ganzen Prozesse der Softwareentwicklung, Bugmeldung und -behebung nicht wirklich verstehe und es mir unmöglich ist bei solch technischen Angelegenheiten auch noch in Englisch die Problemstellung zusammenzufassen und an der richtigen Stelle (redmine, FreeBSD) kundzutun bzw. generell bei solchen technischen Talks mitzumischen.Lange Rede kurzer Sinn: Abwarten, ob es jemand vom Dev Team aufgreift, ich habe mit meinem Redmine Account gerade das Ticket aktualisiert und auch den Fix von FreeBSD verlinkt und darauf hingewiesen, dass es schön wäre, wenn das jemand in einen Snapshot bauen würde, damit man es für ein Future Release testen und ausrollen kann. Dann muss man das auch zukünftig nicht händisch bauen.
Ich danke auch dir recht herzlich dafür, dass du die Möglichkeiten nutzt, um hier Hilfe zu organisieren. Nur leider sieht man, dass es unendlich schwer sein wird etwas zu erreichen.
@rico said in Verbindungsabbrüche:
Da muss einer ran der das Problem hat, im Optimalfall ohne weitere Nebenkriegsschauplätze.
Ich glaube, ich habe meine Hardwareprobleme wieder im Griff und werde die Sache weiter beobachten. Die Abstürze, die nach ein paar Stunden auftraten, sind wohl wieder verschwunden und die pfSense läuft nun fast 2 Tage ohne Probleme. Ich werde jetzt nichts mehr daran verstellen und die Sache einfach weiter beobachten. Sobald es irgendwelche Neuigkeiten gibt, melde ich mich unverzüglich.
@jegr said in Verbindungsabbrüche:
@Rico Geht mir leider - trotz Unitymedia ;) - auch so, daher kann ich da auch so gar nichts zu sagen. Leider.
Naja, falls du die Provider-FritzBox hast, kannst du das, denke ich, sehr einfach nachstellen. Unitymedia hat vor ein paar Wochen den Bridge-Modus Menüpunkt auf eigenen Geräten wieder sichtbar gemacht, sodass du diesen einrichten und mit einer dahintergeschalteten pfSense testen könntest.
Das Problem tritt eben dann auf, sobald die pfSense eine IP direkt von UM bezieht und nicht hinter doppeltem NAT mit einer festen IP hängt. -
Testest du jetzt wieder mit gepatchter dhclient oder der Originalen?
-Rico
-
@Rico
Ich habe jetzt die gepatchte drauf. -
@un1que said in Verbindungsabbrüche:
Ich danke auch dir recht herzlich dafür, dass du die Möglichkeiten nutzt, um hier Hilfe zu organisieren. Nur leider sieht man, dass es unendlich schwer sein wird etwas zu erreichen.
Das es schwer ist - ja da gebe ich dir recht. Allerdings kann ich das auch verstehen, denn wie schon gesagt: An einem sehr sehr viel genutzten Bestandteil des Basissystems herumzusägen, da tut man sich nicht gerade leicht, mal so eben einen ungetesteten und unbekannten Patch reinzudübeln. Vor allem wenn es an genau der Stelle deshalb schonmal gefunkt hat und ein kleiner Personenkreis/Patch dann plötzlich das Ding für annähernd alle unbrauchbar gemacht hat. Insofern kann ich den im Ticket geäußerten Respekt davor schon gut nachvollziehen, zumal im FreeBSD Ticket selbst überhaupt nichts dafür getan wird, keine Abnahme erfolgt und niemand sich den Code überhaupt mal anschaut. Schwierig...
Unitymedia hat vor ein paar Wochen den Bridge-Modus Menüpunkt auf eigenen Geräten wieder sichtbar gemacht, sodass du diesen einrichten und mit einer dahintergeschalteten pfSense testen könntest.
Das Problem tritt eben dann auf, sobald die pfSense eine IP direkt von UM bezieht und nicht hinter doppeltem NAT mit einer festen IP hängt.Jein, UM ist immer noch MAC Adress gebunden. Man müsste das Gerät online ummelden/anmelden, damit es eine IP bekommt. Oder ich müsste die MAC der FB immitieren, die ich allerdings auf Kabelseite nicht wirklich kenne. Nicht wirklich sehr schön - zudem dann meine Telefone flöten gehen. Wäre es nur ein Laboranschluß, kein Problem.
Zudem muss ich sagen, dass der Menüpunkt (trotz 7.01 Update) bei mir nirgends aufgetaucht ist.Grüße
-
@jegr said in Verbindungsabbrüche:
Jein, UM ist immer noch MAC Adress gebunden. Man müsste das Gerät online ummelden/anmelden, damit es eine IP bekommt. Oder ich müsste die MAC der FB immitieren, die ich allerdings auf Kabelseite nicht wirklich kenne. Nicht wirklich sehr schön - zudem dann meine Telefone flöten gehen. Wäre es nur ein Laboranschluß, kein Problem.
Nee, UM bindet deinen Vertrag an die MAC Adresse des Kabelmodems, nicht des Routers. Von daher stellt das absolut kein Problem dar und es wird sich auch nichts an der Telefonie ändern.
Vielmehr kannst du, falls du noch zusätzliche Hardware zum Testen zur Hand hast, so einen zweiten Anschluss simulieren und den zweiten Router am Bridge Anschluss nebenbei betreiben, ohne dass sich etwas am Hauptanschluss der FritzBox tutDas habe ich schon mal vor einiger Zeit getestet, wo der Bridge-Modus noch nicht halb-offiziell freigeschaltet wurde. Damals musste ich den FB-Editor bemühen und den Menüpunkt selbst sichtbar machen.
Zudem muss ich sagen, dass der Menüpunkt (trotz 7.01 Update) bei mir nirgends aufgetaucht ist.
Sicher?
https://www.unitymediaforum.de/viewtopic.php?f=90&t=37511Ist sogar schon mit der FW 6.88 passiert. Kommst du vllt. aus BW oder Hessen? Das wäre die einzig mögliche Erklärung, denn in NRW sollte der Punkt auf jeden Fall da sein.
P.S. Ich bin mir jetzt nicht ganz sicher, ob man dafür evtl. noch den Wifi-Spot im Kundencenter einrichten soll. Aber keine Sorge, der funktioniert auf den Fritten sowieso nicht
Hintergrund war (als ich es noch vor 1-2 Jahren getestet habe), dass durch die Einrichtung des Wifi-Spots man im config File die "Erlaubnis" zugeteilt bekommen hatte, eine zweite IP nutzen zu dürfen. Ansonsten konnte man wohl den Bridge-Modus zwar einrichten und hatte auch eine IP zugewiesen bekommen, es ging aber kein Traffic durch. -
@un1que said in Verbindungsabbrüche:
Ist sogar schon mit der FW 6.88 passiert. Kommst du vllt. aus BW oder Hessen? Das wäre die einzig mögliche Erklärung, denn in NRW sollte der Punkt auf jeden Fall da sein.
Richtig. Bei mir ist da (noch) nichts ;)
-
@jegr
Könnte dann wohl tatsächlich daran liegen. Falls du aber irgendwann mal Zeit und Lust hast hierbei noch weiterzuhelfen (und als Bonus einen Zweitanschluss zum Testen einzurichten), könntest du ja mal mit dem FB-Editor ein wenig rumspielen und den Bridge-Modus selbst freischalten
-
@un1que Wäre das ein Testanschluß - klar. Da das aber produktiv zu Hause ist und ich mir ungern den Unbill von Frau und Kindern zuziehe und ich irgendwann auch einfach mal Feierabend und Erholung brauche wird das eher dann was, wenn ich das bei Kunden direkt haben sollte oder die Möglichkeit das bei jemand anderem zu debuggen.
-
-
@un1que said in Verbindungsabbrüche:
Mal eine kurze Rückmeldung zwischendurch. Die pfSense läuft nun seit ziemlich genau 5,5 Tagen durch, ohne EXPIRED Einträge beim dhclient. Sieht schon mal sehr gut und vielversprechend aus!
das klingt doch schonmal wirklich gut
-
Eigentlich gibt es auch keinen Grund, dass Code der in OPNsense funktioniert das nicht in pfSense tut.
-Rico
-
@rico Da es sich um zwei unterschiedliche FreeBSD Versionen handelt und OPN noch dazu von HardenedBSD und nicht direkt FreeBSD abgeleitet ist -> doch.
-
Ich meine natürlich nur die dhclient und da ist der Code exakt gleich.
-Rico
-
Jetzt müsste man nur irgendwie die FreeBSD Devs überzeugen, die Änderung im Code zu übernehmen... ansonsten sieht es recht aussichtslos, dass der DHCP nativ auf der pfSense einwandfrei mit Unitymedia funktioniert.
... oder abwarten, bis Vodafone den Laden übernommen und bissl Ordnung mitgebracht hat
Btw. die pfSense rennt nun seit mehr als 7 Tagen ohne EXPIRED Einträge, ich bin begeistert! Besten Dank nochmal @Rico!
Ach und ich habe herausgefunden, woher die Einbrüche aus diesem Post stammen. Als ich vor einiger Zeit das WAN Interface und alles drum herum neu eingerichtet habe, habe ich beim WAN keine explizite IP zum Überwachen festgelegt und der Ping ging an die Gateway IP von Unitymedia.
Naja, und wie bei Unitymedia Sachen funktionieren... ist es kein Wunder, dass dieses hin und wieder nicht erreichbar/anpingbar war. Seitdem ich eine andere IP eingegeben habe, sind auch die genannten Einbrüche verschwunden. -
Als Monitor IP empfielt sich der Google DNS 8.8.8.8
-Rico
-
@Rico
Ich habe die 1.1.1.1 von Cloudflare genommen. Sollte ja nicht weniger zuverlässig sein?
