10.12 RU8: 1906VA-4G crasht bei VPN-Aufbau.

[Koppelfeld]

Moin,
direkt nachdem der Router online ist, crasht er gleich wieder - wenn ich alle VPNs abschalte, ist alles o.K..
Aber das ist nicht dauerhaft beabsichtigt.

Löst die aktuelle Beta das Problem?

Bootlog ist nicht sonderlich aussagekräftig, hänge ich heute noch an. Habe ganz vergessen, daß ich nicht mehr per VPN auf die Kiste komme...

[Jirka]

Hallo Koppelfeld,

Löst die aktuelle Beta das Problem?

zumindest habe ich hier keine Probleme. IKEv1/v2 jeweils mit und ohne Zertifikate, teilweise Dynamic VPN, alles bisher reibungslos.

Bootlog ist nicht sonderlich aussagekräftig

...was ja eher der Normalfall ist.

Viele Grüße,
Jirka

[Koppelfeld]

Hi Jirka,

zumindest habe ich hier keine Probleme. IKEv1/v2 jeweils mit und ohne Zertifikate, teilweise Dynamic VPN, alles bisher reibungslos.

Das Problem habe ich weiter eingrenzen können. Die IP des Routers ändert sich bei jedem Restart und es dauert bei einer bestimmten Gegenstelle halt, bis diese neue IP propagiert ist (via "spdns.de"). Nun versucht der Router nach Restart qua statischem VPN eine Verbindung zu einer Gegenstelle aufzubauen. Das gelingt zunächst, aber der Zielrouter hat Probleme mit dem "reverse DNS" und wirft eine Fehlermeldung. Und mit deser Fehlermeldung kommt das Gespann 1906 / 10.12 RU8 nicht klar.

Bootlog ist nicht sonderlich aussagekräftig

...was ja eher der Normalfall ist.

Trotzdem, für die Akten:

Code: Alles auswählen

06/09/2018 17:55:05  LCOS-Watchdog
Task name = VPN-Ifc  Type=PPC: DSI (protection error on load access @0x50)
Code=0x00000002 Thread=04d3c310 Task=04d3c300 Nest=0x00000000

registers follow, m_p_area = 04201020
 R00=0x01d8b4c8  SP =0x04d3e498  R02=0x0497b764  R03=0x00000040 
 R04=0x04d3e4a0  R05=0x00000000  R06=0x00000000  R07=0xffffffff 
 R08=0x00000004  R09=0x0000ffff  R10=0x00000000  R11=0x00000000 
 R12=0x42042222  R13=0x0497a698  R14=0x00000000  R15=0x00000000 
 R16=0x00000000  R17=0x00000000  R18=0x00000007  R19=0x04d3c310 
 R20=0x04d3c300  R21=0x04d3c454  R22=0x00000020  R23=0x04d3c47c 
 R24=0x00000001  R25=0x04804514  R26=0x02230c90  R27=0x00000002 
 R28=0x04975bbc  R29=0x00000000  R30=0x0a69c9a0  R31=0x05eaaba0 

 CR  =0x20000422  XER =0x20000000  LR  =0x01d8b4d4  CTR =0x00000000 
 ESR =0x00000000  DEAR=0x00000050  HID0=0x80000000  HID1=0x00000000 
 MCSR=0x00000000  PID0=0x00000002  PID1=0x00000000  PID2=0x00000000 
 MAS0=0x00020003  MAS1=0x80020100  MAS2=0x00000000  MAS3=0x00000000 
 MAS4=0x00000100  MAS6=0x00020000  MAS7=0x00000000  MAS8=0x00000000 
 MCTR=0x00000000  SPR0=0x00000000  SPR1=0x04d3e4a0  SPR2=0x00000000 
 SPR3=0x04001000  SPR4=0x00000000  SPR5=0x0497b764  SPR6=0x00000040 
 SPR7=0x00000000 
 MCAR   =0x0:00000000
 SRR0(PC) =0x014d80b0
 SRR1(MSR)=0x00029202

 exception, additional backtrace: [BT] 01d8b4d4 01d96c1c 02f37980 02225f60

