[Problem] Fritz!Box 6360 Adam2 Fragen (entstanden aus VPN Probl: 7490-ConnectBox-UM.IPv6 zu 7490 mit IPv4)-

[fibco]

Wegen des Ausgangsproblems ...

Spoiler: VPN per 7490 hinter Unitymedia IPv6 ConnectBox nur 1h lang nach Neustart der CB möglich :(

Situation: Neuer UM IPv6/DS-lite Anschluss mit ConnectBox, daran eine Fritz!Box 7490 mit Fw 06.92
alter NC IPv4 Anschluss mit Cisco xyzy Kabelmodem, daran eine andere Fritz!Box 7490 mit Fw 06.92

Ich habe verstanden, dass nur die Fritzbox auf der IPv6-Seite die VPN-Verbindung aufbauen kann. VPN ist klassisch über Alice/Bob .cfg eingerichtet, dies hat auch ein paar Wochen geklappt.

Nun hat aber Unitymedia irgendetwas geändert (an der Connectbox Konfig, am CGN, am DS-lite ... ich weiß es nicht) und nun bleibt der VPN-Tunnel nach Neustart der Connectbox immer genau knapp eine Stunde bestehen. Danach IKE-Error 0x2027 und IKE-Error 0x203d und kein Neuaufbau des Tunnels möglich. Man liest, dass Unitymedia plant (erwägt?) eine Connectbox-Konfiguration in Richtung IPv4-Exposed Host zu bringen, doch ich möchte jetzt eine Lösung. Warum ein UM Business-Anschluss nicht mehr in Frage kommt oder ein gescheiter VDSL-Anschluss nicht möglich ist, wäre ein weiterer Exkurs (auf den ich erst mal verzichte). Meine Überlegung ist, dass eine Cable Fritz!Box am UM IPv6-Anschluss mir sofort "exposed host" für die nachgeschaltete 7490 bringen würde oder das VPN auch selber machen könnte. Meine Hoffnung ist, dass ich damit einen stetig stabilen VPN-Tunnel haben kann. Naja, bis UM zur nächsten "Sabotage" schreitet :-(-

... will ich die Unitymedia Connectbox testweise durch eine Cable Fritz!Box ersetzen. Eine legal in meinem Eigentum befindliche (dies bitte nicht anzweifeln - für seinerzeit €99 mit Rechnung bei NetCologne gekauft) nicht gebrandete rote Fritz!Box cable 6360 liegt vor mir. Ja, ich weiss, dass diese zwar docsis 3 kann, aber an sich nicht genug UL/DL-Kanäle aufweist (UM schreibt da "soll" statt "muss"). Habe jedoch den Eindruck (Exkurs ...), dass ich die 6360 bei UM durchaus registriert bekommen kann. Firmwarestand der 6360 ist 06.04 (per seinerzeit verfügbarem recover.exe). Nun muss ich sie wegen der Sache mit den Kabelzertifikaten vor Realisation des Testvorhabens zuerst auf einen Firmwarestand >06.51 (?) bringen.

Betreibt jemand eine der seltenen 'Original nicht-Provider gebrandeten' 6360 Fritz!Boxen aktuell im Netz von Unitymedia?

- Leider ist mir der Unterschied 06.51 vs. 06.52 (bei der 6360!) nicht klar.
- Zu beiden FW-Versionen liegen mir Dateien vor. Wie kann ich deren Authentizität prüfen, bitte? Bzw. kann mir jemand einen Fingerzeit auf eine "echte" 06.52 geben (oder eine solche überlassen)?

Einloggen auf die 6360 per Adam2 klappt, doch bei:
GETENV linux_fs_start bekomme ich leider nur "501 enviroment variable not set" :-(

Weiterhin:
- GETENV firmware_info führt zu: "... recovered=2"
- GETENV firmware_version führt zu "... avm"
- GETENV hardware_revision führt zu "... 157"
- GETENV ProductID führt zu "... Fritz_Box_Puma"

Wie ich nun welche "mtd"-Bereich beschreibe, habe ich noch nicht recherchiert (außer, dass mir rukerneltool bei der Box nicht helfen will(?) - schade). Im Moment hänge ich am zuvor beschriebenen GETENV linux_fs_start -> "501 enviroment variable not set" und weiß nicht, wie ich damit umgehen soll. Dazu bitte ich um Rat.

Falls der Ratschlag einen weiteren Blick hat, als ich den bisher habe - sprich: wie ich die nächsten Schritte löse, ohne so massiven Zeitaufwand wie leider bisher - wäre ich sehr(!) dankbar.

VG
fib

 

[koyaanisqatsi]

Moin

Im Moment hänge ich am zuvor beschriebenen GETENV linux_fs_start -> "501 enviroment variable not set" und weiß nicht, wie ich damit umgehen soll.

Keine Panik
Das bedeutet...
1. Sie wurde noch nie geupdatet, oder...
2. Sie wurde Recovert und hat danach noch kein neues Update erfahren

Denn erst nach einen normalen Update wird 'linux_fs_start' angelegt.

 

[fibco]

Lach, das konnte ich nirgends finden. Danke!
Ist das dann entsprechend dem Wert Null?

Hast Du ggf. noch weitere Tipps oder 'ne URL (ich habe schon gaaanz viele zu allem Möglichen) zum Flashen den richtigen mtds? Oder anderem, was zum Ziel führt.

 

[koyaanisqatsi]

Ist das dann entsprechend dem Wert Null?

Ja, aber in ADAM2/EVA trotzdem vor Änderung immer mit GETENV vorher nachschauen
...und die Finger von lassen wenn GETENV fehlschlägt.

Da ich diesbezüglich meine Informationen von @PeterPawn seinen Beiträgen erhalten habe...
https://github.com/PeterPawn/modfs/blob/master/BOOTSELECTION.ger

 

[f666]

Meines Wissens gibt es den c4.avm.de Server zum Update der Zertifikate nicht mehr.
UM ist zwar einer der letzten Provider, welche die alten Zertifikate noch akzeptieren, doch gibt es hier im Forum schon mehrere Hinweise, dass das jetzt schon nicht mehr pauschal gilt.

Wenn du insgesamt Zeitaufwand sparen willst, kauf dir gleiche eine 6490/6590 mit neuen Zertifikaten (neu oder gebraucht).

 

[fibco]

Ja, aber in ADAM2/EVA trotzdem vor Änderung immer mit GETENV vorher nachschauen
...und die Finger von lassen wenn GETENV fehlschlägt.

Da ich diesbezüglich meine Informationen von @PeterPawn seinen Beiträgen erhalten habe...
https://github.com/PeterPawn/modfs/blob/master/BOOTSELECTION.ger

Also in der Situation nicht selber als 0 setzen, ja?!

 

[koyaanisqatsi]

Richtig - Mir wären zwar keine Nachteile bekannt, aber eine nicht gesetzte Variable hat bestimmt ihren Sinn.
Und bei einer Vorhandenen kann mit an Sicherheit grenzenden Wahrscheinlichkeit von einer zweiten Partition ( Firmwarerversion ) ausgegangen werden.
Ein Experte würde in deinem Fall eben auch behaupten, was ich in Post #2 geschrieben habe.
Wenn du sie setzt, würdest du damit einen Experten vor den Kopf stossen.
( Zumindest extrem verunsichern )

 

[fibco]

Oh, diese Abhängigkeit ("c4.avm.de Server zum Update der Zertifikate") hatte ich nicht präsent. Wenn das jemand sicher bestätigen könnte, dann wäre es das Ende der Fahnenstange, oder? Ja, zeitsparender wäre 'ne 6490/6590 wohl. Allein wenn ich hier Elektroschott vermeiden könnt', würd' ich auch noch etwas Zeit aufwenden. Und per Routermiete habe ich vor dem Feiertag keine 6490 in Händen.


Alte Zertifikate .... heute Nacht schaute es beim Anschluss der 6360 mit Fw. 06.04 so aus (denke mal, das Scheitern des SW upgrade lag nicht an der nicht erfolgten CPE-Registrierung, oder??):

08.05.18 01:05:52 SW upgrade Failed after download - Incompatible SW file
08.05.18 00:52:18 SW Download INIT - Via NMS
08.05.18 00:47:48 Auth Reject - Permanent Authorization Failure
08.05.18 00:47:39 TLV-11 - unrecognized OID
08.05.18 00:47:39 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
01.01.70 01:05:08 No Ranging Response received - T3 time-out

Konfigurationsdatei des Anbieters: no-service.bin

 

[PeterPawn]

Wie @f-666 schon schrieb, behebt ein Firmware-Update noch lange nicht das Problem mit den Zertifikaten.

Die Box hat - dem "Auth Reject" nach - noch alte Zertifikate und das CMTS will neue sehen. Entweder man findet ein neues von einer defekten Box (die muß da dann natürlich jemand zuvor gesichert haben, als die Box noch funktionierte) oder auch von einer, die nur im LAN1-Modus betrieben wird und ihr Zertifikat daher auch nicht braucht (das interessiert nur beim Betrieb mit CM) oder es ist eben doch (inzwischen ist es wohl auch bei UM durchaus gang und gäbe, das CM-Zertifikat genauer zu betrachten) nur noch Elektroschrott, wenn man das CM in der 6360 verwenden will.

 

[fibco]

Ich war schlicht der irrigen Annahme, dass mit einer Firmware 06.52 sich die Zertfikatssache irgendwie regelt. Doch wenn der Server dazu nicht mehr aktiv ist :-(
Aber, was machen dann die Leute, die einen Werksreset aus der Oberfläche heraus auslösen? Die Zertifikate werden doch - Laienvermutung - nicht persistenz im Bootlader gespeichert sein und müssten dann auch wieder geladen werden, oder?

 

[PeterPawn]

Ja, das Problem existierte m.W. auch bis zur Version 06.50 ... seitdem wird (zumindest in der 6490, aber vermutlich auch in der 6360 - wirf einfach selbst einen Blick in die Skripte in "/etc/init.d") bei "Werkseinstellungen" ("recovered=n" im Environment beim Start des OS) nicht mehr alles in "/nvram" einfach gelöscht, event. vorhandene Zertifikate werden "gerettet" (sprich: schlicht vom Löschen ausgenommen) und das JFFS2-FS wird gar nicht neu initialisiert.