[Problem] VPN-Koppelung zweier 6490 (LAN-LAN-Koppelung)

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,796
Punkte für Reaktionen
37
Punkte
48
Hallo,

ich möchte zwei 6490 mittels VPN koppeln. Folgende Voraussetzungen bestehen:
  • UM-Box, externe IPv4, intern 192.168.178.0/24, FW 06.50
  • KDG-Box, externe IPv6, intern 192.168.188.0/24, FW 06.65
  • gemeinsamer PSK für VPN
Beide Boxen haben auch einen eigenen DynDNS-Host. Aber es klappt weder damit, noch mit myfritz, noch mit bloßen IP-Adresse.

Im Ereignislog der KDG-Box (diese soll ja dauerhaft die Verbindung herstellen) steht nun dauernd:
Code:
17.01.18 xx:xx:xx    VPN-Fehler: xxxxxx.myfritz.net, IKE-Error 0x2027 [xx Meldungen seit 17.01.18 xx:xx:xx]

Und im vpn.log:
Code:
avmike:mainmode um-box-acc.myfritz.net: del SA 1
avmike:wolke_neighbour_renew_sa 0 SAs
avmike:wolke_neighbour_renew_sa 0 SAs RENEW
avmike:um-box-acc.myfritz.net: Phase 1 starting (renew)
avmike:< cb_sa_create_failed(name=um-box-acc.myfritz.net,reason=IKE-Error 0x2027)
avmike:mainmode um-box-acc.myfritz.net: selected lifetime: 3600 sec(no notify)
avmike:mainmode um-box-acc.myfritz.net: add SA 2
avmike:um-box-acc.myfritz.net remote peer supported XAUTH
avmike:um-box-acc.myfritz.net remote peer supported DPD
avmike:um-box-acc.myfritz.net remote peer supported NAT-T RFC 3947
avmike:um-box-acc.myfritz.net: Phase 1 ready
avmike:um-box-acc.myfritz.net: current=ip.von.um.box:4500 new=ip.von.um.box:4500
avmike:um-box-acc.myfritz.net: local is behind a nat
avmike:um-box-acc.myfritz.net: remote is behind a nat
avmike:um-box-acc.myfritz.net: start waiting connections
avmike:um-box-acc.myfritz.net: NO waiting connections

Eine iPhone-VPN-Verbindung aus dem WLAN der KDG-Box zur UM-Box klappt übrigens problemlos, aber das ist ja auch keine LAN-LAN-Koppelung.
 

Anhänge

  • KDG.png
    KDG.png
    172.1 KB · Aufrufe: 10
  • UM.png
    UM.png
    189.1 KB · Aufrufe: 9
Zuletzt bearbeitet:
Irgendwas kommt ja durch ... die "remote capabilities" sind ja da. Hier könnte sogar wieder das MTU-Problem bei VPN und DS-Lite zuschlagen, denn auch wenn auf der UM-Seite eine echte IPv4 vorhanden ist und dort kein DS-Lite verwendet wird, muß die natürlich auch die geringere MTU des Tunnels berücksichtigen, wenn auf der anderen Seite die Pakete zusätzlich noch einen IPv6-Header beim DS-Lite aufnehmen müssen.

Wenn Du andere Boxen zur Verfügung hast, setze mal an die Stelle der UM-6490 irgendeine andere an einem IPv4-Anschluß ... klappt das dann auch mit der KDG-6490, liegt es an der UM-Box. Klappt auch das partout nicht, hat vielleicht auch KDG mit der 06.65 (kdg) ein DS-Lite-Problem beim VPN - wird ja ab und an auch diskutiert, m.W. bisher mit "wenig Fleisch am Knochen", wenn ich nichts Wichtiges verpaßt habe.
 
Hmm, bei UM ist aber nur die UM-6490 registriert. Ich vermute, UM würde eine andere Box (was auch immer) also gar nicht zulassen.

iPhone-VPN und https-Remotezugriff funktioniert jedenfalls. Ich habe es auch schon mit einer 7490 hinter einem IPv4-Telekomanschluss versucht, die UM-Box zu erreichen. Gleiches Ergebnis.
 
