Kann das sein? Remote-Konfiguration der 7360 verhindert Firmware-Upgrade?

TR069 war schon vor Jahren ein Thema in diversen Foren. Wer eine FritzBox ohne Branding hat,
bei dem ist das deaktiviert.
Das ist doch mal eine Aussage! Wenn sie denn stimmen würde. :?
spixx hat zum Beispiel eine Fritzbox 7360 ohne Branding. Dann braucht er sich also keine Sorgen zu machen? ;)

Der SBC (ich meine jetzt den Session Border Controller), wenn es ihn denn bei deinem Provider gibt, wovon ich nicht ausgehe, hat mit TR-069 nichts zu tun. Der wäre zum Mithören auch gar nicht notwendig, denn die TR-069 Daten gehen doch sowieso direkt zum Provider.
 
Zuletzt bearbeitet:
Ich weiß jetzt nicht wie ihr "branding" genau definiert, aber wie in Beitrag #17 geschrieben war provider=additive bei mir aktiviert. Ansonsten hatte die Box aber firmware_version=avm im Environment gesetzt.
 
[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Foren-Regeln]

hmm, seltsam. Das Problem ist schon das provider additive. Dies stellt sicher, dass die Box ihren Weg zum Provider findet und
ggf. TR069 für den ACS aktiviert. Ich meinte so eher eine Box aus dem Laden. Dort hat der Provider per default keinen Zugriff über TR069.
Er kann die Box zwar sehen, aber nicht erreichen.
 
Ich habe das so verstanden: ich habe zwei Boxen:
1. Box direkt vom Provider (7360) mit provider=additive im Environment, aber ansonsten mehr oder weniger nicht speziell für den Provider eingerichtet (u.a. firmware_version=avm)
2. Box selbst gekauft (7390) da gibt es im Environment kein provider=additive
Und wegen der 1.Box fragte ich eben wie "branding" definiert ist. Genügt die Veränderung des environment zur Definition des "branding", dann ist meine 1. Box "ge-brandet". Bedeutet "branding" aber, dass z.B. eine Firmware-Anpassung stattfinden muss (firmware_version <> avm), dann ist meine 1. Box nicht "ge-brandet".