Stack dump (1024 bytes):
Adr:= 04d3e498
Len:= 00000400
04D3E498:  04 D3 E4 D0 01 D8 B4 C8  00 00 00 04 00 00 00 00 | ........ ........
04D3E4A8:  00 00 00 00 00 00 00 00  5B 06 78 EF 05 EA 9F 40 | ........ [.x....@
04D3E4B8:  04 D3 E4 D0 01 44 6F 78  04 97 5B BC 00 00 00 00 | .....Dox ..[.....
04D3E4C8:  00 02 92 02 0A 69 C9 A0  04 D3 E5 30 01 D9 6C 1C | .....i.. ...0..l.
04D3E4D8:  20 00 04 22 00 00 00 00  00 00 00 00 00 00 00 00 |  ..".... ........
04D3E4E8:  00 00 00 00 00 00 00 07  04 D3 C3 10 04 D3 C3 00 | ........ ........
04D3E4F8:  04 D3 C4 54 00 00 00 20  04 D3 C4 7C 00 00 00 01 | ...T...  ...|....
04D3E508:  04 80 45 14 02 23 0C 90  00 00 00 02 04 97 5B BC | ..E..#.. ......[.
04D3E518:  00 00 00 00 00 02 92 02  04 97 5B BC 00 00 00 00 | ........ ..[.....
04D3E528:  00 02 92 02 0A 6E C7 44  04 D3 E5 80 02 F3 79 80 | .....n.D ......y.
04D3E538:  00 02 92 02 DE AD BE EF  DE AD BE EF DE AD BE EF | ........ ........
04D3E548:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 | ........ ........
04D3E558:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 | ........ ........
04D3E568:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 | ........ ........
04D3E578:  00 00 00 00 00 00 00 00  00 00 00 00 02 22 5F 60 | ........ ....."_`
04D3E588:  DE AD BE EF DE AD BE EF  FF AD BE EF DE AD BE EF | ........ ........
04D3E598:  DE AD BE EF DE AD BE EF  04 D3 E6 00 04 D3 C2 C0 | ........ ........
04D3E5A8:  00 00 00 03 04 A7 9A A0  00 00 00 00 03 92 12 E0 | ........ ........
04D3E5B8:  00 2C 00 00 00 00 00 01  00 00 00 05 00 00 00 00 | .,...... ........
04D3E5C8:  DE AD BE EF DE AD BE EF  DE AD BE EF DE AD BE EF | ........ ........
04D3E5D8:  DE AD BE EF DE AD BE EF  03 81 8F 24 00 00 00 18 | ........ ...$....
04D3E5E8:  00 00 00 03 04 D3 C3 00  02 F1 AB D0 FF AD BE EF | ........ ........
04D3E5F8:  DE AD BE EF DE AD BE EF  04 D3 E6 80 04 D3 E5 A0 | ........ ........

[Jirka]

es dauert bei einer bestimmten Gegenstelle halt, bis diese neue IP propagiert ist (via "spdns.de").

Wenn Du das mit dem LANCOM-Standard-Script machst, wundert mich das nicht. Davon abgesehen nimmt man dann, jedenfalls wenn beide Seiten LANCOM, Dynamic VPN und hat die Probleme nicht. Im Fall von IKEv2 müsste das glaube ich sogar herstellerübergreifend gehen, das weiß ich aber auch noch nicht - ausprobieren.

Trotzdem, für die Akten:

Nö, nicht für die Akten, für die Fehlerbeseitigung seitens LANCOM bitteschön. Ziel muss immer sein, egal was dazu geführt hat (na ja, es gibt Ausnahmen), dass die Geräte nicht abstürzen. Marius würde sich das sicherlich anschauen (oder da ggf. mit Backslash schauen was da Sache ist). Allerdings sieht es so aus, als ob das Log nicht vollständig ist/unten abgeschnitten ist. Das Ende muss schon dran sein. Zum Ende gehört übrigens auch die genaue Geräte- und LCOS-Angabe (wenn auch von Dir hier schon erwähnt), sonst ist der OS-Panic nicht auswertbar und damit wertlos...

Viele Grüße,
Jirka