Verbindungsabbrüche
-
Hallo,
ich habe hier noch ein komisches Problem, welches bereits seit einiger Zeit besteht (evtl. seit dem Umstieg auf die 2.4 Beta oder einem anderen Grund) und mal 1-2x mal am Tag auftritt, mal läuft es ein paar Tage fehlerfrei.
Die pfSense ist dann für ca. 2-5 Minuten über das WebGUI nicht erreichbar und es können in dem Moment keine neuen Verbindungen ins Internet aufgebaut werden. Sprich, Internet geht nicht, aber - was mich am meisten wundert - bspw. IPTV läuft problemlos und unterbrechungsfrei weiter.Es beginnt alles mit den folgenden Meldungen in System Logs:
Oct 24 21:23:08 kernel arpresolve: can't allocate llinfo for [Monitor IP des Gateways] on igb2
Danach werden wohl alle Dienste neu geladen und es läuft weiter. Seit einiger Zeit sehe ich außerdem Notifications mit dem folgenden Inhalt:
pf_busy
PF was wedged/busy and has been reset. @ 2017-10-24 21:26:28
Filter Reload
There were error(s) loading the rules: pfctl: DIOCXCOMMIT: Device busy - The line in question reads [0]: @ 2017-10-24 21:26:29
Ich habe bereits diese Fehlermeldungen gegoogelt und oft gelesen, dass das in dem Moment passiert, wenn das Kabelmodem offline geht. Bei mir ist es eine FB6490, welche im Bridge Modus läuft. Wenn ich aber in der Zeit über den integrierten Router der FB ins Internet gehe (hat zwar eine eigene IP…), dann funktioniert das problemlos. Es dürfte demnach nicht am Modem liegen, zumal ja auch IPTV weiterläuft, richtig?
Hat jemand eine Idee, wie ich dieses nervige Problem beseitigen kann?
-
Hat keiner eine Idee / Erklärung dafür? :-[
-
Hast du die Kiste mit pfBlocker laufen? :)
-
Ein möglicher Grund für die DIOCXCOMMIT-Fehlermeldung ist anscheinend auch die automatische Geschwindigkeitsaushandlung der LAN-/WAN-Karte. (https://detlev.bluelf.me/2015/06/14/pfsense-error-pfctl-diocxcommit/)
Setz mal eine feste Geschwindigkeit und warte, ob es weiterhin passiert. -
@JeG: Ja, wieso? Liegt es etwa an dem pfBlocker? Kann man das irgendwie umgehen?
@Birke: Ok, danke für den Tipp, werde ich ausprobieren. Mittlerweile kommen gleich 3 Meldungen zu einem Ereignis :o
Aber das Hauptproblem sind ja wohl diese nervigen Abbrüche, ohne würden ja wohl keine Fehlermeldungen erzeugt werden. -
@JeG: Ja, wieso? Liegt es etwa an dem pfBlocker? Kann man das irgendwie umgehen?
Weil der Fehler in der Diagnose gern bei/mit pfBlocker aufgetreten war/ist. Wenn ich mich recht erinnere in Verbindung mit IPv6 Tunnel, DHCP auf WAN und pfBlockerNG aktiv.
-
IPv6 habe ich nicht, IPv4-only (mit DHCP auf WAN). Aber wie man das lösen kann, weißt du wohl auch nicht, ne? Hmm, schade.. manchmal nervt es echt, wenn man genau diesen Zeitpunkt beim Surfen erwischt.
Die einzige Möglichkeit (welche leider mit anderen Einschränkungen verbunden ist) wäre wohl nur das Monitoring komplett auszuschalten und zu sagen, das Gateway wäre immer verfügbar?
-
Also, nachdem ich WAN von Auto auf feste Geschwindigkeit umgestellt habe, gab es zunächst gar keine Meldungen (trotz Verbindungsabbrüchen). Mittlerweile kommen die Meldungen aber trotzdem wieder und zwar nach dem Zufallsprinzip. Mal sind es wieder 3 Stück pro Abbruch, mal nur eine. Ob es "ungemeldete" Ereignisse gibt, kann ich nicht sagen, da ich es nicht so oft beobachte - müsste man schon 2-3x täglich machen, da bei mir das Log mit 1000 Ereignissen nach nur 2 Abbrüchen total zugespamt wird.
Ich werde jetzt einfach mal Disable Gateway Monitoring Action probieren. Liege ich richtig mit der Annahme, dass dadurch die "can't allocate …"-Meldungen nach wie vor kommen würden, die Verbindung aber weiterhin funktionieren sollte (ich meine, das tut sie ja bei Live-Streams, warum also nicht beim Surfen o.ä.)?
-
Ich habe das gleiche Problem. Inzwischen eine Lösung vorhanden?
-
Ne, leider nicht. Diese blöden Aussetzer treten nach wie vor ab und zu auf, zum Glück passiert das meist nachts oder zu Zeiten, wo das Internet nicht wirklich aktiv genutzt wird (sodass man es zumindest nicht so wirklich wahrnimmt). Aber sehr ärgerlich ist das allemal.
Keine Ahnung, ob das an der evtl. instabileren Kabelinternet-Verbindung liegt oder doch irgendwie nur im Zusammenhang mit dem pfBlocker auftritt. Verzichten kann ich auf keinen der beiden Dinge, sodass ich mich schon irgendwie damit abgefunden habe, in der Hoffnung, dass es sich irgendwann mal von selbst auflösen wird :-[
Mal eine Gegenfrage: hast du auch Kabelinternet oder DSL? Falls ersteres, bei welchem Provider bist du und welches Zugangsgerät hast du?
-
Ich habe Kabel bei Unitymedia und nutze ein eigenes TC4400 Modem. Zuvor ein Unitymedia Cisco Modem, da war das Problem ebenfalls vorhanden.
-
Ich hab das Problem nun etwas eingegrenzt. Der Abbruch tritt auf, sobald der DHCP Lease am WAN abgelaufen und neu gezogen wird. Hier vergeht augenscheinlich zuviel Zeit in der das Standardgateway (welches beim ISP steht) nicht mehr mitgeteilt, bzw. genutzt werden kann. Ich habe nun einen Workaround indem ich den Leasetime bzw. das Timeout erhöht habe auf 24 Stunden. Hierzu die Advanced DHCP options einblenden und bei Timeout einen Wert in Minuten eintragen.
-
Sicher, dass es tatsächlich am DHCP Lease liegt? Ich frage, weil es (zumindest bei mir) total unregelmäßig eintritt. Manchmal können mehrere Tage ohne diese Abbrüche überbrückt werden und manchmal treten sie sogar bis zu 2x am Tag auf.
Mittlerweile glaube ich auch, dass es irgendwie im Zusammenhang mit dem pfBlocker Package steht. Habe irgendwo im englischen Teil des Forums gelesen, dass jemand es mit einer kompletten Neuinstallation (inkl. -einrichtung) gelöst habe. Allerdings wurde dabei der pfBlocker ausgelassen.
Btw. ich finde es schon sehr seltsam bzw. eher überraschend, dass das TC4400 keine Besserung bringt. Ich habe gedacht, dass dieses Problem evtl. etwas mit diesem "Puma-Bug" zu tun haben könnte, was man jetzt aber wohl ausschließen kann.
P.S. Ich werde jetzt evtl. noch versuchen, eine feste IP einzutragen (statt DHCP Lease Erhöhung). Ich meine, wenn es tatsächlich daran liegt, dann müsste sich das Problem mit der fest eingetragenen IP in Luft auflösen. So hätten wir zumindest die Ursache herausgefunden.
-
Zumindest bei mir war das wohl der Fall, denn es war auch sehr regelmäßig und nun ist es seitdem weg.
-
Wenn ich dich jetzt richtig verstehe, läuft es bei dir nun durchgängig problemlos und ohne Abbrüche? Wie lange schon?
Du hast also nur den Timeout-Wert auf 1440 geändert und dabei alle anderen Felder leer gelassen?
-
Hallo un1que,
welche Hardware hast du im Einsatz, bzw. welche Typ Netzwerkkarten.
ich habe mit ähnlichen Problemen zu kämpfen und ich habe die Intel i211 Netzwerkkarten bei mir die die Probleme verursachen.
Die Probleme traten bei mir ab einer bestimmten Version der 2.4er auf mit der 2.3er Version läuft alles einwandfrei.
Ich vermute mal dass es hier eine Änderung der Treiberversion der Netzwerkkarten gab.
In anderen Foren habe ich u.a. auch über Probleme mit FreeBSD und der Intel i211 Karten gelesen welche auf EEE (energy efficient ethernet) in zusammenhang stehen.
ich habe allerdings noch keine Lösung dafür gefunden.Gruß
Beelzeboss -
Ich glaube, dass ich die I210 NIC‘s habe (bei mir werkelt ein Supermicro MB mit der N3700 CPU - SoC, die genaue Bezeichnung habe ich nicht im Kopf). Habe auch schon überlegt, ob es nicht evtl. an den Treibern liegen könnte, da auch ich keinerlei Probleme bei der v2.3 hatte.
Die Lösung von mrsunfire scheint das Problem zu mildern, aber nicht komplett zu beseitigen, zumindest bei mir nicht. Jetzt kommen die Abbrüche lediglich alle drei Tage, statt früher bis zu 1-2 mal am Tag. Ist zwar deutlich angenehmer, aber mir wär‘s lieber, wenn sie völlig verschwinden würden.
-
Bei mir ist es nun auch alle 3 Tage. Jedoch so kurz dass man es nicht mitbekommt. Problem ist halt dass die pfSense das Standartgateway nicht nutzt so lange es via DHCP angefragt wird. Selbst wenn es gleich bleibt.
-
Naja, zu früh gefreut. Jetzt kommt es teilweise wieder häufiger vor… ich würde sogar sagen, dass es deutlich häufiger auftritt als vor der Umstellung. Wobei ich auch anmerken muss, dass ich trotz der öfteren Abbrüche bisher keinen davon live erlebt habe - früher waren diese schon hin und wieder deutlich spürbar. Mag also stimmen, dass diese nun schneller verschwinden / nicht so lange andauern.
Hier mal ein Auszug aus dem Log:
16.02. 13:05
17.02. 08:48
17.02. 22:16
18.02. 00:09
18.02. 15:23
18.02. 22:45
19.02. 06:52 -
da ihr beide ja intel chips nutzt: welchen treiber nutzt eure pfsense, den igb oder den ix?
habt ihr die tipps von hier mal getestet?
"Hardware Checksum Offloading", "Hardware TCP Segmentation Offloading" and "Hardware Large Receive Offloading" deaktiviert unter System->Advanced->Networking? -
"Hardware Checksum Offloading", "Hardware TCP Segmentation Offloading" and "Hardware Large Receive Offloading" deaktiviert unter System->Advanced->Networking?
Bis auf "Hardware Checksum Offloading" sind die anderen beiden bei mir deaktiviert (bzw. das "Disable…" angehakt - so ist es auch gemeint oder?).
da ihr beide ja intel chips nutzt: welchen treiber nutzt eure pfsense, den igb oder den ix?
habt ihr die tipps von hier mal getestet?Danke für den Tipp, ich werde es heute-morgen mal testen und natürlich wieder berichten. Bei mir ist es der igb Treiber.
-
bzw. das "Disable…" angehakt - so ist es auch gemeint oder?
ja, genau. etwas blöd ausgedrückt von mir :)
-
Hat jetzt leider doch etwas länger gedauert als angenommen, aber ich habe mittlerweile die empfohlenen System Tunables angepasst und Hardware Checksum Offloading deaktiviert. Jetzt bleibt es also nur noch abzuwarten…
Bin übrigens bei der Dokumentation auf den Begriff Flow Control gestoßen (und dass man diesen in bestimmten Fällen ausgeschalten soll?). Kann mir jemand erklären, was es damit auf sich hat und ob es in meiner Situation evtl. auch irgendwie behilflich sein könnte?
-
Ne, das hat leider auch nicht geholfen :-[
Die Abbrüche sind trotzdem noch da mit der nervigen [i]arpresolve: can't allocate llinfo for … Meldung.Sollte ich noch probieren den Flow Control zu deaktivieren, könnte es etwas bringen?
-
Ich muss das gleiche bestätigen. Ich nutze auch die I211 Intel NIC mit dem igb Treiber und einen i5. Dachte erst es liegt an meiner Hardware, aber scheinbar liegt es doch an der Sense.
-
Hat sich bei jemanden die Lage verbessert, insbesondere bei dir, @mrsunfire ?
Bisher gab es bei mir keine Besserungen, auch nicht mit den neuen Updates. Dann habe ich bei "Hardware Checksum Offloading" den Haken wieder entfernt (denke aber nicht, dass es daran lag) und "Firewall Optimization Options" auf "Normal" umgestellt (war bei mir auf "Conservative").
Ist jetzt zwar nicht soo lange her, aber verhältnismäßig habe ich jetzt eine Ewigkeit keine Abbrüche mehr gehabt (ganze 4 Tage am Stück ). Zuvor immer 1-3 mal am Tag, manchmal mit einem oder höchstens 2 ruhigen Tagen dazwischen.
-
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.
-
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/7416Damit fing es hier im Forum an:
https://forum.netgate.com/topic/112869/dhclient-on-wan-occasionally-fails-to-renew-lease-with-cable-isp -
Ihr müsst den Bug Report bei FreeBSD machen, nicht pfSense:
-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. -
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? -
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=217978Dort 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!
-
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. -
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.