Bzgl. des "provider=additive" gehe ich deshalb davon aus, dass damit bei mir die Konfiguration per TR-069 getriggert wird und die initiale Installation stattfinden kann. Es gibt da eben noch diesen tarball provideradditive.tar der auf der o.g. 1.Box hinterlegt ist (siehe Beitrag #17). Da dieser tarball speziell für meinen Provider ist, gehe ich mal davon aus, dass ein out-of-the-store FritzBox keine derartigen Dateien enthält und damit auch kein Initialisierung per TR-069 vorsieht.
 
Zuletzt bearbeitet:
@SBC
Mir sind da ein paar Sachen nicht klar, die Du erwähnt hast. Vielleicht findest Du einen Moment Zeit mir kurz darauf zu antworten.

(1) Du schreibst, dass "bei allen Providern i.d.R. ein SBC" eingesetzt wird. Heißt das, dass auch etwas anderes eingesetzt werden kann? Wenn ja, was? Oder auch gar nichts?
(2) Laut Deiner Beschreibung gehe ich davon aus, dass der SBC weitestgehend transparent, also von mir bei Überwachung des PPPoE-Traffic nicht entdeckt werden kann. Stimmt das?
(3) Wie oben geschrieben läßt sich mein Provider alle acht Stunden die Situation auf der CPE-Seite mitteilen (INFORMATION REQUEST). Darin stehen sowohl Seriennummer der FritzBox also auch Firmware-Version, etc. Wie wahrscheinlich ist es, bzw. welcher Aufwand muss betrieben werden, dass der Provider diese Information (vielleicht sogar zusammen mit der MAC-Adresse der FritzBox) auswertet, um den Anschluß (über den SBC) überhaupt frei zu schalten? Also wenn ich anfangen würde rumzuwerkeln könnte das ganze schon deshalb zum Scheitern verurteilt sein, weil genau diese FritzBox mit genau dieser Firmware an genau diesem DSLAM-Port erwartet wird?
(4) Wenn ich die FritzBox durch eine andere oder die o.a. Kombi aus Modem/FW-appliance kann der Provider dies entdecken? Wie wird möglicherweise verfahren?

zu 1.: so ein SBC kann verdammt teuer sein. Wir reden hier von 1. Million Euro. Er stellt auch die Schnittstelle für Behörden da, um
gezielt Daten abzugreifen. Nun gibt es ja viele kleine Provider, die nur kleine Orte mit paar Einwohner versorgen (Stadt Netze)
Da kann es denn mal sein, dass kein SBC eingesetzt wird.

zu 2.: so soll es jedenfalls sein. Fragt dein PC per https eine Seite an, sieht es so aus: Client >SBC< Server. Keiner merkt, dass
der SBC dazwischen hängt, da nur bis zum SBC verschlüsselt wird. Ein Client kommt da nicht drüber hinaus.

zu 3.: ich habe mir das Netz mit Wireshark angeschaut und den nächsten DSLAM / Switch ein wenig geärgert.
Nachdem dieser zufällig ein reboot durchgeführt hat, habe ich diverse VLAN's entdeckt und analysiert. (Portisolation / Filter waren aus)
Da wären welche für SmartMeeter, Multi-IAD's, Voip+PPPOE getrennt. Die VLAN ID kann ich unter Linux meinem
Interface zuweisen und dann dort mit Wireshark reinschauen. Ich habe auch schon Netze gesehen, wo die VLAN's generell
sichtbar sind, da das Netz für eigene Router untagged sein muß. Bei O2 werden die Ports am DSLAM dem Kunden
explizit zugeordnet. Das ist aber nicht bei jedem Anbieter so. Die PPPOE Einwahldaten sind im Klartext sichtbar,
wenn sie zum Radius oder LAC übermittelt werden. Ich habe meiner Linux Kiste also das PPPOE VLAN zugewiesen und
die Einwahl entsprechend auf das getaggte Interface umgeleitet. Die MAC von der Provider Box gecloned.
Eine harte Nuss war ein Anschluß mit Kabelmodem (FritzBox 6360). Bei DOCSIS 3 Modems kann man die MAC
nicht clonen. Also mußte ich es gegen ein DOCSIS 2 Modem tauschen. Es treten zwar Fehler auf, weil der Hersteller
nicht paßt und der Provider dort eine ungültige Config rauf schicken will. Die schadet dem Modem aber nicht.
Performance ist bei DOCSIS 2 leider begrenzt. 30 bis 40 MBit bekommt man durch, je nachdem wie hoch die Auslastung
von diesem einem 50 MBit Kanal ist.

Alle Boxen mit aktivem TR069 melden sich in regelmäßigen Abständen beim Provider. Änderungen seitens des Kunden
werden entdeckt, aber häufig nicht weiter beachtet. Sobald ein Kunde jedoch beim Support anruft, wird dieser ggf. verweigert.
Wer Störungen verursacht wird gesperrt. Daher würde ich die original Box nicht weiter anfassen und im Schrank liegen lassen.
Bei Hansenet hatte ich jahrelang ein Router mit geänderter MAC Adresse laufen. Irgenwann bekam ich ein Anruf, dass der Router
nicht richtig reagieren würde und ein Techniker diesen austauschen würde :) Die hatten zwei VLANs laufen. PPPOE und IP-TV

Die nächste Bausstelle ist DS-Lite. Furchtbare Sache. Wenn dein Provider dich umstellt, hast Du erstmal verloren.
Für Linux gibt es eine Anleitung, wie man per Trick DS-Lite zum laufen bekommt. Fritzboxen unterstützen DS-Lite mit der
neuen Firmware. Dort kann man den aftr per Hand eintragen.

Bisher sind alle Leute (auch Datenschutzbeauftragte) bzgl. TR069 gescheitert. Ist doch klar, der Aufwand um an die
Gesprächsdaten zu kommen ist viel geringer und geht ohne Umweg über einen Richter.
 
