[Info] Wichtig: Was vor dem Update der FRITZ!Box 6490 auf die 06.83 beachtet werden sollte !

all0hacker

Neuer User
Mitglied seit
3 Okt 2016
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Ich will hiermit alle Nutzer der FRITZ!Box 6490 warnen die in betracht ziehen ihre Box auf die 06.83 zu Updaten welche den Bridge Mode nutzen.
Denn seit dem Update funktionieren die hier unten aufgeführten Features bei mir nicht mehr :(.
  1. Bridge Mode (Egal welchen Anschluss man im GUI auswählt man bekommt keine IP mehr und um dem nachzugehen bräuchte man einen Paketmitschnitt )
  2. Paketmitschnitt (Man wird einfach auf die Übersicht Seite der FRITZ!Box weitergeleitet)
Kennt jemand so ein Verhalten bzw. hat ähnliche Erfahrungen?
Ich freue mich schon aufs Feedback.
Mfg Jannis
 
Beim fehlenden Paketmitschnitt ist lediglich wieder mal die "menu_data.lua" die Ursache ... das sieht nicht einmal so aus, als wollte AVM den Mitschnitt bei der Retail-Version tatsächlich wieder sperren (dafür sind die Abfragen in der "capture.lua" dann weiterhin zu ausführlich), da hat vermutlich nur wieder jemand mit einer "nicht Release"-Version getestet und dann funktioniert der Mitschnitt sogar:
Code:
["cap"] = (not config.is_cable or (config.is_cable and 'release' ~= config.gu_type)) and {
Wer also den Mitschnitt unbedingt braucht, muß dann eben die o.g. Zeile in der "menu_data.lua" irgendwie anpassen - wenn man jetzt AVM wäre, könnte man sich Gedanken um die korrekte Formulierung einer Bedingung machen, aber als "Anwender" wirft man einfach die Bedingung komplett raus (von der ersten öffnenden Klammer bis einschließlich "and") und gut ist's.

Mich nervt da eher, daß die Box in der Übersichtsseite zwar für die Geräte mit einem Service auf Port 80 einen Link anzeigt, der verweist aber praktischerweise auf die FRITZ!Box selbst (.1) und nicht auf das Gerät. Keine Ahnung, ob das bei anderen auch so ist, bei mir betrifft es das interne Gateway und mehr "sieht" die 6490 von meinem Netz nicht, so daß ich nicht einschätzen kann, ob das beim NAS z.B. auch so wäre.
 
  1. Bridge Mode (Egal welchen Anschluss man im GUI auswählt man bekommt keine IP mehr und um dem nachzugehen bräuchte man einen Paketmitschnitt )

Oh interessant, allerdings denke ich eher das hier endlich der Bug gefixt wurde und MaxCPE nach DOCSIS Spezifikation ausgewertet wird.
Außer es handelt sich bei dir um einen Vertrag mit 2 IPs, ich gehe mal davon aus das du eine 2. öffentliche IP meinst.
 
Mich nervt da eher, daß die Box in der Übersichtsseite zwar für die Geräte mit einem Service auf Port 80 einen Link anzeigt, der verweist aber praktischerweise auf die FRITZ!Box selbst (.1) und nicht auf das Gerät. Keine Ahnung, ob das bei anderen auch so ist, bei mir betrifft es das interne Gateway und mehr "sieht" die 6490 von meinem Netz nicht, so daß ich nicht einschätzen kann, ob das beim NAS z.B. auch so wäre.
Du meinst in der "Heimnetzübersicht"? Da habe ich bei meiner 6590 solche Links:

http://<IP-Adresse der Fritz!Box>/secure_link.lua?sid=<Hex-String>&lnk=http://<IP-Adresse des Geräts>

Und ein Klick auf den Link (mit Firefox 53.0.2) bringt mich auch auf das Gerät.

Woran hakt es denn bei Dir? Fehlt der /secure_link.lua* Teil, antwortet die Fritz!Box auf den Link nicht richtig, oder spielt vielleicht Dein Browser nicht mit...?

- - - Aktualisiert - - -

Oh interessant, allerdings denke ich eher das hier endlich der Bug gefixt wurde und MaxCPE nach DOCSIS Spezifikation ausgewertet wird.
Was meinst Du damit? Ich finde in der von Vodafone Kabel eingespielten Config:

Tag 18 (1 bytes): 02
 
Tag 18 (1 bytes): 02

Kann jetzt nicht schauen ob dies das passende Feld ist.
Hmm wenn das der richtige Wert ist wäre das ungewöhnlich, da ich davon ausgehe das du keine Mietbox mit einem separaten Telefonie Interface hast und in diesem Fall die Vergabe einer 2. IP sogar völlig ok wäre.
Wüsste allerdings nicht warum man MaxCPE bei einer Retail Box auf 2 stellen sollte.

Es war nur bis zu mindestens zur 6.63 möglich eine 2. IP möglich trotz Wert 1. Werde das mal mit der 6.83 testen.
 
@robert_s:
Ja, ich habe hier ein zentrales Gateway, was den Traffic auf FRITZ!Boxen verteilt und seinerseits NAT in Richtung dieser Boxen macht, so daß die nur dieses Gateway kennen. Das hat die Adresse 192.168.xxx.2, während die FRITZ!Box die .1 hat. Ein im GUI erzeugter Link arbeitet "ganz normal" mit der "secure_link.lua" und enthält auch die SID genauso wie den "lnk"-Parameter ... nur steht eben am Ende der dort angegebenen URL nicht die ".2", wie es korrekt wäre, sondern ".1", was wieder die FRITZ!Box ist.

Dabei sieht auch der Eintrag in "landevices" nicht ungewöhnlich aus:
Code:
landevices {
        landevices_version = 3;
        landevices {
                ip = 192.168.xxx.2;
                manual_ip = no;
                uniqid = 8904;
                name = "central";
                neighbour_name = "";
                mac = 00:01:2E:DE:AD:BF;
                auto_etherwake = no;
                ifaceid = ::;
                staticlease = no;
                ipv4_exposed_host = no;
                allow_pcp_and_upnp = no;
        }
}
und ich wüßte jetzt nicht, woher die Box ansonsten eine (falsch gespeicherte) IP-Adresse des Gerätes nehmen sollte, wenn nicht von dort. Wenn die Angabe aus der "laufenden Konfiguration" stammt, ist das noch weniger erklärlich.


-Ich habe bisher auch weder Zeit noch Lust gehabt, das Problem zu suchen und event. selbst zu fixen (ich habe mir halt "abgewöhnt", den Link zu nutzen - aber den Paketmitschnitt (s.o.) habe ich tatsächlich direkt wieder aktiviert) - ich hatte eben auch ein paar Probleme beim (Hin- und Her-)Wechseln zwischen 06.83 und 06.63, wenn es um das Aktivieren des eRouters ging.

Zwar kriegte das eCM sauber seine Konfiguration und seine (IPv6-)Adresse für die Provisionierung und auch sein config-File, aber der ATOM-Core wollte - nach dem Wechsel zur 06.63 und auch danach auf der 06.83, bis ich eine Konfigurationssicherung wiederhergestellt hatte - keine IPv4- und/oder IPv6-Adresse kriegen, offenbar war da der DHCP-Proxy im eCM etwas "verschnupft" über irgendeine Einstellung.

Worin sich die Konfigurationsdateien jetzt genau unterschieden, habe ich - mangels Zeit - auch noch nicht untersucht. Aber es ist zumindest in den "dmesg"-Ausgaben der 06.83 auch anhand einiger Nachrichten zu sehen, daß AVM da wohl beim "Übersetzen" der alten Konfiguration einiges an Code investiert hat und das erklärt ggf. auch einen zeitlichen Unterschied zwischen der 06.83 bei der 6590 und bei der 6490, denn bei ersterer gab es ja keine Notwendigkeit für solche Anpassungen.

Zum Wert von "MaxCPE" bei meiner VF-Konfiguration kann ich noch nichts sagen ... es ist gar nicht mehr so ohne weiteres möglich, Dateien (hier halt das config-File) zwischen den beiden Systemen auszutauschen. Es gibt wohl Ansätze, da eine weitere Partition im eMMC-Device (mit dem Namen "update_tmp") zumindest bei Firmware-Updates (bei künftigen?) zu verwenden ... wobei man dafür vielleicht erst mal eine "/var/install" für die nächste Version sehen müßte, um die Zusammenhänge wirklich einschätzen zu können.

Bisher sieht man nur die "/etc/init.d/E15-filesystem-update" und das dort Enthaltene kann noch alles mögliche bedeuten - dort werden jedenfalls diese "no-scratch"-Partitionen gemountet und der Kommentar mit einer "cross_cpu_ramdisk" ließ mich zuerst an eine solche Verbindung der beiden System glauben, aber zumindest vom ARM zum ATOM ist da nach dem Kopieren keine Datei zu sehen. Ob das noch irgendeine Synchronisation braucht oder etwas ähnliches, muß ich erst noch suchen.

Jedenfalls muß ich durch diesen fehlenden Dateiaustausch (auch NFS ist ja raus) erst mal schauen, wie ich die Konfigurationsdatei aus dem ARM-Core an eine Stelle kriege, wo ich sie als Datei exportieren und dann auseinandernehmen kann. Ich habe erst gestern damit begonnen, die 06.83 jenseits rein theoretischer Analyse auch mal in der Praxis zu beobachten. Vielleicht kommen die guten alten Zeiten von "zmodem" bald wieder ... dann geht so ein Dateiaustausch auch über die "armconsole".

Auf alle Fälle bin ich etwas erstaunt, warum @fesc weiterhin irgendwelche Daten (in erster Linie sicherlich SSH-Keys) in "/nvram" speichern will (steht irgendwo in einem anderen Thread). Den Schreibzugriff dorthin hat der ARM-Core (das ist schließlich auch der originale Intel-Code, der da zuständig ist) und neben den Schwierigkeiten beim lesenden Zugriff (den man ggf. durch r/o-Mounten im ATOM realisieren könnte, wobei ich da mit der Endianess beim JFFS2 auch sehr, sehr vorsichtig wäre) kommt dann noch das Problem hinzu, den ARM-Core zum Schreiben zu veranlassen. Da ist es m.E. (nunmehr, zuvor sah das anders aus) sinnvoller, die eMMC-Partitionen (sprich: "/var/media/ftp/irgendwas" und eine Verschlüsselung der gespeicherten Daten gegen allzu einfache NAS-Zugriffe) zu benutzen.

In der ARM-Partition ist wirklich nur noch der Intel-Code und ein paar Kleinigkeiten von AVM zur Kommunikation (pumaglued und ein paar "showirgendwas"-Kommandos) enthalten ... insofern ist das als Abschottung schon recht gut gelungen in meinen Augen. Ob "armconsole" wirklich nötig ist - oder auch "rpc", was es immer noch gibt als Kommando -, kann ich noch nicht wirklich einschätzen ... ohne diese Zutaten wäre aber der ARM-Core wohl tatsächlich nur noch über den "pumaglued" und mit definierten Abfragen/Kommandos zu erreichen (da muß dann "shell start" sicherlich auch nicht unbedingt dazugehören) und damit vor dem Benutzer des ATOM-Cores sicher. Solange es aber diese Programme noch gibt, bleibt da m.E. auch noch eine Lücke offen - daher nur das "recht gut" und kein "wirklich".

Wobei man auch mal sehen und anerkennen muß, daß sich dahinter tatsächlich ein Riesenberg an Arbeit verbergen dürfte, die Architektur komplett umzukrempeln. Man könnte sich zwar jetzt fragen, warum AVM das nicht gleich so gemacht hat bei der Einführung des Puma6 (dann wäre schon die 6490 ein Renner gewesen), aber da kann man sicherlich auch darauf spekulieren, daß mal wieder das Controlling und der Kostendruck das Sagen hatten und man durch das "Weiterwursteln" mit der vom Puma5 übernommenen ARM-Plattform auch für die eigenen Komponenten am Beginn sicherlich etwas Zeit sparen konnte. Damit unterschied sich dann halt die 6490 (wieder mal bis auf das WLAN) nicht so fürchterlich von der 6360, als sie auf den Markt kam - die DVB-C-Funktionen gab es ja "offiziell" gar nicht.

Hier hat AVM in meinen Augen dann einen "Quantensprung" bereits zu diesem Zeitpunkt versäumt und wenn man sich die ganzen anderen Probleme ansieht, die sich aus der Puma6-Architektur im Laufe der Zeit ergeben haben, beißt man sich bei AVM vermutlich heute selbst ins Hinterteil, denn in der Summe würde ich darauf wetten, daß der Aufwand insgesamt (Anpassen der alten Architektur an die zwei Kerne und dann noch einmal alles umwerfen) höher ausfiel, als wenn man es gleich "richtig" gemacht hätte (und die Intel-"Vorgabe" sieht ja auch den ATOM-Teil als "APP-Core" vor, was andere Hersteller (Arris, Hitron) auch prompt so übernommen haben).

- - - Aktualisiert - - -

Ach Quatsch, einen Weg habe ich oben unterschlagen, aber der ist etwas schwieriger zu automatisieren ... der Dateiaustausch geht natürlich problemlos über den FTP-Server (interne Adressen verwenden und einen Benutzer aus dem FRITZ!OS), wenn man auf dem ARM-Core die BusyBox-Applets "ftpput" und "ftpget" verwendet - es ist nur über "rpc" nicht ohne weiteres möglich, sich zuvor in das richtige Verzeichnis zu "beamen" und die Syntax der Applets ist i.V.m. kompletten Pfaden etwas unhandlich, wenn man mit "REMOTE_FILE" und "LOCAL_FILE" arbeiten will.

- - - Aktualisiert - - -

config-File für eine 6490 bei VF/KDG mit einem 100/6-Anschluß (an "meinem" CMTS, das kann in anderen Segmenten anders aussehen) - dekodiert mit dem Excentis-Editor:
Code:
Network Access Control:on
Privacy Enable:on
Subscriber Management Filter Groups:CMupstream 10, CMdownstream 0, SUBupstream 15, SUBdownstream 0, PSupstream 15, PSdownstream 0, MTAupstream 27, MTAdownstream 0, STBupstream 15, STBdownstream 0
SNMP MIB Object(docsDevFilterIpDefault.0):1.3.6.1.2.1.69.1.6.3.0, Integer, 2
SNMP MIB Object(docsDevFilterIpStatus.1):1.3.6.1.2.1.69.1.6.4.1.2.1, Integer, 4
SNMP MIB Object(docsDevFilterIpControl.1):1.3.6.1.2.1.69.1.6.4.1.3.1, Integer, 1
SNMP MIB Object(docsDevFilterIpIfIndex.1):1.3.6.1.2.1.69.1.6.4.1.4.1, Integer, 0
SNMP MIB Object(docsDevFilterIpDirection.1):1.3.6.1.2.1.69.1.6.4.1.5.1, Integer, 3
SNMP MIB Object(docsDevFilterIpBroadcast.1):1.3.6.1.2.1.69.1.6.4.1.6.1, Integer, 2
SNMP MIB Object(docsDevFilterIpSaddr.1):1.3.6.1.2.1.69.1.6.4.1.7.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpSmask.1):1.3.6.1.2.1.69.1.6.4.1.8.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDaddr.1):1.3.6.1.2.1.69.1.6.4.1.9.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDmask.1):1.3.6.1.2.1.69.1.6.4.1.10.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpProtocol.1):1.3.6.1.2.1.69.1.6.4.1.11.1, Integer, 6
SNMP MIB Object(docsDevFilterIpDestPortLow.1):1.3.6.1.2.1.69.1.6.4.1.14.1, Integer, 137
SNMP MIB Object(docsDevFilterIpDestPortHigh.1):1.3.6.1.2.1.69.1.6.4.1.15.1, Integer, 139
SNMP MIB Object(docsDevFilterIpStatus.2):1.3.6.1.2.1.69.1.6.4.1.2.2, Integer, 4
SNMP MIB Object(docsDevFilterIpControl.2):1.3.6.1.2.1.69.1.6.4.1.3.2, Integer, 1
SNMP MIB Object(docsDevFilterIpIfIndex.2):1.3.6.1.2.1.69.1.6.4.1.4.2, Integer, 0
SNMP MIB Object(docsDevFilterIpDirection.2):1.3.6.1.2.1.69.1.6.4.1.5.2, Integer, 3
SNMP MIB Object(docsDevFilterIpBroadcast.2):1.3.6.1.2.1.69.1.6.4.1.6.2, Integer, 2
SNMP MIB Object(docsDevFilterIpSaddr.2):1.3.6.1.2.1.69.1.6.4.1.7.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpSmask.2):1.3.6.1.2.1.69.1.6.4.1.8.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDaddr.2):1.3.6.1.2.1.69.1.6.4.1.9.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDmask.2):1.3.6.1.2.1.69.1.6.4.1.10.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpProtocol.2):1.3.6.1.2.1.69.1.6.4.1.11.2, Integer, 17
SNMP MIB Object(docsDevFilterIpDestPortLow.2):1.3.6.1.2.1.69.1.6.4.1.14.2, Integer, 137
SNMP MIB Object(docsDevFilterIpDestPortHigh.2):1.3.6.1.2.1.69.1.6.4.1.15.2, Integer, 139
SNMP MIB Object(docsDevFilterIpStatus.3):1.3.6.1.2.1.69.1.6.4.1.2.3, Integer, 4
SNMP MIB Object(docsDevFilterIpControl.3):1.3.6.1.2.1.69.1.6.4.1.3.3, Integer, 1
SNMP MIB Object(docsDevFilterIpIfIndex.3):1.3.6.1.2.1.69.1.6.4.1.4.3, Integer, 0
SNMP MIB Object(docsDevFilterIpDirection.3):1.3.6.1.2.1.69.1.6.4.1.5.3, Integer, 3
SNMP MIB Object(docsDevFilterIpBroadcast.3):1.3.6.1.2.1.69.1.6.4.1.6.3, Integer, 2
SNMP MIB Object(docsDevFilterIpSaddr.3):1.3.6.1.2.1.69.1.6.4.1.7.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpSmask.3):1.3.6.1.2.1.69.1.6.4.1.8.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDaddr.3):1.3.6.1.2.1.69.1.6.4.1.9.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDmask.3):1.3.6.1.2.1.69.1.6.4.1.10.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpProtocol.3):1.3.6.1.2.1.69.1.6.4.1.11.3, Integer, 6
SNMP MIB Object(docsDevFilterIpDestPortLow.3):1.3.6.1.2.1.69.1.6.4.1.14.3, Integer, 135
SNMP MIB Object(docsDevFilterIpDestPortHigh.3):1.3.6.1.2.1.69.1.6.4.1.15.3, Integer, 135
Baseline Privacy Configuration Settings
  Authorize Wait Timeout:10
  Reauthorize Wait Timeout:10
  Authorization Grace Time:600
  Operational Wait Timeout:1
  Rekey Wait Timeout:1
  TEK Grace Time:600
  Authorize Reject Wait Timeout:60
  SA Map Wait Timeout:1
  SA Map Max Retries:4
