[Info] FRITZ!Box 7490 Labor-Firmware Version 6.10-27982 vom 13.05.2014

Ich hoffe das Feature ist nicht entfernt worden, weil genau solche Scripting-Möglichkeiten die fritzbox von anderen unterscheidet.
Es hat den Anschein, als ob AVM auch dort "aufgeräumt" hat. Das Binary telefon in dieser Labor-Version enthält jedenfalls die komplette "/var/calllog"- und "/var/flash/calllog"-Behandlung offenbar nicht mehr (sagt 'strings', mir war es noch gar nicht aufgefallen). Wenn sie es nicht in eine Library ausgelagert haben, werden sie es wohl abschalten.

Wenn das so weitergeht müssten wir am Ende wohl froh sein, falls uns der CallMonitor erhalten bleiben sollte.
 
...ja entweder über freetz. Ich hatte eher dran gedacht ein QNAP-Plugin zu bauen, der ständig auf Anrufe an der Fritzbox lauscht (das geht ja weiterhin) und dann bei bedarf die entsprechenden Kommandos an Geräte im Heimnetz schickt.
Den Code könnte man sich vom VDR-Fritzbox-PI "klauen".
ABer jetzt warte ich mal ab, ob da AVM noch was dran dreht. Ist evtl nur ein Fehler. Ja oder was ich mir auch noch vorstellen kann ist, dass AVM die Funktion umgebaut hat, sodaß man das jetzt erst per TelefonKommando freischalten muss und per default deaktiviert ist.

Ryker
 
Nach dem Wiederherstellen einer aus dieser Labor-Version gesicherten Konfiguration funktioniert das Konfigurieren der DECT-Mobilteile nicht mehr.

Ablauf:
1. Recover auf 06.05 nach mißglückten Experimenten
2. Update auf Labor-27982
3. Restore Settings (gesichert vor den Experimenten)

Ergebnis:
Es ist weder möglich, vorhandene Mobilteil-Definitionen zu löschen
Code:
Es ist ein Fehler aufgetreten.
Fehlercode: nil
Bitte geben Sie Ihre Daten noch einmal ein. Sollte der Fehler erneut auftreten, wenden Sie sich bitte an den AVM-Support.
noch ist die Anmeldung neuer Geräte (bisher sind nur 2 angemeldet, die natürlich nach dem Recover nicht funktionieren) möglich. Der DECT-Assistent meldet nach 2 Sekunden eine erfolgreiche Anmeldung (stimmt natürlich nicht) und der allgemeine Telefoniegeräte-Assistent deaktiviert den DECT-Radiobutton mit dem Hinweis "belegt".
 
Ja oder was ich mir auch noch vorstellen kann ist, dass AVM die Funktion umgebaut hat, sodaß man das jetzt erst per TelefonKommando freischalten muss und per default deaktiviert ist.
Ein Hook (es Schnittstelle zu nennen weigere ich mich), der schon bisher nur per Telnet von "Experten" zu nutzen war, jetzt erst nach "Freischaltung" (egal welcher Art) ?

Ist für mich irgendwie nicht schlüssig ... da ist die Erklärung mit der übereifrigen Reingungskraft für alte Code-Fragmente in meinen Augen näherliegender und ich bin mal gespannt, was neben den bisherigen Erkenntnissen (debug.cfg entsorgt, -c-Switch bei allcfgconv entfernt, nun calllog-Script gekillt) noch alles ans Tageslicht kommt. Spätestens bei der Abschaltung des Telnet-Daemons auch in den Nicht-DOCSIS-Boxen ist für mich dann allerdings Schluß mit lustig ...
 
Schau mal, ob DECT noch eingeschaltet ist. Den Fehler beim Löschen von DECT-Geräten hatte ich auch schon, da war DECT aus irgendwelchen Gründen aus. Nach dem Einschalten von DECT konnte ich die DECT-Telefone dann löschen. Nach dem Löschen des letzten war DECT automatisch wieder aus.
 
Zuletzt bearbeitet von einem Moderator:
Schau mal, ob DECT noch eingeschaltet ist.
Ist definitiv eingeschaltet ...

Ich habe auch ausprobiert

1. Box mit aktiviertem DECT starten
2. Box mit deaktiviertem DECT starten und es nachträglich aktivieren