Fragt dein PC per https eine Seite an, sieht es so aus: Client >SBC< Server. Keiner merkt, dass
der SBC dazwischen hängt, da nur bis zum SBC verschlüsselt wird. Ein Client kommt da nicht drüber hinaus.
Wie kommst Du denn auf das schmale Brett? :?
eine https-Seite wird per Zertifikat und Ende-zu-Ende-Schlüsseltausch verschlüsselt vom Server ausgeliefert. Der Provider hat keine Möglichkeit, den Inhalt zu sniffen, wenn er nicht die Zertifikate und Schlüssel austauscht. Das aber bedeutet, dass ein Abruf einer Bankseite nur noch bis zum Provider mit einem falschen = nicht zum Ziel passenden Schlüssel chiffriert wird, diese dort entschlüsselt und gelesen wird und mit einem neuen Schlüssel weitergereicht würde, der aber nicht zum vermeintlichen Absender passt. Gerade das fällt aber jedem 0815-Browser ebenso auf, wie dem https-Server, der daraufhin seine Verbindung kappt. Mitsniffen von https-Seiten geht nur mit roher Gewalt, also Brute-Force-Angriffen auf den Schlüssel.

Ist ja nicht der erste Lapsus, mit dem Du Dich arg weit aus dem Fenster lehnst. Pass auf, dass es nicht nach unten geht...
 
Ich hatte mich über die Ausführung über SSL auch gewundert...

Denn wenn ich das richtig verstanden habe, dann müßte dieser SBC in der Mitte über den privaten Schlüssel beispielsweise der Bank, vom Amazon etc. verfügen, um den Session-Key zu entschlüsseln ...
Das würde nach meinem Verständnis, so denn generell einige dieser SBC im Besitz solcher privaten Schlüssel sein sollten, generell den Mechanismus SSL/TLS etwas konterkarieren.
 
Suche mal nach G10 Auflage. Im Artikel 10 des Grundgesetzes ist das Belauschen geregelt.
Nochmal zum SBC. Dieser übernimmt bei Voip die Funktionen vom Registrar und SIP Proxy. Ein SBC bügelt durch NAPT verursachte Inkonsistenzen aus. Er trägt sich selbst als Absender in die INVITE Nachrichten ein !!! Dadurch zwingt er die Medienströme auf sich.
Eine Verschlüsselung / Austausch des Session-Keys kann als Klartext mitgelesen werden. Ein SBC wird als Man-in-the-middle dargestellt. Ein Client merkt dies nicht, da der Austausch nur mit dem SBC statt findet. Also das Thema hatte ich vor über 6 Jahren. Sicher sind nur richtige Ende-zu Ende Verschlüsselungen, wenn ich den Key wie bei VPN direkt zum Endgerät bringe. Sobald aber ein Key-Exchange statt findet, kann man das vergessen.
Die Sache mit https war so nich ganz richtig. Danke für den Hinweis. HTTPS ist aber auch nicht gleich HTTPS. Ich empfehle mal unter Heise Security nach: Browser-SSL entschlüsselt
zu suchen. Dort wird nebenbei auch nochmal auf einen Proxy als Man-in-the-middle hingewiesen.



Gruß, SBC
 
Für mich ist das obige irgendwie höhere Mathematik. Ein wenig habe mich aber schon beim SSL schlau gelesen, das Thema war ja auch in der jüngeren Vergangenheit ausreichend beleuchtet worden.
Ich hatte mich über die Ausführung über SSL auch gewundert...
Wer aber schon beim kleinen Einmaleins solche handwerklichen Fehler einbaut... ich weiss ja nicht, da zweifel ich dann schon an den gesamten Ausführungen. Paddon, ist halt so, werter SBC
 
