Verbindungsabbrüche



  • Da habe ich mich zu früh gefreut ☹

    Die Abbrüche sind wieder da und zwar wieder in gleichen Abständen wie früher auch. Frage mich nur, wieso es bei bestimmten Umstellungen auf einmal für ein paar Tage lang gut geht und dann zum gewohnten Rhythmus wieder zurückkehrt.

    Kotzt mich aber schon an, dass die pfSense Entwickler da nichts unternehmen wollen, auch wenn davon evtl. nur eine Handvoll Nutzer betroffen ist.


  • LAYER 8 Rebel Alliance

    Wo steht dass die Entwickler da nichts unternehmen WOLLEN?
    Hast du mal einen Bug Report auf englisch erstellt? Soweit ich weiß gibt es keinen deutschen pfSense Entwickler, evtl. wissen die davon gar nichts.
    Mal im englischen Bereich einen Thread öffnen mit ordentlicher Fehlerbeschreibung, Logs, etc. wäre ja mal ein Anfang.

    -Rico



  • @Rico
    Nicht ich, aber ja, ein entsprechender Bug Report wurde bereits erstellt:
    https://redmine.pfsense.org/issues/7416

    Damit fing es hier im Forum an:
    https://forum.netgate.com/topic/112869/dhclient-on-wan-occasionally-fails-to-renew-lease-with-cable-isp


  • LAYER 8 Rebel Alliance

    Ihr müsst den Bug Report bei FreeBSD machen, nicht pfSense:
    0_1546955136491_br.png

    -Rico



  • @Rico
    Ich habe mich mit dem User per PN unterhalten und er meinte wohl, dass er das entsprechend bei FreeBSD eingereicht hat, keine Ahnung was daraus geworden ist.

    Er war jedenfalls sehr unzufrieden (so wie ich es mittlerweile auch bin), dass seitens pfSense ungenügend zur Problemlösung beigetragen wurde bzw. man sich absolut nicht dafür zuständig fühlt. Für ihn wäre die Sache aber erledigt, da er zu Opnsense gewechselt ist, weil dort dieser Bug sehr schnell behoben wurde (das bestätigt meine These, dass pfSense Entwickler sich dafür nicht interessieren).
    Ich wäre vllt. auch schon zu Opnsense gegangen, wenn nicht einige Dinge, durch welche ich mich an pfSense gebunden habe.


  • LAYER 8 Rebel Alliance

    Was ist mit dem Workaround der im Ticket genannt wurde, hilft nicht?

    -Rico



  • @Rico
    Meinst du die angehängte Datei "dhclient.c"? Aber was mache ich damit?


  • LAYER 8 Rebel Alliance

    Ich habe die mal gebaut für AMD64, Datei im Anhang. [DOWNLOAD ENTFERNT]
    Alles völlig ohne Gewähr, da ich für FreeBSD auch noch nie kompiliert habe. Vorher unbedingt ein Backup erstellen!

    Backup der dhclient:

    cd /sbin
    mv dhclient dhclient.orig
    

    Dann die dhclient aus der ZIP nach /sbin kopieren und die Rechte anpassen:

    chmod 555 /sbin/dhclient
    

    libcasper.so.1 aus der ZIP kopieren nach /lib
    libcap_syslog.so.1 aus der ZIP kopieren nach /lib/casper/

    pfSense dann neu starten, bei mir hat der dhclient jedenfalls noch funktioniert und eine IP gezogen. ;-)

    Dann musst du noch wie im Bugtracker beschrieben folgendes machen:
    "The problem can be avoided by setting DHCP option 54 (dhcp-server-identifier) to 255.255.255.255 via Interfaces->WAN->Advanced configuration->Option Modifiers"

    Falls alles komplett schief geht kannst du in /sbin die Datei dhclient löschen und dhclient.orig umbenennen nach dhclient, nach pfSense reboot ist alles wieder wie davor.

    -Rico



  • @Rico
    Wow, vielen Dank dafür! Eine Bitte hätte ich aber noch: ich glaube den Bug Report bei FreeBSD gefunden zu haben:
    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217978

    Dort ist scheinbar auch ein funktionierender Fix vorgeschlagen worden, k.a. Ahnung aber warum nichts mehr daraus geworden ist. Was ich halt sagen möchte: der Fix hat ein späteres Datum als die Datei aus dem Bug Report bei Redmine. Könntest du die Zeilen vllt. anpassen und entsprechend neu kompilieren? Ich wäre dir sehr dankbar dafür!


  • LAYER 8 Rebel Alliance

    Schaue mir das morgen nochmal an und baue den entsprechend um.
    Du bist auf pfSense 2.4.4 ?

    -Rico



  • @Rico
    Oh, das wäre echt super lieb von dir! Ja, habe die Version 2.4.4_1 drauf.


  • LAYER 8 Rebel Alliance

    Anbei die Datei auf Basis von dem von dir verlinkten Patch.
    [DOWNLOAD ENTFERNT]

    -Rico



  • @Rico
    Super, vielen Dank dafür! Ich probiere es heute Nachmittag aus und sage Bescheid, ob alles geklappt hat.



  • @Rico
    Hmm, irgendetwas läuft wohl nicht rund. Was mir als allererstes aufgefallen ist - diese Meldungen (connection closed ist doch nicht normal oder?):

    Jan 9 14:33:03 	dhclient 	17460 	exiting.
    Jan 9 14:33:03 	dhclient 	17460 	connection closed
    Jan 9 14:33:03 	dhclient 	17460 	bound to [IP] -- renewal in 1561 seconds.
    

    Danach hat es mehrere Anläufe gebraucht, bis ich "supersede dhcp-server-identifier 255.255.255.255" in die Option modifiers eingetragen habe und es endlich lief.

    Kürzlich ist die Verbindung einfach weggebrochen und ich bekam keine IP mehr, auch Renew half nicht weiter. Nach einem Restart kommen zwar wieder die o.g. Meldungen, aber es läuft wieder.
    Keine Ahnung, ob das nicht evtl. wieder mal an Unitymedia gelegen hat, weil ich jetzt wieder eine neue IP habe, obwohl sich diese sehr selten ändert. Ich schaue mal weiter.

    *edit:
    Ne, wird wohl nix. Soeben schon wieder einen Ausfall gehabt, wo sich nichts mehr tat und nur durch einen Neustart beheben lies.


  • LAYER 8 Rebel Alliance

    Ist völlig normal wenn z.B. das Interface down geht, oder du eine Option bei dem Interface änderst und dann Save/Apply machst.
    Ich habe gerade mit der original dhclient von pfSense 2.4.4-p2 in den WAN Option modifiers 'supersede dhcp-server-identifier 255.255.255.255' eingetragen, Save/Apply gemacht und auch die Meldung im Log erhalten:

    Jan 9 18:40:24 	dhclient 	90445 	connection closed
    Jan 9 18:40:24 	dhclient 	90445 	exiting. 
    

    -Rico



  • @Rico
    Ja gut, aber ich meinte einen kompletten Verbindungsverlust nach einem gewissen Zeitraum, wo sich das Interface nicht mehr erholt und nur noch auf Down steht. Auch nach längerem Warten passiert nichts.


  • LAYER 8 Rebel Alliance

    Und das war nun zum ersten mal überhaupt der Fall?
    Kann mir kaum vorstellen dass der dhclient generell dafür verantwortlich sein kann dass ein Interface komplett down ist.

    -Rico



  • @Rico
    Ja, genau, früher hatte ich so etwas noch nie. Jetzt passierte es aber schon 2 mal innerhalb von lediglich ein paar Stunden (habe dann aber auch die originale Datei zurückkopiert, da ich mir einen längeren Ausfall nicht erlauben kann, wenn ich aus dem Haus gehe).

    Das Problem war, dass die Internetverbindung ganz wegbrach und das ohne irgendwelche Logeinträge. Beim ersten mal habe ich es nicht sofort gemerkt und nachdem die Sense fast eine halbe Stunde ohne Internetverbindung auch nicht per Renew eine IP gezogen hat, musste ich neustarten. Beim nächsten mal wieder dieselbe Geschichte. Vielleicht verhakt sich etwas, sodass irgendwann gar keine Requests mehr rausgehen?


  • LAYER 8 Rebel Alliance

    Nochmal damit testen: [DOWNLOAD ENTFERNT]

    -Rico



  • @Rico
    Danke, das sieht auf den ersten Blick besser aus: keine "connection closed" oder "exiting." Einträge mehr im Log. Ich werde das jetzt mal weiter beobachten und bei allen Auffälligkeiten berichten.

    edit: Ach, mir ist gerade noch folgendes eingefallen:

    1. Soll ich jetzt libcasper.so.1 und libcap_syslog.so.1 aus der alten ZIP Datei übernehmen oder ganz weglassen?
    2. Hattest du deinen letzten Beitrag editiert? In meiner Benachrichtigungsmail steht was von "0_1547128287746_dhclient.zip" und hier im Forum "0_1547138580460_dhclient.zip", beim Download kommt jedoch die Datei: "1547138582931-dhclient.zip". Die letztgenannte ist hoffentlich die richtige?

  • LAYER 8 Rebel Alliance

    Die so.1 Files solltest du mit der Neuen nicht mehr brauchen.
    Ja ich hatte nach dem Posten noch ein Problem gefunden, dann editiert und neu hochgeladen. Die Dateinamen werden vom Board so generiert, weiß nicht was da beim Editieren nun schief ging.
    Welche Größe hatte deine Zip denn jetzt?

    -Rico



  • @Rico
    Ok, habe ich mir schon gedacht. Die Zip ist 49KB und die dhclient Datei nach dem Entpacken 113KB groß.


  • LAYER 8 Rebel Alliance

    Dann sollte es eigentlich passen, hier zur Sicherheit aber nochmal: [DOWNLOAD ENTFERNT]
    Die anderen Downloads weiter oben entferne ich zur Sicherheit alle da es damit wohl nicht funktioniert und bevor die ein anderer lädt und probiert...

    -Rico



  • @Rico
    Alles klar, danke nochmal. Ich melde mich.



  • @Rico
    Hmm, heute gab es einen Absturz, k.A. ob es damit zusammenhängt. Ich werde die Sache weiter beobachten.


  • LAYER 8 Rebel Alliance

    Absturz inwiefern? Was steht in den Logs dazu?

    -Rico



  • Die pfSense hat nicht mehr reagiert und hat sich nach einer Weile neugestartet. Ich sehe nichts, außer den beim Start angelegten Logs. Damit geht doch der Boot-Vorgang los oder?
    kernel boot file is /boot/kernel/kernel


  • LAYER 8 Rebel Alliance

    Status > System Logs

    -Rico



  • Ja, das meinte ich. Es geht damit los (wenn ich mich nicht irre, sind das aber bereits die Logs, die beim Bootvorgang angelegt werden oder?):

    Jan 11 12:44:44 	kernel 		current process = 82667 (pfctl)
    Jan 11 12:44:44 	kernel 		processor eflags = interrupt enabled, resume, IOPL = 0
    Jan 11 12:44:44 	kernel 		= DPL 0, pres 1, long 1, def32 0, gran 1
    Jan 11 12:44:44 	kernel 		code segment = base 0x0, limit 0xfffff, type 0x1b
    Jan 11 12:44:44 	kernel 		frame pointer = 0x28:0xfffffe0114fdf440
    Jan 11 12:44:44 	kernel 		stack pointer = 0x28:0xfffffe0114fdf320
    Jan 11 12:44:44 	kernel 		instruction pointer = 0x20:0xffffffff80d72f70
    Jan 11 12:44:44 	kernel 		fault code = supervisor read data, page not present
    Jan 11 12:44:44 	kernel 		fault virtual address = 0x18
    Jan 11 12:44:44 	kernel 		cpuid = 3; apic id = 06
    Jan 11 12:44:44 	kernel 		Fatal trap 12: page fault while in kernel mode
    Jan 11 12:44:44 	syslogd 		kernel boot file is /boot/kernel/kernel 
    

    Danach kommt halt das und der Rest:

    Jan 11 12:44:44 	kernel 		FreeBSD 11.2-RELEASE-p4 #2 b00c407ba5d(RELENG_2_4_4): Mon Nov 26 11:41:48 EST 2018
    Jan 11 12:44:44 	kernel 		FreeBSD is a registered trademark of The FreeBSD Foundation.
    Jan 11 12:44:44 	kernel 		The Regents of the University of California. All rights reserved.
    Jan 11 12:44:44 	kernel 		Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    Jan 11 12:44:44 	kernel 		Copyright (c) 1992-2018 The FreeBSD Project. 
    

  • LAYER 8 Rebel Alliance

    Und das Problem hattest du vorher noch nie?

    -Rico



  • Sehr selten, aber hin und wieder schon paar mal gehabt. Deswegen habe ich das nur mit Vorsicht erwähnt. Es sollte nicht heißen, dass es am dhclient liegt, wollte es vollständigkeitshalber nur erwähnt haben.

    Ich werde die Sache weiter beobachten und nur, wenn das Problem jetzt immer wieder auftreten sollte, könnte es einen Zusammenhang geben. Aber hoffen wir mal, dass es lediglich eine Einzelaktion war.


  • LAYER 8 Rebel Alliance

    Das hört sich auch eher nach Hardware extrem überlastet oder defekt an.
    Was für eine Box hast du überhaupt?

    -Rico



  • Echt? Wie kann ich herausfinden, ob ein Hardwaredefekt vorliegt (die Herstellergarantie dürfte sehr bald zu Ende sein...)?

    Ist ein Selbstbau aus einem Supermicro X11SBA-LN4F Board (hat eine integrierte N3700 CPU) mit 4GB Arbeitsspeicher.


  • LAYER 8 Rebel Alliance

    x86 Hardware teste ich immer mit memtest86 und danach Prime, jeweils min. 48 Stunden.
    Aber schau doch erst mal generell nach der Auslastung deiner Box/Prozesse/Packages.

    -Rico



  • Beim Arbeitsspeicher sieht gut aus: teilweise sind um die 60% frei und in den schlimmsten Fällen immer noch ca. 25% - dürfte also im Rahmen liegen?

    Bei der CPU sehe ich so auf den ersten Blick keine Auffälligkeiten. Die Last ist recht konstant und dann kommt der Absturz.
    Für mich sind aber die ganzen Werte, die unter Status/Monitoring/System-Processor ausgegeben werden recht unverständlich. Wo kann ich dessen Bedeutung nachlesen?

    Ansonsten habe ich hin und wieder per Kommandozeile mit "top" die Auslastung in bestimmten Situationen beobachtet. Normalerweise (also bei normalem täglichen Bedarf) werden so 70-90% Idle angezeigt. Um die CPU sehr gut auszulasten, muss man schon mal ordentlich was machen.

    Packages habe ich von den anspruchsvollen lediglich pfBlocker und nTop, wobei der letztere seit 2-3 Monaten ausgeschaltet ist und nur bei Bedarf eingeschaltet und verwendet wird.
    Ansonsten sind noch Acme, Avahi (aus), Cron (unbenutzt), openvpn-client-export, RRD_Summary, Shellcmd und Status_Traffic_Totals installiert. Ich denke mal, dass diese das System nicht wirklich beanpruchen dürften.


  • LAYER 8 Rebel Alliance

    Ich habe nochmal eine kleine Korrektur an der dhclient vorgenommen, die finale Version hier: 0_1547227517977_dhclient_20190111.zip
    Hat aber mit deinem Box Absturz Thema nichts zu tun.

    -Rico



  • @Rico
    Danke! Mal eine Frage: angenommen, durch deinen Patch würde die Sache tatsächlich besser werden, was passiert danach (außer der Tatsache, dass ich dir unendlich dankbar dafür wäre)?
    Mit jedem Upgrade der pfSense könnte es ja dazu kommen, dass beim dhclient Neuerungen/Verbesserungen hinzukommen und die Datei geupdated wird. Ok, man könnte diese dann immer noch austauschen, aber irgendwann könnte auch mal ein Update kommen, wo die Datei nicht mehr kompatibel sein wird. Was dann?
    Ich möchte eigentlich darauf hinaus, ob du dir nicht evtl. vorstellen könntest, deinen Patch an die pfSense Entwickler weiterzuleiten, damit dieser eingepflegt wird oder ist so etwas unüblich?


  • LAYER 8 Rebel Alliance

    Ein funktionierender Patch ist ja, da er sich aber auf das FreeBSD-src Repository bezieht meinen die Devs das muss von FreeBSD Seite gefixt werden, was vom Prinzip her ja auch korrekt ist.
    Das FreeBSD-src Repository soll denke ich mal so weit wie möglich original bleiben, Änderungen kommen nur von FreeBSD selbst da rein (im Optimalfall).

    -Rico



  • @un1que said in Verbindungsabbrüche:

    Ist ein Selbstbau aus einem Supermicro X11SBA-LN4F Board

    Diese Supermicro Board hatte bis zur rev 1.01 arge Probleme mit der LAN-Ports 2-4!
    Diese hängen an PCIe 2.0 x1. Eine optimale Lösung sieht meiner Meinung nach
    anders aus.

    0_1547285943904_X11SBA-LN4F.png

    Mehr dazu hier.

    Spielt das o.g. das Problem hier eine Rolle?

    LG



  • @rico said in Verbindungsabbrüche:

    Ein funktionierender Patch ist ja, da er sich aber auf das FreeBSD-src Repository bezieht meinen die Devs das muss von FreeBSD Seite gefixt werden, was vom Prinzip her ja auch korrekt ist.
    Das FreeBSD-src Repository soll denke ich mal so weit wie möglich original bleiben, Änderungen kommen nur von FreeBSD selbst da rein (im Optimalfall).

    -Rico

    Dann lässt sich bei pfSense wohl tatsächlich nichts machen. Magst du vllt. deine Version des Patches bei FreeBSD hochladen (evtl. in den bereits existierenden Bug Report), wenn ich mit dem Testen fertig bin? Ich kann mich dort auch mal eben Registrieren und eine "Empfehlung" aussprechen, falls das die Sache irgendwie beschleunigen sollte (keine Ahnung wie das ganze funktioniert 😕 ).

    @Gladius
    Ja, die Probleme mit den ersten Revisionen des Supermicro Boards kenne ich, siehe hier: https://forum.netgate.com/topic/97216/ständige-verbindungsabbrüche-pfsense-hinter-kabelmodem
    Aber ich habe damals ein Austauschboard der Rev. 1.02 bekommen.

    @gladius said in Verbindungsabbrüche:

    Spielt das o.g. das Problem hier eine Rolle?

    Ich glaube nicht. Schließlich bin ich nicht der einzige mit diesem Problem (siehe Anfang des Threads und hier). Das liegt auf jeden Fall daran, wie Unitymedia (evtl. auch andere Liberty Global ISP's) mit den DHCP Requests und deren Beantwortung umgeht (mehr dazu in dem o.g. Thread) und der Tatsache, dass man bei pfSense es nicht mit Boardmitteln fixen kann.
    Oder meintest du mein Problem mit den sporadischen Abstürzen?