Alles in der Hoffnung, daß dann das Laden des SC14488-Microcodes (ist das bei einer 7490 eigentlich noch ein SC14488 ?) etwas anders abläuft und die Kommunikation mit dem Chip über die serielle Schnittstelle andere Ergebnisse zeigt.

Leider kein Erfolg ... wenn ich mit meinen Experimenten fertig bin, wird wohl wieder eine komplette Neueinrichtung fällig sein.

Mit der dann frischen Konfiguration werde ich das Ganze noch einmal in der beschriebenen Reihenfolge testen und ggf. per Feedback-Formular an AVM melden (auch wenn das nach meinen Erfahrungen häufig umsonst ist).

Edit:
Erledigt ... mein Fehler. Eine manuelle Änderung des Boxnamens in der ar7.cfg bringt auch das komplette DECT-Equipment durcheinander, da der Boxname zusätzlich als Name der Basisstation verwendet wird (läßt sich m.W. nicht verhindern) und dieser offenbar auch in die ausgehandelten gerätespezifischen Schlüssel mit eingeht.
 
Zuletzt bearbeitet:
Seit den Labors dieser FW-Reihe werden die Anruferbilder auf meinen MT-Fs (22er-Labor) nach dem Update nicht mehr synchronisiert. Ich muss die MT-Fs erst neu starten, dann ist's wieder ok. Weiß allerdings nicht, ob Box- oder MT-F-Problem. (Oder meins?;)
 
Ich wollte heute über das Web-IF alle aufgelaufenen AB-Nachrichten löschen, aber es wurde nur immer die älteste gelöscht...? Keine Ahnung, ob das schon länger so ist...

Und eine Frage schon in der 27909 heißt es:
  • Telefonie/DECT: Erweiterte Funktionalität für Gigaset Handgeräte

Habe keinerlei Änderungen bemerkt und auch nix drüber gelesen...? Habt ihr was bemerkt?
 
Ein weiteres "wegoptimiertes" Feature ist wohl das externe Bearbeiten von Konfigurationsdateien.

Durch diesen Beitrag aufmerksam geworden, habe ich verschiedene Möglichkeiten durchprobiert.

Das direkte Modifizieren auf der Shell der Box funktioniert noch ... alle Versuche, eine modifizierte externe Sicherung einzuspielen, sind aber gescheitert.

Edit:
Das Bearbeiten mit FBEditor funktioniert doch, wenn man nur die richtige Version des FBEditor verwendet. Pikachu machte mich darauf aufmerksam, daß die Prüfsummenbildung in älteren Versionen noch nicht funktionierte.

Mit dem "NoChecks=yes"-Parameter beiße ich - ohne korrekte Prüfsumme - aber immer noch auf Granit.
 