Solche Kleinigkeiten können halt passieren, wenn jemand mit dem gesammelten Halbwissen der letzten zwanzig Jahre um sich wirft. ;)
Ich bin IT Systemelektroniker und nutze Verschlüsselung schon seid 1995, sowie PGP für EMails seid 1997.
Mit den alten GSM Handys konnte man schon immer durch modifizierte Firmware Gespräche im Mobilfunknetz abhören.

Nebenbei geht das Anliegen des TE vollkommen unter, denn das ganze hat nichts mehr zu tun mit dem eigentlichen Thema dieses Threads: Kann das sein? Remote-Konfiguration der 7360 verhindert Firmware-Upgrade?
 
Ich empfehle mal unter Heise Security nach: Browser-SSL entschlüsselt
zu suchen.

Der Artikel hat nichts mit der Frage zu tun, ob solch ein SBC in der Lage ist, in-the-middle SSL-Inhalte zu belauschen. Vielmehr beschreibt er die Möglichkeit (vorausgesetzt, eine bestimmte Umgebungsvariable ist gesetzt), daß ein Package-Sniffer uter Kenntnis der Schlüssel lokal die Ströme on-the-fly decodieren kann.

Es bleibt immer noch die Frage, wie ein SBC an zahlreiche signierte private Schlüssel (von Banken, Online-Stores, Web-Mails etc.) zur Dekodierung der vom Client einlaufenden Datenströme gelangt.
Verschlüsselt wird der Session-Key nach meinem Verständnis lokal auf dem Client, dieser Vorgang nimmt also am Netzverkehr nicht teil. Und bei TLS/SSL werden, glaube ich, niemals unverschlüsselte Session-Keys ausgetauscht: U.A. gerade das ist der Sinn von TLS/SSL. Schau z.B. mal hier.
Beste Grüße,

JD.
 
Nach diesem kleinen Exkurs wenden wir uns doch bitte wieder dem Thema zu, wie es auch schon KunterBunter so nebenbei erwähnte... ;)
 
Aber interessant ist das alles allemal :)

Ich will mal zusammenfassen was ich bisher verstanden haben:

Meine vom Provider zur Verfügung gestellte FritzBox 7360 wird über TR-069 konfiguriert und administriert. Um das zu verhindern stehen prinzipiell folgende Möglichkeiten zur Verfügung:
  • Austauschen der 7360 gegen eine 7390 mit Übernahme der Konfiguration und Abschalten des TR-069; das bedeutet aber das vom Provider zur Verfügung gestellte CPE zu entfernen. BTW, mein Vertrag beinhaltet keinerlei Klauseln, dass die Verbindung nur über diese 7360 erfolgen darf/muss.
  • Ich könnte aber auch an der 7360 das WLAN ausschalten und meine 7390 dahinter hängen und mit dieser die Internetverbindung nach innen zur Verfügung stellen. Problem hierbei ist jedoch dass die drei PPPoE-sessions (Internet, VoIP, TR-069), die auf der 7360 derzeit existieren, nur die Internet-session auf die zweite FritzBox weitergeleitet wird. Die voip-session kann aber nicht weitergeleitet werden. Somit müßte ich DECT über die 7360 und Internet über die 7390 machen. Das ist aber Mist, da die steinalte Firmware nicht gerade toll mit dem Telefonen umgeht (haben schon einige Reboot gemacht). Da die 7360 auch initial die SIP-session herstellt kann ich nicht über die Internet-Vebindung an der Voip-Verbindung vorbei eine zweite sip-session aufbauen. Jedenfalls befürchte ich das.
  • ich könnte die 7360 abklemmen und gegen eine DSL-Modem/FW-Appliance/Linux-Host-Kombination austauschen. Das wäre der größte Schritt, sowohl finanziell, als auch vom Aufwand her. Dann stellt sich allerdings wieder die Frage, wie ich dann über die extra PVC für VoIP die DECT-Telefone ansteuere (wieder über die FritzBox?). Die PPPoE-session für diese PVC kann ja nur derjenige aufmachen, der auch die notwendigen VLAN-tags einsetzt.
    Vielleicht müßte ich einen eigenen SIP-Server aufsetzen, der wiederum an den Provider-SIP weiterleitet. Wäre vielleicht ein Möglichkeit, dann könnte ich aber die DECT-Telefone in die Tonne kloppen.
  • Ich lasse alles so wie es ist und den Provider lustig alles auskundschaften.
 