[COLOR="#FF0000"][B]Maximum Number of CPEs:2[/B][/COLOR]
Euro-DOCSIS Extension Field
  Cable Modem Attribute Masks
    CM Upstream Required Attribute Mask:00000030
Upstream Service Flow Encodings
  Service Flow Reference:1
  Quality of Service Parameter Set:provisioned admitted active
  Traffic Priority:0
  Upstream Maximum Sustained Traffic Rate:6360000
  Maximum Traffic Burst:28000
  Maximum Concatenated Burst:28000
  Service Flow Scheduling Type:Best Effort
  IP Type of Service Overwrite:and-mask 0x00 or-mask 0x00
Upstream Service Flow Encodings
  Service Flow Reference:12
  Quality of Service Parameter Set:provisioned admitted active
  Traffic Priority:4
  Service Flow Scheduling Type:Best Effort
  IP Type of Service Overwrite:and-mask 0x68 or-mask 0x68
Downstream Service Flow Encodings
  Service Flow Reference:2
  Quality of Service Parameter Set:provisioned admitted active
  Traffic Priority:0
  Downstream Maximum Sustained Traffic Rate:106000000
  IP Type of Service Overwrite:and-mask 0x00 or-mask 0x00
Downstream Service Flow Encodings
  Service Flow Reference:4
  Quality of Service Parameter Set:provisioned admitted active
  Traffic Priority:4
  Service Flow Forbidden Attribute Mask:80000000