Ich meinte natürlich eine andere FRITZ!Box an einem anderen (IPv4-)Anschluß ... es geht darum, daß UM (oder die FRITZ!OS-Firmware bei UM) generell Probleme haben soll, wenn es um VPN geht, weil die MTU für den Tunnel falsch gesetzt und wohl nicht über PMTU-Discovery ermittelt wird (sonst wäre sie ja vermutlich richtig). Die Frage ist, ob das für die KDG-Box auch gilt ... "kann" die aber z.B. mit einer DSL-Box, wäre das schon mal als Fehlerquelle ausgeschlossen.
 
Eine iPhone-VPN-Verbindung aus dem WLAN der KDG-Box zur UM-Box klappt übrigens problemlos
Ich habe es auch schon mit einer 7490 hinter einem IPv4-Telekomanschluss versucht, die UM-Box zu erreichen. Gleiches Ergebnis.
genau das sind die Symtome für das von anderen Usern genannten "MTU-IPv4-Problem"; Hinweise hierzu in Thread 280723:
https://www.ip-phone-forum.de/threa...psecbridge-und-1x-ds-lie.280723/#post-2255754
ff.

Welche MTU-Werte für IPv4/IPv6 wurden Dir von den beiden Providern (UM, KDG) provisioniert ? supportdaten der beiden FB6490 nachsehen und posten

Hast Du die FB6490-UM FB6490-VF/KD zum VPN-Initiator gemacht ? ich lese nichts davon in #1

Was steht im avmike.log der FB6490-UM ?

Ist es möglich einen Mitschnitt beim VPN-Verbindungsaufbau zu machen ? dann könnte man die Frames udp/4500 Frames bzgl. MSS/MTU genauer ansehen; oder sind FB-Mitschnitte durch die Provider-Firmware gesperrt ?

Bitte den Vorschlag von PeterPawn "mit einer DSL-Fritzbox zu testen";
interessant ware hier auch eine DSL-FritzBox hinter FB6490-UM Box zu hängen und dann LAN-to-LAN VPN testen; natürlich vorher sämtliche VPN-Verbindungs-Konfigurationen in FB6490-UM deaktivieren und Freigabe (Port-Forwarding) udp/4500 von FB6490-UM auf diese DSL-FritzBox (z.B. FB7490) auch auf Port udp/4500 einzurichten.