Ich würde zunächst mal, wie ich bereits weiter oben schrieb, versuchen, die Konfiguration der 7360 zu sichern und soweit als möglich wieder in der 7390 zu übernehmen.
Alternativ dazu kannst Du versuchen, das auf Deiner 7360 aktuell laufende (.05.50 ?) Image sicherheitshalber hier herunter zu laden, mittels ruKernelTool ein Image Deiner Wahl auf die Box zu flashen und die Sicherungen zurück zu spielen.
Falls das nicht zu Deiner Zufriedenheit funktionieren sollte, kannst Du mittels des Tools die "alte" Firmware und die Sicherungen zurück spielen.
Desweiteren ist Dein Problem grob ähnlich zu einer anderen Routerzwang-Problematik, die hier im Forum auch schon diskutiert wurde (Alice-IAD). Es existiert eine (ältere) Anleitung, mit der Du mithilfe des Paketmitschnittes der Box selber den Kontakt zum DSLAM mitschneiden und aus diesem Deine gesamten Zugangsdaten (Internet und VoIP) extrahieren kannst. Diese kannst Du dann, falls die Lösung mit dem Sichern/Übernehmen nicht funktioniert, händisch in Deiner Box eintragen.
Heißt: So wie ich das sehe, existiert kein (technischer) Grund, der ein Firmware-Update einer/Deiner Box verhindern könnte (da es bis dato auch kein AVM-Image mit Stadtwerke-Konstanz-Branding gibt ;) )
Grüße,

JD.
 
Zuletzt bearbeitet:
Ja das werde ich machen.

Vielen Dank an alle für die Unterstützung und die Informationen. ;) :lamer:
 
Das ist aber Mist, da die steinalte Firmware nicht gerade toll mit dem Telefonen umgeht (haben schon einige Reboot gemacht).
Wie bereits erwähnt, kannst du versuchen, mit dem ruKernelTool einen Firmware Upgrade von 124.05.50 auf 124.06.01 zu machen. Wenn du dabei die Option "Clear MTD 3+4" nicht anhakst, bleibt die gesamte Konfiguration erhalten. Auf die gleiche Weise kannst du notfalls auch wieder einen Downgrade auf die ursprüngliche Firmware-Version machen, falls irgend etwas nicht funktionieren sollte. Die Konfiguration solltest du vorher zusätzlich mit Passwort sichern.
 
Zuletzt bearbeitet:
Moin,

also ruKernelTool wird bei neu ausgelieferten Boxen eigentlich nicht mehr funktionieren. AVM hat wegen Beschwerden der Provider
nachgebessert und unterbindet die Nutzung. Habe selbst gerade zwei Boxen bei Freunden gehabt.
Ich habe bei meiner original Box ohne Branding die default Einstellungen gesichert (exportiert) und mit den gebrandeten Boxen
verglichen. Bei den TR069 Einstellungen habe ich die Server Adressen entfernt und verstecke bzw. ausgeblendete Einstellung
der Web-Gui wieder aktiviert. Es gibt ein Script "fb_calcsum.vbs", mit dem kann man die richtige Checksumme vom Export berechnen
und dann wieder zurück in die Box spielen. Die Export Datei natürlich nur mit einem richtigen Text Editor (Unix/Linux) editieren.
Bei einer 6360 konnte ich so den Bridge Modus aktivieren. Dann arbeitet die Box nur noch als Modem.
Bei einer 7360 sollte man so auch wieder die Update Funktion aktivieren können. Alternative bei ganz harten Fällen hilft
auch ein ur altes original Recover File von AVM. Das zeigt zwar an, dass die Box Provider Einstellungen enthält, bricht aber
den Flash Vorgang nicht ab!

Gruß, SBC
 