Upstream Packet Classification Encoding
  Classifier Reference:201
  Service Flow Reference:12
  Classifier Activation State:on
  Ethernet LLC Packet Classification Encodings
    Ethertype/DSAP/MacType:type 0x03 eprot1 0x0F eprot2 0x16
Upstream Packet Classification Encoding
  Classifier Reference:205
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Destination Address:88.134.209.0
    IP Destination Mask:255.255.255.0
    TCP/UDP Destination Port Start:5060
    TCP/UDP Destination Port End:5060
Upstream Packet Classification Encoding
  Classifier Reference:208
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Type of Service Range and Mask:tos-low 0x50 tos-high 0x50 tos-mask 0xFF
    IP Protocol:17
    IP Destination Address:88.134.209.0
    IP Destination Mask:255.255.255.0
Upstream Packet Classification Encoding
  Classifier Reference:210
  Service Flow Reference:12
  Classifier Activation State:on
  Ethernet LLC Packet Classification Encodings
    Ethertype/DSAP/MacType:type 0x03 eprot1 0x25 eprot2 0x2B
Upstream Packet Classification Encoding
  Classifier Reference:212
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Source Address:10.0.0.0
    IP Source Mask:255.0.0.0
    TCP/UDP Destination Port Start:67
    TCP/UDP Destination Port End:67
