OPNsense Forum
International Forums => German - Deutsch => Topic started by: doschn on April 26, 2020, 10:12:53 am
-
Morgen allerseits,
ich habe bei meiner opnsense Installation leider ein paar kleine Probleme mit Kernel Meldungen bezüglich mbuf drops. Heute morgen konnte ich endlich mal den Zusammenhang zw. anderen Ereignissen auf der opn herstellen.
wie man in den Logs sehen kann tritt der mbuf drop auf nachdem gegen 04:20 die IPv4, sowie IPv6 Adressen vom Provider erneuert wurden. Habt ihr eine Idee wie man dem entgegenwirken kann?
hn1 ist hierbei das WAN Interface hinter der FritzBox mit einer privaten v4 und globalen v6 Adresse.
Als module / plugins und Funktionen habe ich Netflow, Suricata (non-promiscous) im IPS mode, HAProxy und Unbound DNS im Einsatz.
2020-04-26T04:39:26 kernel: 766.578990 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:39:23 kernel: 763.572963 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:39:21 kernel: 761.568016 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:39:20 kernel: 760.570687 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:32:53 kernel: 373.568258 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:32:50 kernel: 370.351749 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:32:47 kernel: 367.112605 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:32:44 kernel: 364.119766 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:32:43 kernel: 363.105042 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:32:40 kernel: 360.107560 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:32:38 kernel: 358.104026 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:32:37 kernel: 357.104500 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:26:10 kernel: 970.090883 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:26:07 kernel: 966.889159 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:26:03 kernel: 963.686943 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:26:00 kernel: 960.681870 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:25:59 kernel: 959.679564 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:25:56 kernel: 956.671972 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:25:54 kernel: 954.667823 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:25:53 kernel: 953.669286 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T04:24:56 dhcp6c[60625]: status code: no binding
2020-04-26T04:24:56 dhcp6c[60625]: Received REPLY for RENEW
2020-04-26T04:24:56 dhcp6c[60625]: Sending Renew
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum done
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum interface_086400.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum interface_003600.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum interface_000300.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum interface_000030.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum dst_port_086400.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum dst_port_003600.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum dst_port_000300.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum src_addr_086400.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum src_addr_003600.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum src_addr_000300.sqlite
2020-04-26T03:56:35 /flowd_aggregate.py: vacuum src_addr_details_086400.sqlite
2020-04-26T03:54:56 dhcp6c[60625]: Received REPLY for RENEW
2020-04-26T03:54:56 dhcp6c[60625]: unknown or unexpected DHCP6 option opt_86, len 16
2020-04-26T03:54:56 dhcp6c[60625]: Sending Renew
2020-04-26T03:24:56 dhcp6c[60625]: Received REPLY for RENEW
2020-04-26T03:24:56 dhcp6c[60625]: unknown or unexpected DHCP6 option opt_86, len 16
2020-04-26T03:24:56 dhcp6c[60625]: Sending Renew
2020-04-26T02:54:56 dhcp6c[60625]: Received REPLY for RENEW
2020-04-26T02:54:56 dhcp6c[60625]: unknown or unexpected DHCP6 option opt_86, len 16
2020-04-26T02:54:56 dhcp6c[60625]: Sending Renew
2020-04-26T02:24:56 dhcp6c[60625]: Received REPLY for RENEW
2020-04-26T02:24:56 dhcp6c[60625]: unknown or unexpected DHCP6 option opt_86, len 16
2020-04-26T02:24:56 dhcp6c[60625]: Sending Renew
2020-04-26T01:54:56 dhcp6c[60625]: Received REPLY for RENEW
2020-04-26T01:54:56 dhcp6c[60625]: unknown or unexpected DHCP6 option opt_86, len 16
2020-04-26T01:54:56 dhcp6c[60625]: Sending Renew
Bin über jeden Lösungsvorschlag dankbar.
-
Gibt sich das Problem denn irgendwann von selbst oder dauert es dann bis zu bestimmter Action an?
Ich tippe ja auf Suricata. Vermutlich wird es neugestartet, wenn sich WAN IP ändert und dabei Flags gelöscht.
Ich hab ähnliches Problem mit Sensei. Immer nachts um 3:xx kommen die mbuf Drops.
Scheint als würde Sensei hier die HW-Offloads löschen, die für die App/netmap jedoch benötigt werden.
Ich hab mir dazu kurzes Skript gebastelt, welches die Offload Settings des Interface checked und in monit eingebaut.
Immer wenn jetzt Sensei die Flags löscht, wird dies erkannt und automatisch wieder gesetzt, dann hören die Meldung auch sofort wieder auf.
-
Wie ich es manuell gefixt bekomme hab ich noch nicht ganz herausgefunden. Die zusammenhänge hab ich dahingehend noch nicht erkannt. Bin im Umgang mit BSD nicht wirklich konform und vermisse viele Systemwerkzeuge aus RHEL / CentOS.
scheinbar hat es sich heute mittag aber wieder gelegt
2020-04-26T12:24:57 dhcp6c[60625]: Received REPLY for RENEW
2020-04-26T12:24:57 dhcp6c[60625]: unknown or unexpected DHCP6 option opt_86, len 16
2020-04-26T12:24:57 dhcp6c[60625]: Sending Renew
2020-04-26T11:57:35 /flowd_aggregate.py: vacuum done
2020-04-26T11:57:35 /flowd_aggregate.py: vacuum interface_086400.sqlite
2020-04-26T11:57:35 /flowd_aggregate.py: vacuum interface_003600.sqlite
2020-04-26T11:57:35 /flowd_aggregate.py: vacuum interface_000300.sqlite
2020-04-26T11:57:35 /flowd_aggregate.py: vacuum interface_000030.sqlite
2020-04-26T11:57:35 /flowd_aggregate.py: vacuum dst_port_086400.sqlite
2020-04-26T11:57:34 /flowd_aggregate.py: vacuum dst_port_003600.sqlite
2020-04-26T11:57:34 /flowd_aggregate.py: vacuum dst_port_000300.sqlite
2020-04-26T11:57:34 /flowd_aggregate.py: vacuum src_addr_086400.sqlite
2020-04-26T11:57:34 /flowd_aggregate.py: vacuum src_addr_003600.sqlite
2020-04-26T11:57:34 /flowd_aggregate.py: vacuum src_addr_000300.sqlite
2020-04-26T11:57:34 /flowd_aggregate.py: vacuum src_addr_details_086400.sqlite
2020-04-26T11:54:57 dhcp6c[60625]: Received REPLY for RENEW
2020-04-26T11:54:57 dhcp6c[60625]: unknown or unexpected DHCP6 option opt_86, len 16
2020-04-26T11:54:57 dhcp6c[60625]: Sending Renew
2020-04-26T11:53:10 kernel: 790.371015 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T11:53:07 kernel: 787.158400 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T11:53:04 kernel: 783.951156 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T11:53:01 kernel: 780.952413 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T11:53:00 kernel: 779.947998 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T11:52:57 kernel: 776.945067 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
könntest du mich bezüglich des Scripts unterstützen?
-
Kannst ja nächstes Mal, wenn es auftritt mal versuchen:
ifconfig hn1 txcsum rxcsum txcsum6 rxcsum6
Damit sollte Offloading wieder aktiviert werden und die Meldung sofort aufhören.
Wenn das hilft, wäre nächster Schritt dann eines, das regelmäßig prüft, ob die Flags gesetzt sind und ggf. setzt.
ifconfig hn1 | grep csum
Wenn Return code ungleich Null, dann wieder setzen.
Aber noch besser wäre, wenn Software wie suricata oder Sensei, die netmap nutzen, nicht diese Flags verändern würden. Evtl. liegt es auch an der netmap Emulation. Wer weiß.
-
Kannst ja nächstes Mal, wenn es auftritt mal versuchen:
ifconfig hn1 txcsum rxcsum txcsum6 rxcsum6
Damit sollte Offloading wieder aktiviert werden und die Meldung sofort aufhören.
Wenn das hilft, wäre nächster Schritt dann eines, das regelmäßig prüft, ob die Flags gesetzt sind und ggf. setzt.
ifconfig hn1 | grep csum
Wenn Return code ungleich Null, dann wieder setzen.
Aber noch besser wäre, wenn Software wie suricata oder Sensei, die netmap nutzen, nicht diese Flags verändern würden. Evtl. liegt es auch an der netmap Emulation. Wer weiß.
werde ich testen - vielen Dank für die Unterstützung!
-
habe grad mal getestet - das problem scheint im Rahmen des abgesetzten Kommandos zu entstehen.
Es ist weg nachdem ich in Suricata den promiscous mode aktiviere, danach deaktiviere:
2020-04-26T19:45:34 kernel: 133.982921 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T19:44:39 kernel: 078.975395 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T19:44:00 kernel: 039.969652 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T19:43:32 kernel: pflog0: promiscuous mode enabled
2020-04-26T19:43:32 kernel: pflog0: promiscuous mode disabled
2020-04-26T19:43:31 opnsense: /usr/local/etc/rc.filter_configure: ROUTING: keeping current default gateway 'fe80::de39:6fff:fe15:90aa%hn1'
2020-04-26T19:43:31 opnsense: /usr/local/etc/rc.filter_configure: Ignore down inet6 gateways : FritzBox_IPv4
2020-04-26T19:43:31 opnsense: /usr/local/etc/rc.filter_configure: Ignore down inet gateways : FritzBox_IPv4
2020-04-26T19:43:25 kernel: 005.857636 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-04-26T19:42:37 sshd[76285]: Accepted keyboard-interactive/pam for root from 192.168.100.220 port 64160 ssh2
2020-04-26T19:42:37 opnsense: user root authenticated successfully for sshd [using OPNsense\Auth\Services\System + OPNsense\Auth\Local]
2020-04-26T19:24:57 dhcp6c[60625]: Received REPLY for RENEW
generell gab mir ifconfig zu keinem Zeitpunkt ne Zeile mit Informationen aus, die csum enthält.
edit: wenn ich es mit deinem Befehl aktiviere tritt der Fehler erneut auf - wenn ich mit ifconfig hn1 -txcsum -rxcsum -txcsum6 -rxcsum6 das offloading deaktiviere ist es wieder weg. aber keine Ahnung wieso es mir im ifconfig nicht angezeigt wird - weder wenn aktiv, noch inaktiv.
Wird also schwierig für mich einen Check über ifconfig in nem Script oder Cronjob umzusetzen.
-
Ist aber interessant, das die Meldung heißt Offloading needed, aber Du es deaktivieren musst. Liegt jedenfalls irgendwie an Software, die promiscuous traffic belauscht und netmap nutzt.
Und ifconfig zeigt keine Flags an? Möglich, das sie nicht direkt csum heißen. Ich nutze nur das Kommando zum Setzen der Flags öfters als das ich sie nachsehe.
-
sieht nicht so aus:
hn1: flags=28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC> metric 0 mtu 1500
options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE>
ether 00:15:5d:b2:19:11
hwaddr 00:15:5d:b2:19:11
inet 192.168.178.254 netmask 0xffffff00 broadcast 192.168.178.255
inet6 fe80::215:5dff:feb2:1911%hn1 prefixlen 64 scopeid 0x6
inet6 2001:a62:156d:fe01:215:5dff:feb2:1911 prefixlen 64 autoconf
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
groups: IFG_Local
ka ob das an Hyper-V liegt
-
Sorry, es sind nicht Flags, sondern Options. Dort müsste es gelistet sein. Aber da die Meldung bei dir kommt wenn die Optionen gesetzt sind, müsste Du quasi testen, ob die Optionen gesetzt sind und falls ja, diese löschen.
Und dann auf CSUM greppen oder mit grep -i. Wie man sieht, sind die Optionen in uppercase.
Warte Mal zur nächsten mbuf Drops Meldung ab und schaue dann, wie die Optionen sind.
-
Das ist das Ergebnis mit csum ON:
hn1: flags=28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC> metric 0 mtu 1500
options=48001b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,LINKSTATE,TXCSUM_IPV6>
ether 00:15:5d:b2:19:11
hwaddr 00:15:5d:b2:19:11
inet 192.168.178.254 netmask 0xffffff00 broadcast 192.168.178.255
inet6 fe80::215:5dff:feb2:1911%hn1 prefixlen 64 scopeid 0x6
inet6 2001:a62:15d1:c801:215:5dff:feb2:1911 prefixlen 64 autoconf
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
groups: IFG_Local
hier mit CSUM off:
hn1: flags=28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC> metric 0 mtu 1500
options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE>
ether 00:15:5d:b2:19:11
hwaddr 00:15:5d:b2:19:11
inet 192.168.178.254 netmask 0xffffff00 broadcast 192.168.178.255
inet6 fe80::215:5dff:feb2:1911%hn1 prefixlen 64 scopeid 0x6
inet6 2001:a62:15d1:c801:215:5dff:feb2:1911 prefixlen 64 autoconf
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
groups: IFG_Local
das passt soweit. hab es gestern wohl einfach übersehen :-\
gibt es in der OPNsense die Möglichkeit die Custom Checks per WEB-IF einzusteuern oder muss ich hierfür ein Script bauen, welches per IF Bedingung die werte setzt und dieses durch einen Cron-Job regelmäßig ausführen?
Nachtrag: heute morgen scheint es die Fehler auch durch die Kommandos nicht abzustellen. Probiere noch einmal etwas weiter.
Nachtrag2: Weder ein Neustart des IDS/IPS noch die Befehle erbrachten heute eine Lösung. Muss wohl von vorne anfangen zu suchen ???
Teilweise kommt es im Zusammenhang mit diesen Meldungen auch zu merkwürdigen Einträgen im FW-Log, in denen keine weiterführenden Informationen enthalten sind - mir erschließt sich ebenfalls nicht was diese Meldungen aussagen und wodurch diese generiert werden.
Hier die Links zu Screenshots von den Logs und Meldungen.
https://drive.google.com/file/d/1gR_QHAIbNoK9vUBJZRBlfJeZMvAX2eZH/view?usp=sharing (https://drive.google.com/file/d/1gR_QHAIbNoK9vUBJZRBlfJeZMvAX2eZH/view?usp=sharing)
https://drive.google.com/file/d/1XIu66DYNvZRBolfWnpvPx8pub3uouv2q/view?usp=sharing (https://drive.google.com/file/d/1XIu66DYNvZRBolfWnpvPx8pub3uouv2q/view?usp=sharing)
-
Nach weiteren Prüfungen (mehrfache Reboots und Beobachten) konnte ich die Ereignisse hierauf eingrenzen:
2020-05-12T05:27:50 kernel: 070.009398 [3884] netmap_transmit hn1 drop mbuf that needs checksum offload
2020-05-12T05:20:05 dhcp6c[27238]: status code: no binding
2020-05-12T05:20:05 dhcp6c[27238]: Received REPLY for REBIND
2020-05-12T05:20:05 dhcp6c[27238]: Sending Rebind
2020-05-12T05:02:05 dhcp6c[27238]: status code: no binding
2020-05-12T05:02:05 dhcp6c[27238]: Received REPLY for RENEW
2020-05-12T05:02:05 dhcp6c[27238]: Sending Renew
2020-05-12T04:32:05 dhcp6c[27238]: Received REPLY for RENEW
2020-05-12T04:32:05 dhcp6c[27238]: unknown or unexpected DHCP6 option opt_86, len 16
2020-05-12T04:32:05 dhcp6c[27238]: Sending Renew
2020-05-12T04:02:05 dhcp6c[27238]: Received REPLY for RENEW
2020-05-12T04:02:05 dhcp6c[27238]: unknown or unexpected DHCP6 option opt_86, len 16
2020-05-12T04:02:05 dhcp6c[27238]: Sending Renew
Sobald er das Binding verliert / ein neues erhält fangen die Probleme erneut an.
Habt ihr Lösungsvorschläge, wie ich das Problem angehen kann?
MfG
-
Hej, hast du das Problem hier gelöst. Ich habe hier (https://forum.opnsense.org/index.php?topic=18923.0) einen langen Post gemacht und nun nach vielen weiteren Tests festgestellt, dass ich vermutlich genau dein Problem habe und dazu auch ein sehr ähnliches Setup. Hast du auch keine Connectivität mehr, wenn das Problem auftritt? Bei mir bricht neben dem IPv6 ping bzw. der Nutzung vor allem auch mein Wireguard Side-2-side VPN weg, was aber auch über IPv6 getunnelt wird und daher immer ein signifikantes Indiz für einen Verlust der funktionierenden Verbindung ist.
Bei mir bringt eine Eingabe zur Aktivierung der Options mittels ifconfig bce0 txcsum rxcsum txcsum6 rxcsum6 leider nichts, ich habe auch nichts gefunden, wie ich den Fehler jetzt wegbekommen können sollte. Testweise könnte man Surricata aka IPS/IDS abschalten, ich habe zudem noch Sensei laufen. Alles das lief mit IPv4 only einwandfrei, erst seit mein IPv6 stack mit dazu gekommen ist und ich einen delegierten Prefix hinter der FB mitnutzen will habe ich massive Probleme und bin heute erst auf diesen Fehler hier aufmerksam geworden.
Ich bin inzwischen auf OPNsense 20.7.2-amd64, aber das hat nichts geändert. In diesem Bereich wurde ja auch laut Changelog nicht wirklich was geändert.
Was mich am meisten verwirrt, warum ich mein default IPv6 nicht von der OPNsense aus pingen kann:
root@OPNsense:~ # ping6 -c 2 fe80::c225:6ff:feff:820d%bce0
PING6(56=40+8+8 bytes) fe80::221:5eff:fec8:be88%bce0 --> fe80::c225:6ff:feff:820d%bce0
--- fe80::c225:6ff:feff:820d%bce0 ping6 statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
fe80::c225:6ff:feff:820d ist meine Fritzbox
bce0 ist mein WAN interface.
Und das obwohl das die default route ist:
root@OPNsense:~ # netstat -nr
Routing tables
[...]
Internet6:
Destination Gateway Flags Netif Expire
default fe80::c225:6ff:feff:820d%bce0 UGS bce0
::1 link#8 UH lo0
[...]
Also gern bin ich an dieser Problemlösung mit interessiert :).
-
Ich bin hier ein wenig weiter gekommen. Ich habe mit den folgenden Tunnables für meine Broadcom Karten experimentiert:
kern.ipc.nmbclusters="2543660"
hw.bce.tso_enable="0"
hw.pci.enable_msix="0"
Mein kern.ipc.nmbclusters war vorher schon Größer als 1 Mio., somit hatte ich hier nur einfach nochmal mehr drauf gelegt.
Ich habe allerdings damit leider nichts verändert. Meine MBUF size ist damit nun erheblich Größer, aber meine MBUF usage liegt weiterhin bei 0% mit 6340/2543660 - auch wenn der Fehler auftritt. Die Zahlen kommen also an, scheinen aber keinen Zusammenhang mit der besagten Fehlermeldung zu haben:
2020-09-07T22:22:10 130.255112 [4006] netmap_transmit bce0 drop mbuf that needs checksum offload
2020-09-07T22:22:04 124.883013 [4006] netmap_transmit bce0 drop mbuf that needs checksum offload
2020-09-07T22:21:59 119.759379 [4006] netmap_transmit bce0 drop mbuf that needs checksum offload
Sobald die Fehlermeldung auftritt, ist meine IPv6 connectivität jedenfalls schonmal tot.
Ich denke aber, ich habe nun die Ursache des Problemes gefunden, diese liegt bei dem Dienst "netdata". Dieser war nach einem Reboot nicht mit hochgekommen und starb mittels:
kernel pid 53819 (netdata), jid 0, uid 302: exited on signal 11 (core dumped)
Im Log finde ich an selber Stelle unmittelbar davor auch:
configctl[62556] error in configd communication Traceback (most recent call last): File "/usr/local/opnsense/service/configd_ctl.py", line 68, in exec_config_cmd line = sock.recv(65536).decode() socket.timeout: timed out
configctl[96731] error in configd communication Traceback (most recent call last): File "/usr/local/opnsense/service/configd_ctl.py", line 68, in exec_config_cmd line = sock.recv(65536).decode() socket.timeout: timed out
Fazit:
Lasse ich netdata ausgeschaltet, dann habe ich keine Probleme, starte ich den Service, stirbt er immer wieder und kommt dann nach dem 3. oder 5. mal anklicken trotzdem hoch, dann kommt aber relativ Zeit der besagte Fehler "netmap_transmit bce0 drop mbuf that needs checksum offload" in enormer Geschwindigkeit in die Logs geflutet.
Kannst du oder jemand anders, diesen Fall auch nachstellen?
PS: Warum ich mein IPv6 GW nicht pingen kann, habe ich noch nicht geklärt, scheint aber ein anderer Fall zu sein und habe ich hier (https://forum.opnsense.org/index.php?topic=19018.0) einmal gesondert angesprochen.
-
Servus,
sorry hatte länger nicht mehr rein geschaut.
Die IPv6 Connectivität stirbt bei mir nicht - die Zuverlässigkeit was dynamische v6 angeht hat sich mit den letzten Updates aber weiterhin erhöht. Davor konnte ich mit folgendem Workaround ohne einen Reboot die v6 Erreichbarkeit wiederherstellen:
Wenn ich die IPv6 Konfiguration entferne und erneut auf Track interface [WAN] setze ist die v6 Konfiguration korrekt übernommen worden. Seit dem letzten Update hier keine Probleme mehr.
Die von dir erwähnten Fehlermeldungen habe ich auch, jedoch stehen sie in keinem unmittelbaren Zusammenhang mit dem mbuf Fehler. (dieser Tritt vorher und danach auf)
2020-09-21T18:02:00 configctl[21612] error in configd communication Traceback (most recent call last): File "/usr/local/opnsense/service/configd_ctl.py", line 68, in exec_config_cmd line = sock.recv(65536).decode() socket.timeout: timed out
Werde deine Fixes nach einem Konfig Backup die Tage mal versuchen und mich dann nochmal melden.
-
Ok, interessant, bei mir ist es seit dem letzten Release noch schlimmer geworden.
Hatte das mit dem Tack Interface auf WAN auch al getestet, aber beim ersten mal nur ohne Änderungen gespeichert und dann ist die Firewall Oberfläche hängengeblieben, also das Web Frontend war tot und kam nach einiger zeit wieder, hat vermutlich rebootet (Uptime fing wieder bei 0 an). Als so richtig stable ist das aktuell nicht.
Ich warte auf die nächste Release-Runde und gucke dann mal. Bis dahin ist IPv6 bei mir zumindest leider vollkommen unbrauchbar.