Das ruKernelTool kann zur Zeit nicht für Fritzboxen mit der neuen Flashaufteilung genutzt werden.(7490, 7272 7362 SL 3370,3390)
Das ist bekannt.An der Lösung des Problems wird gearbeitet.Das kostet nicht nur Zeit,sondern auch Geld,da Probeboxen beschafft werden müssen.
Ich kann jedenfalls die M-Net Boxen mit der Evironment-Variable(7360 und 7390) und den EWE Boxen eigene Firmware (7360 und 7390) mit dem ruKernelTool
bearbeiten.
Du müsstes Tante Google bemühen.
 
Hallo zusammen, ich bin jetzt eine Stufe weiter gegangen: 7390 auf die Einstellungen der 7360 eingestellt, ebenso firmware auf 05.50 reduziert, dazu dann noch die tr069-forward-rules ausgeschaltet und firewall-rules installiert, die einen Zugriff auf Port 8089 unterbinden. Dann nach dem Start der 7390 wieder die pcap-Mitschnitte aktiviert und das DSL-kabel eingesteckt. Groß war die Freude, als nach ca. 30-40 Sekunden die DSL-Verbindung stand und danach sofort auch die Internetverbindung und die Telefonverbindung zustande kam. Dann aber flackerte plötzlich die INFO-LED (habe ich auf Internetverbindung aktiv gelegt) und nichts ging mehr. Also die pcap-files analysiert. Es ist einfach unglaublich was da passiert. ich habe zwei Verbindungen eingerichtet: die vopi-PPPoE-session funktioniert problemlos, aber auf der internet-session geht der Punk ab. Nachdem die IPs über DHCP zugewiesen sind, hat die 7390 plötzlich ein DNS-resolving auf den ACS-Server des Providers veranstaltet! Was denn? Warum denn? Wie denn? Und danach wird eine Verbindung zum ACS über die regular Internetverbindung aufgebaut, sämtliche FritzBox-Infos bei diesem abgeliefert (INFORM-push) und danach ein download eines neuen Images von diesem eingeleitet. Interessant ist natürlich, woher kommt die URL für den ACS-server? Die steckt in den DHCP-Vendor-Specific-Options (siehe wireshark-output). Aber erstaunlich ist, dass die FritzBox damit offensichtlich etwas anfangen kann. Sie beginnt nämlich einen Fernwartungszyklus. Das ist wirklich heftig.

Weiß jemand, wie man die offensichtlich von AVM so implementierte automatische Aktion durch Option #43 in den DHCP-Daten unterbinden kann?

Code:
No.     Time        Source                Destination           Protocol Length Info
      1 0.000000    0.0.0.0               255.255.255.255       DHCP     594    DHCP Discover - Transaction ID 0x6d6e9a6b
      4 0.253297    0.0.0.0               255.255.255.255       DHCP     594    DHCP Discover - Transaction ID 0x6d6e9a6b
     13 *REF*       185.36.44.1           185.36.44.212         DHCP     376    DHCP Offer    - Transaction ID 0x6d6e9a6b

Frame 13: 376 bytes on wire (3008 bits), 376 bytes captured (3008 bits)
Bootstrap Protocol
    Message type: Boot Reply (2)
...
    Option: (53) DHCP Message Type
        Length: 1
        DHCP: Offer (2)
    Option: (43) Vendor-Specific Information
        Length: 33
    Option: (255) End
        Option End: 255
...
    Option: (43) Vendor-Specific Information
        http://acs.tk-bodensee.net:9675     <<<<<<<<<<<<<<<<< das kommt vom Provider huckepack im DHCP-OFFER und DHCP-ACK

     14 0.000343    0.0.0.0               255.255.255.255       DHCP     594    DHCP Request  - Transaction ID 0x6d6e9a6b
     18 0.022904    185.36.44.1           185.36.44.212         DHCP     376    DHCP ACK      - Transaction ID 0x6d6e9a6b