Upstream Packet Classification Encoding
  Classifier Reference:219
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    TCP/UDP Destination Port Start:53
    TCP/UDP Destination Port End:53
  IPv6 Packet Classification Encodings
    IPv6 Next Header Type:17
    IPv6 Source Address:2a02:8101:1000:0:0:0:0:0
    IPv6 Source Prefix Length:36
    IPv6 Destination Address:2a02:8100:0:0:0:0:0:0
    IPv6 Destination Prefix Length:32
Upstream Packet Classification Encoding
  Classifier Reference:222
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    TCP/UDP Destination Port Start:547
    TCP/UDP Destination Port End:547
  IPv6 Packet Classification Encodings
    IPv6 Next Header Type:17
    IPv6 Source Address:2a02:8101:1000:0:0:0:0:0
    IPv6 Source Prefix Length:36
    IPv6 Destination Address:2a02:8100:0:0:0:0:0:0
    IPv6 Destination Prefix Length:32
Downstream Packet Classification Encoding
  Classifier Reference:103
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Destination Address:10.0.0.0
    IP Destination Mask:255.0.0.0
    TCP/UDP Destination Port Start:161
    TCP/UDP Destination Port End:161
Downstream Packet Classification Encoding
  Classifier Reference:104
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Source Address:88.134.209.0
    IP Source Mask:255.255.255.0
    TCP/UDP Source Port Start:5060
    TCP/UDP Source Port End:5060
