[Gelöst] kernel: arpresolve: can't allocate llinfo for xxx.xxx.xxx.xxx
-
Servus!
Bis vor kurzem lief meine Alix Möhre samt Pfsense einwandfrei. Seit neuestem Update 2.1.5 habe ich, aus heiterem Himmel, täglich meist 1 oder 2 Verbindungsabbrüche auf dem WAN Interface. Im Systemlog steht folgendes:
Sep 6 14:21:13 php: rc.start_packages: Restarting/Starting all packages.
Sep 6 14:21:06 check_reload_status: Reloading filter
Sep 6 14:21:06 check_reload_status: Starting packages
Sep 6 14:21:06 php: rc.newwanip: pfSense package system has detected an ip change 110.92.132.200 -> 110.92.132.200 … Restarting packages.
Sep 6 14:21:04 php: rc.newwanip: Creating rrd update script
Sep 6 14:21:04 php: rc.newwanip: Resyncing OpenVPN instances for interface WAN.
Sep 6 14:20:57 php: rc.newwanip: phpDynDNS (blublub.dyndns.tv): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
Sep 6 14:20:57 php: rc.newwanip: ROUTING: setting default route to 110.92.132.1
Sep 6 14:20:57 php: rc.newwanip: rc.newwanip: on (IP address: 110.92.132.200) (interface: WAN[wan]) (real interface: vr0).
Sep 6 14:20:57 php: rc.newwanip: rc.newwanip: Informational is starting vr0.
Sep 6 14:20:52 check_reload_status: rc.newwanip starting vr0
Sep 6 14:20:51 kernel: arpresolve: can't allocate llinfo for 110.92.132.1
Sep 6 14:20:51 kernel: arpresolve: can't allocate llinfo for 110.92.132.1
Sep 6 14:20:50 kernel: arpresolve: can't allocate llinfo for 110.92.132.1
Sep 6 14:20:50 kernel: arpresolve: can't allocate llinfo for 110.92.132.1Wie gesagt, ab dem Update auf 2.1.4 habe ich diese Fehler. Mit 2.1.5 ist es noch schlimmer geworden. Das passiert auch morgens wenn keinerlei Traffic über die Leitung geht.
Meine Pfsense ist direkt an das Cisco EPC3212 Kabelmodem angeschlossen. Auf dem Modem selbst habe ich im LOG keinerlei Fehler.WArum sagt Pfsense das es ein IP Change gegeben hat, obwohl das nicht stimmt. Was ist da los? Kann man testweise ein Downgrade auf 2.1.3 machen?
Hat da jemand eine Idee von euch?
Danke und Gruss
BGP -
Hi,
Sep 6 14:20:52 check_reload_status: rc.newwanip starting vr0
rc.newwanip wird von diversen anderen Prozessen angestoßen, nicht notwendigerweise von dem, der eine neue IP auf dem WAN detektiert.
Sep 6 14:20:57 php: rc.newwanip: phpDynDNS (blublub.dyndns.tv): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
Das sagt ja auch, dass kein neuer IP Eintrag aktualisiert werden muss, da noch alles beim alten ist.
rc.newwanip wird m.W. auch von einem Gateway Problem, Interface down etc. ausgelöst, also müsste man sich ggf. mal die Umgebung auf WAN Seite, Logs, apinger, Gateway Monitor etc. genauer ansehen.
Grüße
-
Hi JeGr,
erstmal vielen Dank für die Antwort. Ich verstehe das nicht, warum aus heiterem Himmel? Meine Pfsense macht nix großartiges ausser PF. Keine wilden Dienste und nix. Sie lief jahrlang stabil, ab 2.1.4 update habe ich diese Problem bemerkt und ab 2.1.5 ists richtig schlimm. Google kennt zu dem Problem auch keine wirkliche Antwort. In den Logs finde ich absolut nichts. Kann ich auf 2.1.3 downgraden?
Gruss
-
https://forum.pfsense.org/index.php?topic=62964.0
Hast du mal versucht wie im o.g. Beitrag deine State Table zu resetten?
Grüße
-
Habs jetzt mal mit State Reset versucht, weiss zwar nit was das bringen soll, da ich zwischendurch auch mal nen Reboot gemacht habe :))
Trotzdem Danke für deine Mühe. Halte euch/dich auf dem laufendem!
-
So, hat nix gebracht, wieder derselbe Fehler samt Verbindungsabbruch. Werde morgen mal alternativ einen anderen Router hinstellen.
-
So, mal nen kleines Update von mir. Mein 35 Euro TPLink 8970B rennt nun seit 4 vollen Tagen auch unter heavytraffic einwandfrei und ohne einen einzigen Verbindungsabbruch. Wie gesagt, das ist ein uralter PFsense Bug der ab 2.1.4 wieder eingepflegt wurde und niemand kann wirklich helfen. Von der armseligen BSD Alix WLAN Leistung mal ganz zu schweigen. ;D
-
Von der armseligen BSD Alix WLAN Leistung mal ganz zu schweigen.
Sorry aber darüber informiert man sich schon vorher, dass WLAN vllt. ein nicht so tolles Thema ist.
Wie gesagt, das ist ein uralter PFsense Bug der ab 2.1.4 wieder eingepflegt wurde und niemand kann wirklich helfen.
Was ich aus dem "Bug"-Report lese eher, dass den Bug niemand wirklich gut nachvollziehen kann, weil es wohl an Anschlüssen und Endgeräten Kombinationen liegt. Ich hab in mehreren Dutzend Konstellationen das Problem bislang nie gehabt, insofern ist sowas eben auch schwer zu debuggen.
Grüße
-
Wir haben das Jahr 2014. Da muss WLAN rennen, das ist nix exotisches. Das mit WLAN wusst ich auch vorher und trotzdem, man darf es nichtmal erwähnen, weil sonst bekommt man genau so Antworten. Das komplette Captive Portal kannst vergessen mit so einer WLAN Basis drunter.
Und um das "kernel: arpresolve: can't allocate llinfo" Problem kümmert sich auch niemand. Debuggen kann ich es auch nicht. Ich habe alle Foren durch zu dem Thema, aber immer nur aussagen von Usern, den Devs ist es wohl egal.
Warum rennt meine 30Euro China Plastikmöhre denn jetzt seid 2 Wochen ohne einen einzigen Abbruch? Ich will hier keinen Ärger verbreiten, aber man muss sich auch mal auskotzen können.Gruss
-
Wir haben das Jahr 2014. Da muss WLAN rennen, das ist nix exotisches
Falsch. Du magst recht haben, wenn du ein Device kaufst, dass für WLAN konstruiert wurde. Gibts genügend für und die haben auch ihre eigenen (teils proprietären) Treiber dafür. Aber niemand definiert, dass eine Security "Distribution" (oder Image oder Firmware, wie auch immer man es nennen mag) auch optimal für WLAN gebaut ist oder sein muss.
Gegenbeispiel: Nenne einen (größeren) Hersteller, dessen Security Appliance super für WLAN gebaut ist. Cisco ASA? Nope. Juniper SRX o.ä.? Nö. Setzen BTW auch fast alle auf BSD als Unterbau (bei Juniper sieht mans schön beim Bootvorgang).
Captive Portal funktioniert schick, allerdings baue ich da bspw. eben den WLAN AP dahinter genau aus dem Grund, weil ich WLAN nicht auf dem Gateway haben möchte und es eh nicht in der Weise gut funktionieren würde, dass es sich lohnt. Egal wie, unter Eigenbau Lösungen (Linux + teil-closed-source Treiber ausgenommen) läuft heute eben kein Super-Duper-WiFi mit 4 Antennen und WLAN-AC so gut wie in den fertigen Kisten, die Netgear, Asus und sonstige Firmen rauskloppen. Die sind eben auch primär genau dafür gebaut. Und wenn meine 'Kunden' eben schon Clients haben, die inzwischen sogar WLAN-ac haben, dann brauche ich mit Eigenbau eben gar nicht mehr anfangen, da es kaum sinnvolle Lösungen gibt. Ich bekomme solche Sachen wie Asus mit 4 Antennen, Beamforming und MultiChannel eben nicht hin, dafür haben die da auch ein paar Jährchen Entwicklung reingehauen.
Das mit WLAN wusst ich auch vorher und trotzdem, man darf es nichtmal erwähnen, weil sonst bekommt man genau so Antworten.
Was heißt "solche" Antworten? Es ist aber eben so, wenn ich mich vorher informiere und mir die Plattform ansehe und lese, "Hey, WLAN geht vllt. bis g-Standard OK, bei n wirds wackelig und ac kannst du gerade voll vergessen", dann weiß ich ob ich das will und entsprechend gebastel habe oder nicht. PFsense hat sich nirgends auf die Fahne geschrieben eine tolle WiFi out-of-the-box AP Lösung zu sein. Es ist primär immer noch eine Security Appliance/Firmware/Distro. Nicht weniger, aber auch nicht mehr (was WiFi angeht).
Ich habe alle Foren durch zu dem Thema, aber immer nur aussagen von Usern, den Devs ist es wohl egal.
Sorry, dann bist du leider blind, ich habe allein dazu 2 Tickets im Bugtracker gesehen, bei denen Devs dazu geantwortet haben. Den Link den ich oben gepostet hatte mit einem evtl. Workaround, der eben bei manchen Leuten klappte, kam auch von einem Dev bzw. Teammember (Jimp). Also was soll die Misanthropie? Ich will hier nichts beschönigen und ich habe weder mit ESF noch mit dem Team was zu tun, sondern moderiere nur noch bestem Wissen und Gewissen, aber sinnloses "auskotzen" wie du meinst, bringt niemand was und ist kontraproduktiv. Was genau bringt es anderen, wenn Sie einen Rant von dir lesen dürfen à la "Alles scheiße, 2014 muss das laufen, wir sind doch nicht bei Deppen blabla". Herrjeh bei dir läuft es nicht. Das ist wirklich bedauerlich und ich würde es gern ändern. Kann es auch nicht nachvollziehen. Komischerweise läuft es bei - ich sage mal frech - 95% aber ohne genau das Problem.
Ich kann deinen Ärger verstehen - keine Frage. Aber stell doch mal im Umkehrschluß dir selbst die Frage wie DU das debuggen würdest? Alle Anschlüsse dieser Welt dir nach Texas legen lassen? Geht nicht. Alle Modem und sonstige Gegenstellen prüfen? Wie denn? Geht auch nicht.
Du kannst ja durchaus mal ein neues Image mit 2.1.3 versuchen (sollten auf den Mirrors unter old o.ä. noch herumliegen) oder auch mal hergehen und die 2.2-Beta versuchen, bei der einige auch schon gute Erfahrungen hatten. Oder im Bugtracker suchen, ob der Bug für 2.1.5 konkret wieder offen ist und dort versuchen mehr Infos zuzusteuern, um dem Wurm endlich beizukommen.
Ansonsten gab es für das Problem noch 2 andere Ansätze:
http://www.overclockers.com/forums/archive/index.php/t-744150.htmleiner war das Gateway Monitoring zu verändern und die Werte zu erhöhen, ein anderer die Verbindung zwischen pfSense und Kabelmodem zu verändern und eine statische IP zu vergeben (und nach Möglichkeit am Kabelmodem DHCP abzuschalten). Grund in dem Thread war ebenfalls, dass das Kabelmodem und sein DHCP Server angefangen haben, das externe Interface der pfSense mit DHCP Queries zu fluten bzw. teilweise unerreichbar zu machen. Der Gateway Ping schlägt dann fehl, resettet das WAN Interface und das WAN der pfSense geht down. Deshalb Verbindungsabbruch. Alternativ könnte auch eine andere IP als Monitoring eingetragen werden, ggf. bringt das Abhilfe und der State Reset bei Monitor Fail könnte abgeschaltet werden.
Beste Grüße in der Hoffnung Abhilfe zu schaffen