Das sieht nach einem Problem bei Rekeying aus ... allerdings ist dieses Crash-Protokoll ja schon knapp 3 Wochen alt.
Normalerweise handeln die Peers beim IPSec einen Sitzungsschlüssel aus, der für eine begrenzte Zeit und/oder eine begrenzte Datenmenge gilt. Eines der beiden Limits war bei Dir offenbar erreicht und während der Aushandlung eines neuen Schlüssels kam es zu einem Problem, das am Ende in einem SIGBUS mündete.
Allerdings war das mit einiger Wahrscheinlichkeit doch eine softwaregenerierte Ausnahme der AVM-Firmware, denn offenbar trat das Problem in einer Routine "timercb_del" auf, die ich - rein dem Namen nach - dafür verantwortlich machen würde, daß eine Routine zur Behandlung eines Timer-Events (timer callback) aus der Kette der Handler gelöscht werden soll (del) und - auch reine Vermutung meinerseits - die wird wohl nicht mehr dort in der Queue vorhanden gewesen sein.
Ob das jetzt aber bei der Eingrenzung Deines derzeitigen Problems helfen wird, wage ich zu bezweifeln, solange dieser Fehler nicht reproduzierbar erneut auftritt.
-Wobei generell Rekeying tatsächlich zu diesen Abstürzen beitragen könnte, dazu müßte man aber wissen, wann solche Abstürze genau auftreten. Da die Lebensdauer eines Session-Keys eben entweder in Sekunden oder in Bytes "gemessen" wird, braucht es eine Beobachtung beider Größen. Die Zeit läuft auch, wenn gar keine Daten übertragen werden und eine Volumengrenze kann auch wieder zuerst überschritten werden, wenn die Leitung "dick genug" ist und eine recht lange Lebensdauer ausgehandelt wurde.
Was die FRITZ!Box selbst als Proposal an dieser Stelle anbietet, kann man am einfachsten mit einem Debug-Protokoll einer racoon- oder StrongSwan-Installation feststellen, nach dem Standard einigen sich beide Peers auf den jeweils kleinsten gemeinsamen Nenner bei beiden Werten.
Komischerweise hat AVM bei den neueren Versionen des avmike etwas eingebaut, daß bereits nach dem Ablauf von 90% der vereinbarten Lebensdauer (nach Zeit) ein zusätzlicher Session-Key (bzw. eine weitere "security association" (SA)) ausgehandelt wird und diese existiert normalerweise erst einmal parallel zu der alten. Wann genau jetzt auf den neuen Schlüssel umgeschaltet wird, kann man leider weder im AVM-Protokoll (/var/tmp/ike.log) sehen noch irgendwo anders in der Firmware ... jedenfalls habe ich dazu bisher noch nichts gefunden.
Den avmike zu debuggen ist auch alles andere als leicht ... trotz vorhandener Optionen "-d" und/oder "-v" für den Aufruf kommt man gar nicht dazu, das wirklich selbst aufzurufen, da der avmike bei aktivierten VPN-Verbindungen selbst nach einem "kill" sofort wieder neu gestartet wird und bei nicht aktivierten Verbindungen startet er zwar mit den gewünschten Einstellungen, wird aber bei jeder Änderung der VPN-Einstellungen (also auch beim Aktivieren einer Verbindung) gekillt und neu gestartet. Man muß also das eigentliche Binary /bin/avmike durch ein geeignetes Wrapper-Skript ersetzen, wenn man da etwas mehr sehen will ... wobei das auch nicht so ausführlich ist in den Release-Versionen.
Sollte es aber am Ende tatsächlich das Problem des Rekeyings sein, müßte sich der Fehler entweder bereits früher provozieren oder auf später verschieben lassen - in Abhängigkeit von den derzeit verwendeten Sets für P2. Wenn das jetzt schon eines der "LT8h"-Sets ist, sollte bei Verwendung eines "1h"-Lifetime-Sets das Problem früher auftreten. Wird schon jetzt eine Lifetime von 3600 Sekunden verwendet (wie gesagt, AVM initiiert ein Rekeying bereits nach 54 Minuten, bei den 8h-Sets nach 7:12 h), sollte ein 8h-Set das Problem (wenn es tatsächlich nur von der Zeit abhängt) nach dem Neuaufbau einer VPN-Verbindung (auch das wäre wichtig, da - wie oben geschrieben - die Zeit ab Aktivierung der SA zählt) den Fehler hinauszögern können.
Zumindest einen Blick wäre es in jedem Falle mal wert, ob es eine Abhängigkeit vom Rekeying gibt oder nicht ... den Inhalt der /var/tmp/ike.log kann man auch den Support-Daten entnehmen, dort findet sich das Hinzufügen und Entfernen von SAs in Form von Protokoll-Einträgen.