Downstream Packet Classification Encoding
  Classifier Reference:107
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Destination Address:10.0.0.0
    IP Destination Mask:255.0.0.0
    TCP/UDP Source Port Start:67
    TCP/UDP Source Port End:67
Downstream Packet Classification Encoding
  Classifier Reference:114
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    TCP/UDP Source Port Start:53
    TCP/UDP Source Port End:53
  IPv6 Packet Classification Encodings
    IPv6 Next Header Type:17
    IPv6 Source Address:2a02:8100:0:0:0:0:0:0
    IPv6 Source Prefix Length:32
    IPv6 Destination Address:2a02:8101:1000:0:0:0:0:0
    IPv6 Destination Prefix Length:36
Downstream Packet Classification Encoding
  Classifier Reference:117
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    TCP/UDP Source Port Start:547
    TCP/UDP Source Port End:547
  IPv6 Packet Classification Encodings
    IPv6 Next Header Type:17
    IPv6 Source Address:2a02:8100:0:0:0:0:0:0
    IPv6 Source Prefix Length:32
    IPv6 Destination Address:2a02:8101:1000:0:0:0:0:0
    IPv6 Destination Prefix Length:36
Mal in "voller Schönheit", weil man dann auch die DOCSIS-QoS-Settings sehen kann, die wir in irgendeinem anderen Thread auch schon beim Wickel hatten.
 
  • Like
Reaktionen: FunkReich
Ok dann liegt der Fehler bei Vodafone und verstehe nciht wirklich wieso sie dies machen, da ich auch hier davon ausgehe das es keine Mietbox ist.
Interessant das überhaupt soviel gesetzt wird auch bei den Classifiern.
 