UPDATE: Tippfehler (nach Hinweis von PeterPawn #7) korrigiert:
Hast Du die FB6490-VF/KD zum VPN-Initiator gemacht ?
 
Zuletzt bearbeitet:
Supportdaten, jeweils im Abschnitt Networking:

UM:
0: name internet
0: sync_group: sync_cable
...
0: IPv4: ip ip.von.um.box mask 255.255.252.0 gw gw.von.um.box dhcp mtu 1500


KDG:
0: name internet
0: sync_group: sync_cable
...
0: IPv6: mtu 1500

Ich habe die KDG-Box zum Initiator gemacht (Internet/Freigaben/VPN/LAN-LAN-Verbindung/[x] VPN-Verbindung dauerhaft halten), da nur diese sich ja von IPv6 zu IPv4 verbinden kann.

Paketmitschnitt ist leider gesperrt. Würde ein Paketmitschnitt der 7490 hinter KDG-6490 helfen? Einen Fritz!Box-IPv4-Zugang habe ich leider im Moment auch nicht unter Kontrolle. Kann mir bitte jemand einen solchen einrichten? Er darf auch im Zugriff auf eine ungültige Adresse beschränkt sein, dass es ja nur um den Verbindungsaufbau geht.
 
Hast Du die FB6490-UM zum VPN-Initiator gemacht ? ich lese nichts davon in #1
Warum sollte er das tun?

Hier ist die UM-Box ja nicht selbst an einem DS-Lite-Anschluß ... der Peer hingegen schon. Damit kann die UM-Box also gar nicht als Initiator arbeiten bzw. sie würde den Peer auf diesem Weg niemals erreichen können. Das ist praktisch das Gegenteil von der (an anderer Stelle diskutierten) Konstellation, wenn auch vermutlich mit demselben Effekt, sollte es an der "festen" (falschen) MTU in der UM-6490 liegen.

@Chatty:
Ich bin mir zwar nicht 100% sicher, aber in der UM-Box sollte eigentlich auch mit Provider-Firmware ein Mitschnitt möglich sein, nur das Interface für das DOCSIS-Management war dort ausgeblendet (iirc, ich müßte erst graben und nachlesen, was ich aber erst dann mache, wenn mir jemand definitiv sagt, daß "Paketmitschnitt" nicht erreichbar ist in deren Support-Seite).

Daß die anderen beiden Zugriffsmöglichkeiten auf die UM-Box funktionieren (iPhone-VPN, GUI), ist nicht wirklich verwunderlich ... wenn das Problem tatsächlich in der falschen MTU-Angabe für den VPN-Tunnel zu suchen ist. Solange bei diesen anderen Zugriffen nicht ebenfalls ein "Abschnitt" in der Verbindung existiert, der eine geringere Paketgröße erfordert, beeinflußt das ja die MTU nicht und hier würde es (zumindest in der Theorie) auch schon wieder ausreichen, wenn auf der KDG-Seite eben ein DS-Lite-Anschluß vorliegt, obwohl die Box dort selbst sogar die korrekte MTU verwendet werden könnte.

Solange die UM-6490 einfach weiterhin von 1500 Bytes (oder genauer "octets" :D) ausgeht und damit Pakete vom AFTR-Gateway bei KDG zerlegt werden müssen, muß die Authentizitätsprüfung für ein VPN-Paket scheitern. Zwar darf bei NAT-T der Router etwas "außen herum" dazubasteln, damit das Routing von Paketen funktioniert, aber "innerhalb" der Pakete darf nichts geändert werden und das würde beim Fragmentieren geschehen.
 
Ab wann wird es für dich definiv?
Eher selten, zumindest so wie es dort steht ... aber ich schaue mal in die Firmware (es war die 06.50-lgi+avm, wenn ich das richtig gelesen habe?) und auf die Voraussetzungen, damit die Seite in der "menu_data.lua" eingeschlossen wird. Vermutlich reicht es bereits, in die "featovl.cfg" den passenden Inhalt zu bringen - aber ich muß erst einmal nachsehen.

Jedenfalls nutzt es (fast) nichts, wenn man auf einer anderen Box hinter der UM-6490 irgendetwas mitschneiden will, denn das ist ja wieder genau die Konstellation, wo es wohl funktioniert, weil die kaskadierte Box dann ihrerseits wieder eine passende MTU anwendet, wenn sie einen VPN-Tunnel aufbaut und eine externe VPN-Verbindung zur UM-6490 endet natürlich auch in dieser Box selbst und nicht auf einem kaskadierten Router dahinter.

Die KDG-Versionen blendeten den Mitschnitt m.W. schon immer aus, solange man die nicht zur "Beta-Version" erklärte über die passenden CONFIG-Variablen - da nutzt es also auch nichts, weil man die ankommenden IPSec-Pakete dort ebenfalls nicht sehen kann und damit auch nicht die ggf. erfolgte Fragmentierung, wenn da zwei Pakete kämen für ein von der UM-6490 gesendetes.

Wobei ich auch nicht sicher weiß, ob der direkte Aufruf (ohne "lastpage" - also "lp=" - in der URL) bei genau dieser Firmware überhaupt (wie von Dir versucht) funktionieren muß (kriegt man auch nur durch's Lesen raus) ... aber den fehlenden Punkt zum "Paketmitschnitt" auf der Support-Seite muß man natürlich ernst nehmen.
 
Also /dect.lua klappt beispielsweise nichts, aber ?lp=dect. Aber wie lautet der Parameter für Paketmitschnitt? ?lp=capture funktioniert nicht.
 
So steht's in der "menu_data.lua" der fraglichen Version:
Code:
    pageData["cap"] = (not config.DOCSIS or (config.DOCSIS and 'release' ~= config.gu_type)) and { ["show"] = true, ["wiz"] = true, ["lua"] = "capture.lua" } or nil
Also wird die Seite bei dieser Version nur dann angezeigt (das gilt auch für den direkten Aufruf mit "lp=cap"), wenn die Software nicht als "Release-Version" angesehen wird, wozu "CONFIG_RELEASE" nicht "1" sein darf oder - wenn das doch "1" ist - CONFIG_BETA_RELEASE ebenfalls "1" sein muß.

Wie man das jetzt hinbekommt, will ich Dir nicht näher erklären - jedenfalls nicht in diesem speziellen Fall, wo es um DOCSIS-Boxen geht.

Wie es generell geht, habe ich (schon vor der Aktivität, die es mir verbietet, in diesem konkreten Fall genauer zu werden und es Dir haarklein zu erklären) an anderer Stelle beschrieben und die installierten Firmware-Versionen haben ja auch noch einige bekannte Lücken, die in anderem Zusammenhang (eben nicht nur mit DOCSIS-Geräten, sondern auch mit DSL-Boxen bzw. bei DOCSIS auch in einem anderen Kontext) beschrieben wurden (und für so manchen Unfug benutzt wurden :D), während sie von AVM dann irgendwann mal gefixt wurden (so Richtung 06.8x).

Wenn die KNB neue Versionen nicht installieren, sind sie am Ende selbst schuld. Die Tatsache, daß damit die Kunden mit Provider-6490 immer noch auf dem ARM-Core festhängen, der ja deutliche Performance-Nachteile hat, ist da nur noch eine weitere Randnotiz.
 
Ich verstehe wie auch in anderen Threads deine Motivation nicht, hier zu posten, dass du das Wissen hast, wie man etwas macht, es aber explizit nicht teilen möchtest. Wozu es dann überhaupt erwähnen?
 
Dieses konkrete Szenario darf ich nicht in dem von Dir offenbar erwarteten Maße beschreiben, weil ich es in einem Pen-Test für AVM ebenfalls angeführt habe und für dessen Ergebnisse selbstverständlich Stillschweigen gilt, solange AVM sie nicht selbst veröffentlicht.

Ist es tatsächlich zuviel verlangt, wenn Du Dich einfach mal auf den Hosenboden setzt und Deinerseits suchst, was mit den bisher gegebenen Hinweisen gemeint sein könnte? Sowohl die "featovl.cfg" wurde erwähnt als auch die "zuständigen" Variablen. Wie Du das jetzt genau machst - also ob Du nur die Einstellungen irgendwie überlagerst und wie das genau geschieht oder ob Du die komplette Firmware änderst - ist mir vollkommen egal.

Schon die anderen, von mir noch einmal wiederholten Informationen bzgl. "lp" und zum mutmaßlichen MTU-Problem der UM-6490 hättest Du durch eigene Suche hier finden können ... insofern war schon die bisherige "Diskussion" eigentlich nur ein Duplikat anderer Threads und einigermaßen überflüssig. In der Konsequenz entschuldige ich mich nicht dafür, daß ich hier nicht mehr weiterhelfen will, sondern eher dafür, daß ich in diese nutzlose - weil mindestens doppelte - Diskussion überhaupt eingestiegen bin.

Meine Motivation war es hier tatsächlich, Dir zu helfen ... wenn Du die Grenzen dieser Hilfsbereitschaft (und -möglichkeit) dadurch überschreitest, daß Du "full service" erwartest, sehe ich das nicht direkt als mein Problem an, sondern eher als Deines. Das bißchen Aufwand sollte allemal noch drin sein ... wenn ich Dir gar nicht geantwortet hätte, wärst Du auch noch nicht weiter. Ich habe Dir also definitiv nicht geschadet mit meinen Antworten - höchstens dadurch, daß bei Dir damit offenbar eine falsche (und m.E. ungerechtfertigte) Erwartungshaltung geweckt wurde.

Und wenn ich das Wissen nicht bereits anderswo geteilt hätte, wäre mein Verweis auf die Suchmöglichkeit falsch ... insofern trifft dieser Punkt einfach nicht zu. Ich will es nicht noch einmal teilen - das ist meine eigene Entscheidung und es ist und bleibt die Deine, ob Du Dich auf die Suche nach dieser vorhergehenden Beschreibung machst oder nicht. Wenn Du das nicht willst, läßt Du es einfach bleiben ...

Danke für das Gespräch.
 
Du vergisst dabei immer, dass du das Wissen schon hast. Wenn ich wüsste, wonach ich Suche, dann würden mir auch die korrekten Suchbegriffe einfallen. Da du deine alten Beiträge absichtlich nicht entfernst, ist dir deren Anwendung ja doch kein Dorn im Auge, wie du immer durch Hinweise á la "ohoh DOCSIS, kann man Böse Dinge machen" andeutest. Würdest du etwas konkreter Hinweisen (von mir aus per PM/Mail), dann müsste man (hier ich) immer noch genügend nachlesen und ergooglen. Sei es drum. Danke für die vermutlich nettgemeinten Hinweisstückchen.
 
Würdest du etwas konkreter Hinweisen
ich würde mit "provideradditive.tar" und "featovl.cfg" mal mit Recherche starten;

UPDATE: relevantes configfile gemäß Beiträgen/Hinweisen von PeterPawn #9, #13, #16 von "avmfeature.conf" nach "featovl.cfg" geändert.
 
Zuletzt bearbeitet:
@Chatty:
Du wirst mir schon noch einreden, daß ich viel zu unfreundlich zu Dir war.

Wenn ich meinerseits mit einem einzelnen Stichwort (nämlich der bereits erwähnten "featovl.cfg") bei Google auf die Suche gehe und mich dabei auf diese Site und die Fundstellen, in denen mein Nutzername auftaucht, beschränke, dann erhalte ich im Moment genau 48 Treffer. Schränke ich das dann noch einmal weiter ein, indem ich das ebenfalls erwähnte "CONFIG" als Wildcard hinzunehme, sind es noch 22 Ergebnisse und schon der dritte Treffer beschreibt, wie man mit der "featovl.cfg" in die Firmware eingebaute "CONFIG"-Variablen überschreiben kann.

Da steht das zwar nur für den Fall, daß man mit einer Shell zugreifen kann, aber das wäre dann - wenn man erst mal einen "Plan" hat - eben der nächste Schritt - das Erkunden, wie man diese Datei ansonsten noch setzen kann, wenn man eben keinen Shell-Zugriff hat oder wie man sich diesen verschafft. Das sind auch nicht nur "Informationsbröckchen" ... selbst wenn es keine umfassende Abhandlung darüber geben sollte. Es mag sein, daß Dich persönlich das bisher nie interessiert hat und Du deshalb diese Beiträge nicht verfolgt hast ... aber wessen Schuld soll das denn sein, wenn nicht Deine eigene? Was denkst Du, wieviele andere einen Shell-Zugang zu einer 6490 haben und denen ist der auch nicht über Nacht gewachsen.

Ich weiß tatsächlich nicht, ob die Suche mit
Code:
site:ip-phone-forum.de featovl.cfg PeterPawn CONFIG*
jetzt so schwer abzuleiten ist anhand der bisher in diesem Thread gegebenen Hinweise ... aber ich weiß genau, daß Du auch nicht der Erste bist, der auf der Suche nach diesen Möglichkeiten ist.

Wie ernst es Dir mit der Suche nach einer Lösung ist, kann ich auch nicht einschätzen ... ich halte einen Zeitaufwand von 4-8 Stunden bei so ziemlich jedem Problem für "erträglich" und wenn jemandem die Lösung eines eigenen Problems (und das ist hier nun mal etwas komplexer, das habe ich mir nicht ausgedacht und wenn es Dir zuviel wird, mußt Du eben nach anderen Alternativen Ausschau halten) diese Zeit nicht wert ist, dann tut es mir leid - aber auch das verpflichtet mich noch nicht, vom "Bestätigungsmodus" (daß jemand auf dem richtigen Weg ist) und ein paar Hinweisen auf mögliche Suchbegriffe, unmittelbar auf "Erklärbär" umzuschalten, nur weil derjenige das bisher nicht gelesen hat und es nun nicht suchen will oder nicht finden kann.

Aber das Argument, daß ich bereits weiß, wonach ich suchen soll, ist insgesamt ziemlich ärgerlich (abgesehen davon, daß ich oben gezeigt habe, daß Du das auch hättest finden können - zumindest nach meiner Ansicht) ... Du darfst darauf wetten, daß auch ich oft genug nach Sachen suchen muß (und sei es ebenfalls im Internet, um irgendwelche Links in Beiträgen anzubringen), von denen ich nicht weiß, wo sie genau stehen und zu denen auch ich mich erst vorarbeiten muß - dazu gehörte u.a. auch Deine konkrete Firmware-Version auf der UM-Box, die ich dazu erst einmal bei mir wieder entpacken mußte, damit ich nach der oben zitierten Fundstelle suchen konnte ... das war sogar ein (fast exklusiver, wobei auch spätere Leser das noch "konsumieren" können) Service nur für Dich. Gern geschehen.

Jedenfalls gehe ich anstelle eigener Recherchen auch nicht hin und heule herum, daß das Internet inzwischen ja sooo groß ist und man nichts mehr finden kann. Allerdings stimme ich Dir ausdrücklich zu, wenn Du damit nur zum Ausdruck bringen wolltest, daß auch jede Recherche (ob nun im Internet oder in der AVM-Firmware) richtig Arbeit machen kann ... nur muß man das halt in Kauf nehmen, wenn man zu Ergebnissen kommen will.
 
Also um die 6490 erstmal zu öffnen (u.a. für CONFIG-Änderungen), muss man eine provideradditive.tar ins TFFS legen. Diesen Post von @tetzlav findet Google schon gar nicht mehr (erst Seite 51, nicht Seite 50), aber damit habe ich ein TFFS-Image erzeugt, welches zu klein ist (2kb, enthält nur das Environment). Das mit tffs_add_file erzeugte Image ist leider immer noch halb so groß wie der originale Dump (128kb gegenüber 256kb) und der Zeitstempel ist nicht nur um 1 verjüngt (8. Byte Dump 1: 0x0D, Dump 2: 0x0C, neues Image: 0x07). Der Inhalt ist aber optisch ähnlich zum originalen Dump und die Nutzdaten sind etwas größer (Dump 1 geht bis Offset 0x30D94, Dump 2 bis 0x1E741, neues Image bis 0x1F177).

Das ganze habe ich übrigens erstmal mit der KDG-Box gemacht, da ich die UM-Box nicht neben mir habe.
 
Wenn der TFFS-Dump aus einer erweiterten Support-Datei stammt, enthält er eine Kopie der beiden TFFS-Partitionen ... für das Erzeugen eines neuen Images braucht es aber nur eine, damit wäre die halbe Größe in Ordnung, solange sie mit der Größe einer einzelnen TFFS-Partition (die findet man auch in den Support-Daten, z.B. in der Ausgabe von /proc/mtd) übereinstimmt.

Die Differenz in der "Version" des Images läßt sich beim "tffs_add_file" meines Wissen einstellen mit irgendetwas wie "-o" (so sieht das Skript für mich jedenfalls aus, wenn ich es im GitHub ansehe) ... steht aber garantiert im 6490-Thread in dem Beitrag, in welchem ich das "tffs_add_file" als "Abkürzung" für die erste Version (das war die mit dem kompletten Zerlegen und neu Zusammenbauen) "vorgestellt" habe.

Ein TFFS-Image (wie es z.B. das Recovery-Programm von AVM auch erzeugen würde) enthält per se auch nichts anderes als eine Name-Table und die entsprechenden Environment-Variablen aus dem Bootloader; da wären 2KB also sicherlich auch in Ordnung - aber eben ein Indiz für eine "zurückgesetzte" Box ohne eigene Einstellungen ... genau das vermeidet "tffs_add_file" ja, indem es nur Dateien hinzufügt und den "kompletten Neuaufbau" des Images umgeht (wenn genug Platz am Ende im Image ist).

Wobei die "featovl.cfg" ja auch Bestandteil des TFFS ist - allerdings könnte die von der Firmware wieder gelöscht bzw. geändert werden, wenn der Provider seinerseits PACM mit abweichenden Einstellungen verwendet - siehe frühere Beiträge zu "avmfeature.conf" und "docsis_feature_disable" (oder so ähnlich) - und darüber irgendwelche Einstellungen in der Datei zurückgesetzt würden.

Das dürfte aber für die beiden Variablen, welche im Moment die Anzeige des Packet-Dumps verhindern, gar nicht der Fall sein ... normalerweise werden per PACM ja nur die Variablen gesetzt, die in der "boxfeaturedisable" zu sehen sind (und diese Datei gibt es auch in jeder DSL-Firmware, selbst wenn sie da nicht benutzt wird) und ggf. noch die SIP-Konfiguration.

Man muß also vermutlich gar nicht bis zum Shell-Zugang kommen ... vielleicht kann man ja auch schon vorher die erwähnte "featovl.cfg" mit dem gewünschten bzw. benötigten Inhalt füllen.

Ob ein eigenes, neues TFFS-Image gültig ist oder nicht, ermittelt man dann am besten dadurch, daß man es noch einmal zerlegen läßt und die dabei entstehenden Einzeldateien mit dem erwarteten Inhalt vergleicht.

EDIT: Die Lücke mit der "provideradditive.tar" hat AVM ja auch irgendwann geschlossen ... ich weiß meinerseits nicht, ob die bei der 06.65 mit KDG-Branding überhaupt noch offen ist - aber selbst wenn das nicht der Fall ist, braucht es für eine "featovl.cfg" ja auch nicht unbedingt diese Lücke, denn die kann man auch "ganz normal" einbauen lassen.
 
Zuletzt bearbeitet:
Die Dumps habe ich mit tffs_from_supportdata aus den Supportdaten erstellt und dabei 2x 256kb Dateien erhalten. Laut den Supportdaten sind beide Partitionen je 256kb groß:
Code:
mtd3    0xc0000,0x100000
mtd4    0x100000,0x140000

Aber die 2. Hälfte besteht nur aus 0xFF - wie gesagt ab Offset 0x1E741.

Dein Tipp, dass entstandene Image einfach wieder zu zerlegen mit dissect_tffs_dump ist so einfach wie genial. Und tatsächlich enthält das neue Image einen Node 29 mit dem komprimierten Inhalt meiner provideradditive.tar. Also würde ich es einfach versuchen.

Aber nun suche ich erstmal nach Infos für einen korrekten Node 215 (featovl.cfg).
 
Aber nun suche ich erstmal nach Infos für einen korrekten Node 215 (featovl.cfg).
Variablen-Name=Wert

Wirf am besten einen Blick in die rc.conf einer beliebigen Box, da wird die Datei "verarbeitet".

Ein Image für den SPI-Flash braucht ja keine überflüssigen binären Einsen zu schreiben, der Flash-Inhalt nach "erase" ist damit ja identisch. Möglich, daß ich auch in "tffs_add_file" nach den letzten hinzugefügten Daten den Rest einfach abschneide, denn da wird ja schon nach dem ersten ungenutzten Bereich gesucht, damit das Skript den Punkt hat, wo es mit dem Hinzufügen beginnen kann. Das weiß ich aber nicht mehr aus dem Kopf, dafür ist das alles schon zu lange her.

EDIT: Ja, die Begrenzung auf den nächsten vollständigen 4K-Block gibt es tatsächlich, aber nur in "tffs_add_file" (https://github.com/PeterPawn/YourFritz/blob/master/tffs/tffs_add_file#L256) und wenn Du mit "tffs_from_supportdata" die Daten extrahiert hast, weiß ich nicht, warum da nicht - je nach Index für die Auswahl der Partition halt mit einem anderen Stand - eine Datei mit 256 KB entsteht. Da wird ja gar nichts be- oder verarbeitet, das ist nur das (automatische) Extrahieren der unveränderten Daten aus der Support-Datei.
 
Zuletzt bearbeitet:

Statistik des Forums

Themen
244,696
Beiträge
2,216,705
Mitglieder
371,316
Neuestes Mitglied
realbluethunder
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.