Zuletzt bearbeitet:
Hat jemand inzwischen ein eigenes SSL Zertifikat ans Laufen gebracht? Ich nach wie vor nicht... ;(
 
Hat jemand inzwischen ein eigenes SSL Zertifikat ans Laufen gebracht? Ich nach wie vor nicht... ;(
Ich auch nicht mit dem neuen Interface (es bleibt beim Einrichten per Hand) ... mir ist noch nicht einmal die geplante Vorgehensweise von AVM richtig klar.

Bisher führte ja jede Änderung eines möglichen DNS-Namens (Boxname, My!Fritz, DynDNS) der Box zur Generierung eines neuen Webserver-Zertifikats, der private Schlüssel (2048 Bit) wurde nur neu erzeugt, wenn er nicht vorhanden war oder nicht geöffnet werden konnte, weil das boxspezifische Kennwort dafür falsch war.

Der FTP-Server ließ sogar bei jedem "AUTH TLS"-Kommando erst einmal ein neues Zertifikat (mit dem PrivKey des Webservers) generieren, das wurde nie über die Lebenszeit einer ftpd-Instanz (die wird ja per inetd gestartet) hinaus persistiert.

Ist das jetzt vorbei und AVM akzeptiert einen beliebigen CN und beliebige Alternativen oder muß das hochgeladene Zertifikat alle möglichen Namen auch enthalten ?
Wenn alle Namen vorhanden sein müssen (also auch solche wie der interne "fritz.box"), dürfte die Verwendung eines gekauften "offiziellen" Zertifikats etwas kompliziert werden.

Die neue Firmware verhält sich von den alternativen Namen her genauso, d.h. dort sind alle möglichen internen Namen genauso enthalten, wie die zwei externen (MyFritz+DynDNS).

Andererseits ist es aber jetzt wohl so, daß sie nach dem einmaligen Generieren eines Zertifikats auf der Box alle folgenden Änderungen (My!Fritz an/aus, DynDNS an/aus) ignoriert.

Da ich hier erst nach dem Update der Firmware die Einstellungen am Stück wiederhergestellt habe, lag also zum Zeitpunkt der automatischen Generierung des Zertifikats schon eine gültige Liste von Adressen vor. Wie sich das jetzt beim nachträglichen Einschalten von DynDNS/My!Fritz verhält, will ich nicht selbst testen.

Oder will AVM am Ende nicht nur ein Zertifikat, sondern auch einen privaten Schlüssel per Upload haben ? Die Zeichenketten
Code:
-----BEGIN
 CERTIFICATE--
 PRIVATE KEY--
-----END
aes128
deuten darauf hin. Wenn man dann noch die Funktionsnamen "PEM_read_RSAPrivateKey" und "PEM_write_RSAPrivateKey" findet, könnte man ja eine Datei mit dem Zertifikat und dem privaten Schlüssel hintereinander im PEM-Format (wenn der private Schlüssel mit einem Kennwort geschützt, dann mit
Code:
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC ...
als korrektes Format annehmen.

In jedem Falle gehe ich davon aus, daß AVM bei den möglichen Permutationen zu diesem Thema (Schlüssellängen, Algorithmen) nur wenige Kombinationen wirklich zulassen wird. Damit dürfte ein privater RSA-Schlüssel mit einer Länge von 2048 Bit der Ausgangspunkt sein.

Aber bei allen Experimenten (verschlüsselt oder nicht, falsches/richtiges Kennwort, usw.) kommt immer dieselbe Meldung "Invalid variable name.". Da das hochgeladene Formular syntaktisch richtig ist (sagt ein Wireshark-Mitschnitt), kann eigentlich nur noch eine Diskrepanz zwischen Formular und "firmwarecfg"-Binary die Ursache sein oder vielleicht ist auch der komplette Codeteil zum Zertifikat-Import zwar in "firmwarecfg" enthalten, aber nicht "scharf geschaltet". Die im Formular verwendeten Namen "BoxCertPassword" und "BoxCertImportFile" finden sich jedenfalls in exakt dieser Schreibweise in 'firmwarecfg' wieder.

Besser wäre aber sicherlich ohnehin das Generieren eines entsprechenden CSR durch die Box und der Upload des resultierenden Zertifikats nach dem Signieren. Dann würde der private Schlüssel auch die Box nicht verlassen.

Aber selbst ein funktionierender Upload eines Zertifikats inkl. privatem Schlüssel wäre schon eine erhebliche Erleichterung gegenüber der "händischen" Vorgehensweise.

Jedoch sieht das im Moment alles schon noch sehr rudimentär aus, so fehlt z.B. nach wie vor eine Sicherung der websrv_ssl_*.pem-Dateien in den exportierten Konfigurationsdaten. Damit würde immer noch bei jedem Rücksetzen der Box auf Werkseinstellungen auch ein neuer privater Schlüssel generiert und der Besitzer muß dann das Zertifikat der Box jedesmal erneut in seinem Browser als "vertrauenswürdig" installieren. Insofern sehe ich die Verbesserung durch die Möglichkeit des Download des intern generierten Zertifikats eher als gering an. Auch bisher konnte man bei der ersten Kontaktaufnahme mit dem Webserver der Box ja das Zertifikat dauerhaft freigeben.

Ich habe auch noch nicht herausfinden können, wie die Box zwischen einem selbst generierten und einem vom Benutzer hochgeladenen Zertifikat unterscheiden will, in den Einstellungsdateien habe ich keinen potentiellen Kandidaten dafür finden können. Allerdings hat ja auch noch kein Upload bei mir funktioniert ... die Einstellung könnte also noch kommen.
 
Hat jemand inzwischen ein eigenes SSL Zertifikat ans Laufen gebracht? Ich nach wie vor nicht... ;(
Beim Korrekturlesen der vorstehenden Antwort fiel mir dann auf, was ich noch nicht probiert hatte ... und nun kann ich sagen: Doch, es funktioniert.

Folgende Vorgehensweise führte dann zum Ziel, Abweichungen davon habe ich noch nicht getestet:

- Generieren eines "private key"
Code:
central:~ # openssl genrsa -aes128 -out box.key 2048 -passout stdin
Generating RSA private key, 2048 bit long modulus
....................................................................................................+++
....+++
e is 65537 (0x10001)
Enter pass phrase for box.key:
Verifying - Enter pass phrase for box.key:
central:~ #
Ich habe bisher nur mit einem verschlüsselten PrivKey getestet.

- Erstellen eines config-Files (openssl.fb) für das Signieren eines self-signed-Zertifikats, ansonsten kennt der CA-Verwalter die richtigen Einstellungen
Code:
[ req ]
prompt = no
default_bits = 2048
distinguished_name  = req_distinguished_name
x509_extensions = v3_ca
input_password = '[I]<password of private key>[/I]'
string_mask = nombstr
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true
subjectAltName=critical,[I]DNS:<dyndns host name>[,...][/I]
[ req_distinguished_name ]
CN = [I]dyndns host name[/I]
Die Liste der alternativen Namen kopiert man am besten aus dem von der Box selbst erzeugten Zertifikat.

- Zertifikat erzeugen
Code:
central:~ # openssl req -config openssl.fb -new -x509 -key box.key -out box.crt -days 365
central:~ #

- Zertifikat und Key in eine gemeinsame Datei packen
Code:
central:~ # cat box.crt box.key >box.pem

Die Datei "box.pem" läßt sich jetzt als Datei für den Upload verwenden.

Es gibt bloß ein Problem: Das Binary 'firmwarecfg', das für den Import der Datei verantwortlich ist, mag offenbar nur die folgenden Elemente im per POST übertragenen Formular:

1. die SID einer gültigen Sitzung als "sid"
2. das Kennwort für die Entschlüsselung des "private key" als "BoxCertPassword"
3. den Inhalt der o.a. Datei "box.pem" als "BoxCertImportFile"

Das derzeit vorliegende GUI packt aber noch diverse andere Elemente mit in den Request.

Man muß also auf anderem Wege (z.B. wget unter Linux oder Fiddler unter Windows) einen passenden Request mit "multipart/form-data" erzeugen.

Alle weiteren Test (z.B. zur Unterscheidung zwischen Upload/selbst generiert wie im vorherigen Beitrag beschrieben) habe ich noch nicht ausgeführt.
 
Hallo Peter,

vielen Dank für deine ausführlichen Informationen. Ich bin in der Hinsicht leider etwas leihenhafter aufgestellt.

Nur kurz zu meinem Umfeld:

ich habe ein Domain, sagen wir domain.de
für diese habe ich unterschiedliche Subdomains angelegt:

home.domain.de (entspricht Domainname auf den das Comodo Lite SSL Zertifikat ausgestellt ist (Kein Multidomain)
owa.domain.de --> Umleitung auf https://home.domain.de
fritz.domain.de --> Umleitung auf https://home.domain.de:499 (port der Fritte für Fernwartung
ecp.domain.de --> Umleitung auf https://home.domain.de/ecp/

Zertifikat wurde vom Exchange Server generiert (bzw. der CSR) und eben entsprechend ausgestellt für home.domain.de. Durch die Subdomains läuft alles über home.domain.de, was es ermöglicht eben ein einziges Zertifikat für alles zu nutzen.

Erhalten habe ich folgende Daten von Comodo:

- Linux (pem+cabundle)
- - cert.cabundle (containing PositiveSSL CA 2)
- - certificate.crt (containing your certificate)
- Plesk (Certificate+CACertificate)
- - cacertcertificate.crt (containing PositiveSSL CA 2)
- - certificate.crt (containing your certificate)
- Windows (pem)
- - intermediate1.crt (containing PositiveSSL CA 2)
- - certificate.crt (containing your certificate)
- Sonstige (pem)
- - root.crt (containing AddTrust External CA Root)
- - intermediate1.crt (containing PositiveSSL CA 2)
- - certificate.crt (containing your certificate)
- Sonstige (pkcs7)
- - certificate.cer (containing your certificate and intermediates)

Zusätzlich habe ich im IIS noch das ganze exportiert & mit Kennwort versehen (.pfx Datei). Die konnte ich auch problemlos auf dem DC importieren z.B.

Da ich auf der Fritte nur https von außen brauche, dachte ich, dass ich das Zertifikat dort importieren kann, und dann der Zertifikatfehler beim Aufruf von fritz.domain.de --> https://home.domain.de:499 nicht mehr erscheint. Sollte wirklich ein Multidomainzertifikat inkl. fritz.box usw. notwendig sein, ist es ja nicht machbar. Welcher Anbieter soll das verifizieren und wie?

Gruß
Smithy
 
Da ich auf der Fritte nur https von außen brauche, dachte ich, dass ich das Zertifikat dort importieren kann, und dann der Zertifikatfehler beim Aufruf von fritz.domain.de --> https://home.domain.de:499 nicht mehr erscheint.
Wenn das Zertifikat "home.domain.de" als CN oder als alternativen Subject-Name enthält, sollte der Fehler weg´sein, wenn ein ordentliches Redirect mit HTTP-Status 30x von "fritz.domain.de" auf "home.domain.de:499" erfolgt. Die HTTP-Umleitung ist aber bei vielen DynDNS-Anbietern unterschiedlich realisiert. Als Faustregel: Zeigt der Browser in der Adresszeile "https://home.domain.de:499" an, sollte bei richtigem Zertifikat keine Warnung erscheinen.

Sollte wirklich ein Multidomainzertifikat inkl. fritz.box usw. notwendig sein, ist es ja nicht machbar. Welcher Anbieter soll das verifizieren und wie?
Ich kann nicht sicher sagen, welche Namen die Box im Zertifikat zwingend erwartet. Da ich meine eigene kleine CA betreibe, konnte ich bisher immer passende Zertifikate generieren. Da mußt Du entweder bei AVM nachfragen oder einfach selbst probieren. Wenn das mit den Zertifikaten irgendwann mal Sinn machen soll, wird AVM sicherlich keinen CN "fritz.box" ernsthaft erwarten bei einem "offiziellen" Zertifikat. Insofern besteht da wohl Hoffnung ... :)

Wenn Du es selbst ausprobieren willst, mußt Du - meiner Meinung nach - systematisch ganz unten anfangen. Als erstes solltest Du feststellen, ob Dein privater Schlüssel eine Länge von 2048 Bit hat. Wenn schon das nicht der Fall ist, mußt Du erst einmal prüfen, welche Schlüssellängen die Box überhaupt akzeptiert. Am einfachsten arbeitest Du meine aufgelistetete Reihenfolge ab (wenn Du mit der allgemeinen Bemerkung zum Ansenden von "multipart/form-data"-POSTs nichts anfangen kannst, schreib mir eine PM, womit Du arbeiten könntest) und modifizierst pro Durchlauf immer nur eine Variable. Wenn Du dann am Schluß sicher bist, daß Dein Zertifikat die Rahmenbedingungen von AVM erfüllt, kannst Du Dich an die Umwandlung der pfx-Datei (ist normalerweise eine PKCS12-Datei im DER-Format, wenn ich richtig liege) in das geforderte Format machen. Dafür brauchst Du dann aber entsprechende Kenntnisse zum Umgang mit X509-Zertifikaten und am besten auch zum Umgang mit "openssl" auf der Kommandozeile. Das kann man sich alles an anderer Stelle anlesen ... ein "Kochbuch" für den Import eines Zertifikates in eine Fritz!Box wirst Du aber sicherlich - dafür ist die Funktion noch zu neu - nicht finden. Aber eines Tages wird AVM die Funktion sicherlich auch bewerben und muß sie dann dokumentieren ... wenn sie es sich nicht doch noch anders überlegen.

Ich bin von der bisher sichtbaren Umsetzung ohnehin nicht besonders begeistert, bei mir habe ich es etwas anders gelöst. Wer ist schon bereit, für ein Zertifikat für eine Fritz!Box (normalerweise habe kommerzielle Zertifikate ja auch eine sehr kurze Gültigkeitsdauer) die nicht gerade geringen Summen auszugeben, die Verisign & Co. fordern ?

Ich habe einfach von meiner CA (die ist ohnehin in allen meinen Geräten/Browsern - egal welches System - als vertrauenswürdig installiert) für jede Fritz!Box ein Zertifikat für eine Sub-CA ausgestellt, dieses Zertifikat samt Key in die Box übertragen und die Kommandos "/usr/bin/openssl_genrsa" und "/usr/bin/openssl_req" durch ein eigenes Skript (per Bind-Mount) ersetzt, welches das jeweils geforderte Fritz!Box-Zertifikat nicht als "self-signed" erzeugt, sondern es mit dem Zertifikat der installierten Sub-CA "unterschreibt". Somit stimmt dann am Schluß die "chain of trust" und ich muß nicht ständig neue Zertifikate als "vertrauenswürdig" akzeptieren. Der Sub-CA-Key wird dabei genau mit demselben Kennwort verschlüsselt, das die Box auch für ihren eigenen privaten Schlüssel verwendet. Sollte wirklich mal eine Box kompromittiert werden, ziehe ich einfach das Zertifikat für die Sub-CA zurück und damit verlieren dann alle von dieser Box erzeugten Zertifikate automatisch auch ihre Gültigkeit. Bloß mit der Möglichkeit der Sicherung/Wiederherstellung der Dateien in einer Box bin ich auch noch nicht zufrieden ...
 
Zuletzt bearbeitet:
Ich werde mich mal etwas weiter einlesen und auch erst mal AVM kontaktieren.

2048 Bit sind es auf alle Fälle, dass kann ich schon mal sagen. Ich habe auch immer auf certsrv auf dem Server zurück gegriffen bisher. Mich hat das installieren der Zertifikate, auf Handy, oder den verschiedenen Browsern und fremden Rechnern die Warnungen abzusegnen usw. tierisch genervt. Da ein Zertifikat für ein Apfel und ein Ei erhältlich ist, solange es nur einen Namen wie bei mir enthält, ist es mir die Sache wert (15€ im Jahr, die hab ich schnell verraucht. Mein Zertifikat ist bis 2019 gültig für 59€ und funktioniert auf allen bisher getesteten Geräten die mir unter die Finger gekommen sind egal wo, weltweit.)

Als Addresse wird korrekt home.domain.de:499 ausgegeben und korrekt umgeleitet, daher wäre es nur noch ein tüpfelchen auf dem I, wenn die Fritte es schlucken würde. Wenn es nicht geht - so oft muss ich auf die Fritte nicht drauf. ;) Wichtig ist mir mehr die Exchange Server Anbindung mit dem Zertifikat und die funktioniert bestens:)
 
daher wäre es nur noch ein tüpfelchen auf dem I, wenn die Fritte es schlucken würde. Wenn es nicht geht - so oft muss ich auf die Fritte nicht drauf. ;)
Na dann probiere es doch einfach mal ... bei den vielen Zertifikat-Dateien ist sicherlich auch eine im PEM-Format (beginnt mit "-----BEGIN CERTIFICATE-----" und enthält base64-kodiert das Zertifikat) dabei.

Zusätzlich brauchst Du noch Deinen privaten Schlüssel, den man aus der Zertifikatverwaltung von Windows aber eben nur im PKCS12-Format exportieren kann.

Nun brauchst Du OpenSSL (für Linux oder Windows, Dateinamen kannst Du sicherlich selbst anpassen) und das Kennwort, das Du beim Export der .pfx-Datei verwendet hast.
Code:
openssl pkcs12 -in [I]<deine-pfx-datei>[/I] -out [I]<neue-datei-mit-dem-key>[/I] -nocerts -nodes
Den Part aus der neuen Datei (Achtung, der private Schlüssel ist nun unverschlüsselt und sollte weder lange irgendwo als Datei herumliegen noch über unsichere Kanäle übertragen werden !) zwischen "-----BEGIN PRIVATE KEY-----" und "-----END PRIVATE KEY-----" (inkl. der Begrenzerzeilen) kopierst Du nun zusammen mit dem PEM-formatierten Zertifikat in eine gemeinsame Datei. Ich hatte das Zertifikat vor dem Key stehen.

Anschließend generierst Du (wie weiter oben schon beschrieben) einen HTTP-POST-Request mit einer gültigen SID, dieser Datei und leerem Kennwort (Dein PrivKey ist ja unverschlüsselt). Die Box sollte im HTTP-Body in etwa mit "Zertifikat erfolgreich importiert." antworten. Wenn das von Erfolg gekrönt ist, wissen wir auch gleich, daß der Import eines nicht verschlüsselten privaten Schlüssel funktioniert.
 
ich möchte ja nicht unhöflich erscheinen, aber versteht denn die Mehrheit der Mitleser die Posts ab #51 ? Die sind ja teilweise ellenlang, und hat das wirklich nur mit dieser Firmware zu tun? Bitte nicht falsch verstehen, aber mir ist das zumindest teilweise zu hoch.
 
ich möchte ja nicht unhöflich erscheinen, aber versteht denn die Mehrheit der Mitleser die Posts ab #51 ? Die sind ja teilweise ellenlang, und hat das wirklich nur mit dieser Firmware zu tun? Bitte nicht falsch verstehen, aber mir ist das zumindest teilweise zu hoch.
Sorry, aber völlig OT sind wir wohl nicht. Diese Firmware ist die erste, die das Einspielen eines eigenen Zertifikats für die Box erlaubt. Wenn das aber zu speziell ist, können die Admins ja die betreffenden Postings in einen anderen Thread verschieben. Ich hätte damit kein Problem, mache aber von mir aus kein neues Thema dazu auf.
 
Probleme in dieser Version, die mir aufgefallen sind:

  • WLAN "vergißt" immer die bereits angemeldeten Geräte, wenn diese einige Zeit lang abgeschaltet waren. Sie stehen zwar noch in der Liste der bekannten Geräte unter "Heimnetz" mit gültiger MAC, aber nicht mehr als WLAN-Geräte. Ich muß die Option unter "Sicherheit" - "Alle neuen WLAN-Geräte zulassen" immer aktiviert lassen und es erscheint beim erneuten Einschalten eines länger ausgeschalteten Geräts jedesmal die Meldung
    20.05.14 21:44:48 Neues WLAN-Gerät erstmalig angemeldet (5 GHz). Geschwindigkeit 433 Mbit/s. MAC-Adresse: yy:yy:yy:yy:yy:yy.
    20.05.14 21:43:58 Neues WLAN-Gerät erstmalig angemeldet (2,4 GHz). Geschwindigkeit 65 Mbit/s. MAC-Adresse: yy:yy:yy:yy:yy:yy.
    in den Systemlogs.
  • Ich kann keine neue VPN-Verbindung durch Import einer .cfg Datei mehr erzeugen (Option "Eine VPN-Konfiguration aus einer vorhandenen VPN-Einstellungsdatei importieren"). Es taucht lediglich ein einziger, nicht funktionsfähiger Eintrag in der Liste der VPN-Verbindungen auf. Importiere ich dieselbe .cfg Datei in meine alte 7270er Box, exportiere die Gesamt-Konfiguration der 7270 und importiere diese Datei in die 7490 (es reicht, die Haken bei "VPN" zu setzen), dann funktionieren die VPN-Verbindungen auch in der 7490
  • Auch bei mir kann man DECT-Geräte nicht richtig löschen. Befinden sich mindestens zwei DECT-Geräte in der Liste, dann scheint die Box beim Löschen hängen zu bleiben. Nach einem Zwangs-Reboot ist das gelöschte Gerät jedoch aus der Liste verschwunden. Wenn sich nur noch ein DECT-Gerät in der Liste befindet und man dieses löscht, erscheint die bereits weiter vorne aufgeführte Meldung mit "Fehlercode nil". Nach einem Neustart der Box ist die Liste dann leer.
  • Beim Telefonieren mit einem über VPN als VOIP-Nebenstelle angemeldeten Smartphone funktioniert nicht, es kommt auf beiden Seiten kein Ton.
 
Zuletzt bearbeitet:
@Peter - Danke - werde ich am Wochenende mal in Ruhe testen :)
 
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.