Ich gehe davon aus, daß bei VF/KDG nicht zwischen Kundenbox und Provider-Gerät unterschieden wird bei der Konfiguration ... auch die QoS-Regeln für die 10/8-Adressen sind ja bei der Kundenbox witzlos, da diese Adressen bei VF/KDG nur verwendet werden, wenn das eMTA vom KNB provisioniert wird.
 
Jedenfalls muß ich durch diesen fehlenden Dateiaustausch (auch NFS ist ja raus) erst mal schauen, wie ich die Konfigurationsdatei aus dem ARM-Core an eine Stelle kriege, wo ich sie als Datei exportieren und dann auseinandernehmen kann. Ich habe erst gestern damit begonnen, die 06.83 jenseits rein theoretischer Analyse auch mal in der Praxis zu beobachten. Vielleicht kommen die guten alten Zeiten von "zmodem" bald wieder ... dann geht so ein Dateiaustausch auch über die "armconsole".

Auf alle Fälle bin ich etwas erstaunt, warum @fesc weiterhin irgendwelche Daten (in erster Linie sicherlich SSH-Keys) in "/nvram" speichern will (steht irgendwo in einem anderen Thread). Den Schreibzugriff dorthin hat der ARM-Core (das ist schließlich auch der originale Intel-Code, der da zuständig ist) und neben den Schwierigkeiten beim lesenden Zugriff (den man ggf. durch r/o-Mounten im ATOM realisieren könnte, wobei ich da mit der Endianess beim JFFS2 auch sehr, sehr vorsichtig wäre) kommt dann noch das Problem hinzu, den ARM-Core zum Schreiben zu veranlassen. Da ist es m.E. (nunmehr, zuvor sah das anders aus) sinnvoller, die eMMC-Partitionen (sprich: "/var/media/ftp/irgendwas" und eine Verschlüsselung der gespeicherten Daten gegen allzu einfache NAS-Zugriffe) zu benutzen.

Für den Datenaustausch auf 6.83 habe ich mir ein kleines tool geschrieben welches auf rpc aufsetzt (/usr/local/bin/rpc_cp). Damit holt sich der Atom beim booten einmalig alles key-material, bzw. ein sync tool kann es zurückschreiben. Das läuft soweit gut (ist auf einem release15 branch).
Warum nicht auf der eMMC:
- Etwas verschlüsseltes auf der eMMC habe ich auch schon im Sinn, aber der key zum entschlüsseln muss ja auch irgendwo liegen (und nicht gerade auf der eMMC). Also gewinne ich nix.
- Ich hatte schon den Fall dass mir die box das eMMC gelöscht hat (durch unbeabsichtigtes schalten in einen Produktionsmodus). Da war ich froh dass die Daten in /nvram lagen.
- /nvram kann man zur Not auch über eva wiederherstellen (was andererseits natürlich wieder eine Sicherheitslücke ist ...).
 