Frame 18: 376 bytes on wire (3008 bits), 376 bytes captured (3008 bits)
Bootstrap Protocol
    Option: (43) Vendor-Specific Information
        Length: 33

    Option: (43) Vendor-Specific Information
        http://acs.tk-bodensee.net:9675     <<<<<<<<<<<<<<<<< das kommt vom Provider huckepack im DHCP-OFFER und DHCP-ACK

    140 9.606248    2a03:80:600:0:c56c:b630:6297:2901 2a03:80:0:80::53      DNS      103    Standard query 0x2b8b  A acs.tk-bodensee.net
    143 9.639273    2a03:80:0:80::53      2a03:80:600:0:c56c:b630:6297:2901 DNS      265    Standard query response 0x2b8b  CNAME acs03.tk-bodensee.net A 31.47.80.101
    144 9.640436    185.36.44.212         31.47.80.101          TCP      78     37117 > 9675 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=4335 TSecr=0 WS=4
    145 9.654574    31.47.80.101          185.36.44.212         TCP      78     9675 > 37117 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=1251042072 TSecr=4335 WS=128
    146 9.655244    185.36.44.212         31.47.80.101          TCP      70     37117 > 9675 [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=4339 TSecr=1251042072
    149 9.677768    31.47.80.101          185.36.44.212         TCP      70     9675 > 37117 [ACK] Seq=1 Ack=142 Win=6912 Len=0 TSval=1251042078 TSecr=4341
    150 9.678220    185.36.44.212         31.47.80.101          HTTP/XML 1193   POST / HTTP/1.1 
Frame 150: 1193 bytes on wire (9544 bits), 1193 bytes captured (9544 bits)
Hypertext Transfer Protocol
    POST / HTTP/1.1\r\n
    Host: acs.tk-bodensee.net:9675\r\n
    Content-Length: 2571\r\n
    Content-Type: text/xml; charset="utf-8"\r\n
    SOAPAction: "cwmp:Inform"\r\n  <<<<<<<< die INFORM-action
    \r\n
    [Full request URI: http://acs.tk-bodensee.net:9675/]
    [HTTP request 1/5]
    [Response in frame: 153]
    [Next request in frame: 155]
eXtensible Markup Language
    <soap:Envelope
        xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:cwmp="urn:dslforum-org:cwmp-1-0">
        <soap:Header>...</soap:Header>
        <soap:Body>
            <cwmp:Inform>
                <DeviceId>
                    <Manufacturer>
                        AVM
                        </Manufacturer>
                    <OUI>
                        00040E
                        </OUI>
                    <ProductClass>
                        FRITZ!Box
                        </ProductClass>
                    <SerialNumber>...</SerialNumber>
                    </DeviceId>
                <Event
                    soap-enc:arrayType="cwmp:EventStruct[2]">
                    <EventStruct>
                        <EventCode>
                            1 BOOT       <<<<<<<< Soll wohl heißen, dass das die im BOOT-Falle übergebenen cwmp:Inform Daten sind.
                            </EventCode>
                        <CommandKey>
                            </CommandKey>
                        </EventStruct>
                    <EventStruct>
                        <EventCode>
                            0 BOOTSTRAP
                            </EventCode>
                        <CommandKey>
 
also ruKernelTool wird bei neu ausgelieferten Boxen eigentlich nicht mehr funktionieren. AVM hat wegen Beschwerden der Provider
nachgebessert und unterbindet die Nutzung.

Ich habe aktuell bei einer 7360(v1), sog. Edition M-Net, mittels ruKT u.A. eine FW 124.05.50 komplikationslos auf diese Box geflasht. Also insbesondere eine FW, die für 32 MB Flash (7360v2) vorgesehen war, auf eine Box mit 16 MB. Desweiteren kann ich auch mittels ruKT die (internationale) 111.05.50 auf Box flashen, alles ohne Probleme. Einzig firmware_info muß im Environment angepaßt werden.
Ich kann das gerne noch mit weiteren FW testen.
Grüße,

JD.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,159
Beiträge
2,247,074
Mitglieder
373,678
Neuestes Mitglied
brainkennedy
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.