Ist damit alles unterhalb von /nvram/* gemeint?

Also zB auch /nvram/1/security ? Falls durch Werkseinstellugen bei FW unter 6.5x dieser Bereich gelöscht wurde ?
 
Was meinst du mit "damit"? Wenn die Daten gelöscht sind brauchst du eh ein Backup von /nvram. Falls das in Form eines JFFS2 images der /nvram partition vorliegt könnte man das direkt per ftp in eva einspielen (falls das damit gemeint war).
 
Hätte vll. noch ein drittes mal lesen und darüber nachdenken sollen, vorm Tippen.

Aber davon abgesehen

Unter /nvram liegt doch auch NAS, oder ?

Einzelne Files lassen sich aber nicht schreiben ?(wenn du von einem nvram image schreibst)
 
@fesc:
Eine Möglichkeit für ein direkt aus der Firmware gewonnenes Kennwort (anhand von Environment-Einstellungen) gibt es ja bereits: https://github.com/PeterPawn/privatekeypassword - der private Schlüssel für das Box-Zertifikat wird von AVM auch mit diesem Kennwort geschützt. Auch für das Absichern von kompletten TAR-Files über diesen Wert hätte ich schon seit längerem eine Lösung im Angebot: https://github.com/PeterPawn/YourFritz/tree/master/signimage - dort kann man auch das Box-Zertifikat verwenden zum Signieren und damit sicher sein, daß die Datei tatsächlich auf dem oder für das Zielsystem erstellt wurde.

Allerdings braucht natürlich Verschlüsseln und Signieren ein passendes OpenSSL (was man aber m.E. auch für so ziemlich jeden anderen produktiven Einsatz einer FRITZ!Box ergänzen muß) - dann kann man damit aber sowohl den Inhalt solcher Dateien verschlüsseln als auch die Integrität eines Backups (hier würden dann Backup-Datei und Datenspeicherung auf genau demselben Weg erfolgen) überprüfen und diese Daten praktisch problemlos sichern (auch wenn sich Einstellungen mal häufiger ändern als es bei öffentlichen SSH-Keys der Fall ist) und - auch im Falle des Löschens durch die Firmware - ohne Kopfstände wiederherstellen.

Wobei bei SSH ja auf der Box eher die öffentlichen Schlüssel der berechtigten Benutzer landen werden als eigene private Schlüssel - den für den SSH-Server kann man auch wieder aus dem AVM-Zertifikat samt Key nehmen (so RSA-1024 einem reicht), wenn man einen für die Box braucht oder man erzeugt sich halt einen "besseren" und verschlüsselt den beim Speichern - und diese öffentlichen Schlüssel brauchen keine zusätzliche Verschlüsselung, sondern nur die Überprüfung der Authentizität.

Backup/Restore geht zwar theoretisch auch mit einem JFFS2-Image (irgendwo bei den "eva_tools" gibt es auch ein Skript, um ein Image einer JFFS2-Partition aus der Box zu extrahieren - für Forensik bei AB-Daten (zum Wiederherstellen vorher gesicherter Daten) auch bei anderen Boxen als der 6490 zu gebrauchen und dafür auch ursprünglich mal gemacht), aber da ist für den durchschnittlichen Benutzer dann schlechter an das Backup heranzukommen. Da bringt der Punkt "über EVA wiederherstellen" dann in meinen Augen weniger Vorteile als der NAS-Zugriff beim Wiederherstellen so einer gesicherten Datei im eMMC.

Theoretisch ist es zwar egal, ob man nun ein OpenSSL (und ohne das kommt man dann doch nicht aus) und "privatekeypassword" für die Box übersetzen muß oder Dein Tool zum Datenaustausch mit dem ARM-Core ... aber angesichts der AVM-Bemühungen zur Isolation des ARM-Cores ist es m.E. besser, wenn man das nicht "unterlaufen" will und sich bei den für die Öffentlichkeit bereitgestellten Modifikationen auf solche beschränkt (zumindest bei der "new architecture"), die auf dem ATOM-Core ablaufen können. Wenn AVM irgendwann dazu übergehen sollte, das ARM-FS kryptographisch abzusichern (ich würde das zugegebenermaßen machen, weil sich bei dieser Architektur der ARM-Teil deutlich seltener ändern müßte als der ATOM-Teil und nach der DOCSIS-Spec hat eben der Besitzer ohnehin auf dem eCM nichts verloren), dann sind auch keine Zusätze zum ARM-FS mehr (zumindest nicht so einfach, wie das derzeit der Fall ist) möglich ... und ich würde sogar sagen, daß sie auch nicht nötig sind. Der ATOM-Core ist obendrein auch noch deutlich schneller - nicht zuletzt deshalb läuft ja wohl auch bei Dir der SSH-Server auf diesem System und nicht direkt auf dem ARM-Kern - und damit machen dem die paar Operationen beim Ver- und Entschlüsseln von Konfigurationsdaten auch nichts aus.

Beim Sicherheitsaspekt sehe ich gar keinen echten Unterschied zwischen einer kryptographisch gesicherten Speicherung im eMMC und einer (ansonsten unverschlüsselten) im JFFS2 unter "/nvram". Wenn ich Zugriff auf die Daten im Environment habe, kann ich den Box-Schlüssel genauso berechnen, wie ich das JFFS2-Image mit eigenen Daten überschreiben kann. Ich sehe allerdings noch einen weiteren Vorteil für die Besitzer der älteren Boxen (wo die neuen Zertifikate dort lagern), wenn man seltener auf "/nvram" zugreift (erst recht, wenn es um Schreibzugriffe geht) und da, wo man mit einem Restore des JFFS2 ggf. neue Zertifikate vernichtet oder - wenn man sein eigenes Backup davon macht - CM-Zertifikat und -Key per se erst einmal unverschlüsselt irgendwo herumzuliegen hat (es sei denn, man verschlüsselt das noch einmal selbst), da wäre das bei einem (obendrein noch verschlüsselten) Backup im eMMC eben nicht der Fall ... zumindest nicht für CM-Cert und -Key, weil die da gar nicht enthalten sein müßten - anders als beim JFFS2-Image, wo man keine dateiweise Wiederherstellung über EVA machen kann.
 
Zuletzt bearbeitet:
@stoney0815: Nein, /nvram ist eine 640K grosse partition im SPI flash. NAS liegt auf einer eMMC. Und nein, eva koennte nur die gesamte partition schreiben (mtd5 wenn ich mich nicht irre).
 
config-File für eine 6490 bei VF/KDG mit einem 100/6-Anschluß (an "meinem" CMTS, das kann in anderen Segmenten anders aussehen) - dekodiert mit dem Excentis-Editor:
Danke für den Tip mit dem Editor, das config-File für meine 6590 bei VFKD mit 200/12 unterscheidet sich praktisch nur an den zu erwartenden Stellen:
Code:
-  Upstream Maximum Sustained Traffic Rate:6360000
-  Maximum Traffic Burst:28000
-  Maximum Concatenated Burst:28000
+  Upstream Maximum Sustained Traffic Rate:12700000
+  Maximum Traffic Burst:65535
+  Maximum Concatenated Burst:65535

-  Downstream Maximum Sustained Traffic Rate:106000000
+  Downstream Maximum Sustained Traffic Rate:212000000
 
@fesc:
Eine Möglichkeit für ein direkt aus der Firmware gewonnenes Kennwort (anhand von Environment-Einstellungen) gibt es ja bereits: https://github.com/PeterPawn/privatekeypassword - der private Schlüssel für das Box-Zertifikat wird von AVM auch mit diesem Kennwort geschützt. Auch für das Absichern von kompletten TAR-Files über diesen Wert hätte ich schon seit längerem eine Lösung im Angebot: https://github.com/PeterPawn/YourFritz/tree/master/signimage - dort kann man auch das Box-Zertifikat verwenden zum Signieren und damit sicher sein, daß die Datei tatsächlich auf dem oder für das Zielsystem erstellt wurde.

Allerdings braucht natürlich Verschlüsseln und Signieren ein passendes OpenSSL (was man aber m.E. auch für so ziemlich jeden anderen produktiven Einsatz einer FRITZ!Box ergänzen muß) - dann kann man damit aber sowohl den Inhalt solcher Dateien verschlüsseln als auch die Integrität eines Backups (hier würden dann Backup-Datei und Datenspeicherung auf genau demselben Weg erfolgen) überprüfen und diese Daten praktisch problemlos sichern (auch wenn sich Einstellungen mal häufiger ändern als es bei öffentlichen SSH-Keys der Fall ist) und - auch im Falle des Löschens durch die Firmware - ohne Kopfstände wiederherstellen.
Danke fuer den Hinweis, bin ich am einbauen, privatekeypassword und openssl laufen bereits. Hat auch den Vorteil dass Atom auf die key/cert Daten im tffs direkt zugreifen kann.
Waere mal interessant zu wissen was AVM mit den letsencrypt nodes machen will (sind ja noch leer, irgendwo hattest du schon mal spekuliert, glaube ich).
 
@fesc:
Ich weiß gerade nicht genau, welchen SSH-Server Du verwendest ... für eine ältere "dropbear"-Version gab/gibt es bereits Patches (in meinem Freetz-Fork, in den offiziellen Trunk haben sie es damals - als sie noch funktionierten - nicht geschafft und im Moment bringt das gerade auch nichts), damit der sich auch automatisch aus dem privaten Schlüssel der Box seinen eigenen Host-Key zieht. Allerdings passen die gerade nicht auf die aktuelle Version, weil da an der Konfiguration vom "dropbear"-Autoren viele Änderungen vorgenommen wurden und ich die Korrekturen meiner Patches noch nicht eingecheckt habe (mal sehen, vielleicht komme ich heute nachmittag dazu).

Für OpenSSH ist/wäre es auch nicht weiter kompliziert, direkt den PEM-kodierten privaten Schlüssel zu verwenden - nur für den Fall, daß Du Interesse daran hast, den ohnehin vorhandenen privaten Schlüssel einer FRITZ!Box (in aktuellen Versionen wäre das ein 2048-Bit-RSA-Key) für einen SSH-Host zu verwenden.

Allerdings ist ED-25519 halt auch schneller (macht beim ATOM-Core sicherlich nicht so viel aus, wie bei den diversen MIPS-Boxen - genau gemessen habe ich da aber nicht), das bräuchte dann die sichere Speicherung des Keys für den Host auf der Box, weil AVM das bisher nicht kann und auf einem RSA-Schlüssel beharrt. Mit einem 4096-Bit-RSA-Key (mein eigener Key+Zertifikat) braucht ein "dropbear" auf einer 7490 (VR9) schon mal 8 Sekunden für den Verbindungsaufbau - da lohnt sich dann das "connection sharing" richtig, weil nachfolgende SSH-Requests dann wesentlich flotter arbeiten, solange die Verbindung besteht.
 
@PeterPawn: Dropbear v2016.74.
Ich habe /var/flash/websrv_ssl_key.pem entschluesselt und mittels dbconvert im tmpfs abgelegt. Das funktioniert und reicht mir erst mal, auch sicherheitstechnisch. Mein Ziel ist einzig das niemand mit Zugriff auf /var/media/ftp Unfug anrichten kann. Wenn sich jemand einloggen kann ist eh alles zu spaet. Aber ich schau mir den patch mal an.
Darauf aufbauend die restlichen features (signiertes image, OpenVPN TLS daten, verschluesseltes image fuer .ssh etc.).
 
Paketmitschnitt (Man wird einfach auf die Übersicht Seite der FRITZ!Box weitergeleitet)
Kennt jemand so ein Verhalten bzw. hat ähnliche Erfahrungen?
Hallo, das Problem konnte ich sowohl bei der FB6590 als auch bei der FB6490 nachvollziehen, und habe es an AVM gemeldet.
Intern soll der Fehler dort bereits behoben sein, und mit dem nächsten Firmware Update ausgerollt. Wenn man von den Problemen
bei bestimmten Unitymedia Anschlüssen in Verbindung mit Fritz!OS 6.83 hört, wird es bis dahin hoffentlich nicht mehr lange dauern.
 
für das capture also immer noch auf eine neue Version warten oder gibt es einen Trick, wie man das sonst aufrufen kann?
 

Statistik des Forums

Themen
246,045
Beiträge
2,244,985
Mitglieder
373,451
Neuestes Mitglied
Ayzham
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.