[Info] FRITZ!Box 6490 Cable FRITZ!OS 6.63 (28.10.2016)

[robert_s]

Es gibt ein neues FRITZ!OS für die retail-6490, welches u.a. die Probleme mit der Einrichtung der SIP-Telefonie und des nicht funktionierenden Dual Stack bei Vodafone Kabel Anschlüssen behebt.

Einen öffentlichen Download-Link gibt es nicht (man muss die Update-Funktion der Box nutzen, oder den Link anderweitig finden), aber wenigstens liegen Release Notes öffentlich auf dem AVM-Server:

http://ftp.avm.de/fritz.box/fritzbox_6490_cable/firmware/deutsch/info.txt

Neue Features:
- Optimierte Einstellungen zur Unterstützung der Telefonie am Netcologne-Kabelanschluss
- Unterstützung für IPv6 Dual-Stack an bestimmten Kabelanschlüssen
- Option zur Einrichtung einer weiteren Verbindung für VoIP-Telefonie

Verbesserungen in FRITZ!OS 6.63

Internet:
Behoben - Optimierter Ablauf im Ersteinrichtungsassistent

Telefonie:
Behoben - Bei aktiviertem DQoS keine Telefonie am Vodafone Kabelanschluss
Behoben - Einbindung eines neuen Telefonbuchs vom Anbieter Google nicht möglich

System:
Verbesserung - Stabilität
Behoben - Paketmitschnittseite nicht aufrufbar
Behoben - Sporadische Linkverluste bei Verwendung bestimmter LAN-Switches
Behoben - Sporadisch fehlender Neustart nach einem Firmware-Update

Speicher/NAS:
Behoben - Bei Erstellung einer Freigabe einer Datei im Online Speicher mit Fritz!NAS erscheint die Fehlermeldung „ungültige Pfadangabe“

Sicherheit:
Verbesserung - Diverse Sicherheitsoptimierungen

 

[KunterBunter]

Siehe auch hier.

 

[PeterPawn]

Die schlechte Nachricht ist ... der Paketmitschnitt startet in dieser Version dank existierendem Symlink zum notwendigen CGI-Programm tatsächlich, man sollte aber nicht darauf bauen, daß man die VLAN-Interfaces (l2sd0.2, l2sd0.99 und l2sd0.1000) tatsächlich gesondert ansprechen könnte, auch wenn die Interface-Liste etwas anderes suggeriert.

Startet man den Mitschnitt auf einem dieser VLAN-Interfaces, wird stattdessen eine Capture-Session für l2sd0 (also das "Basisinterface" der VLANs) gestartet und da die Buttons zum Stoppen nur an der Stelle freigeschaltet werden, für die bei der erneuten Abfrage eine aktive Capture-Session gemeldet wird, kann man den gestarteten Mitschnitt dann nicht mehr anhalten, denn der Versuch, die Sitzung für "l2sd0" zu stoppen, schlägt dann offenbar auch fehl (jedenfalls läuft das "capture_notimeout" auch munter weiter).

Nicht einmal über den "alle stoppen"-Button läßt sich dieses Dilemma wieder beheben. Also besser keines der Interfaces l2sd0.X benutzen - auf dem l2sd0 hat man dann eben allen Traffic der VLAN-Interfaces zusammen. Und da das Capture irgendwo an einer "komischen Stelle" erfolgt, hat man noch den Effekt in den mitgeschnittenen Daten, daß Pakete zur FRITZ!Box (also "incoming") mit VLAN-Tag aufgezeichnet werden, während das Tag in den Antworten der FRITZ!Box (noch?) fehlt.

Über diese VLANs wird offensichtlich der Traffic auf dem internen Switch "auseinander" gehalten, für das "LAN" wird VLAN-ID 2 verwendet und für das Gastnetz die 99. Was sich hinter VLAN-ID 1000 nun wirklich verbirgt, muß man mal in einer etwas stärker ausgelasteten Umgebung untersuchen ... bei mir (LAN1-Mode) gab/gibt es nicht ein Paket mit VLAN-ID 1000 auf l2sd0 zu sehen.

Die Idee, die Kommunikation irgendeines Clients mit dem x86-Core und den dort laufenden Daemons mitzuschneiden, kann man (zumindest bei dieser Version) auch gleich wieder beerdigen ... da das Capture auf dem NP-Core läuft, sind da keine Pakete des APP-Core zu sehen. Ein WLAN-Mitschnitt geht bei der 6490 in dieser Form ja ohnehin nicht, weil das WLAN ja auch auf dem APP-Core arbeitet - hier gibt es also gar kein Interface auf dem NP, was dieser in der Liste im GUI anzeigen könnte.

 

[robert_s]

Ein WLAN-Mitschnitt geht bei der 6490 in dieser Form ja ohnehin nicht, weil das WLAN ja auch auf dem APP-Core arbeitet

Könnte diesem Umstand auch der Bug geschuldet sein, dass man die 6490 als UPNP Gateway Device nur über WLAN findet und nicht über LAN? Ich habe mir den Wolf nach dem Fehler in gupnp/gssdp gesucht, bis ich feststellte, dass der "Referenz" Windows-Laptop die Fritz!Box auch nur fand solange er über WLAN kommunizierte und im LAN ebenso erfolglos war.

In Wireshark kann man schön sehen, dass die 6490 auf den "M-SEARCH" SSDP-Multicast über WLAN sofort antwortet, über LAN dagegen gar nicht. Über LAN taucht nur selten mal ein SSDP-Announcement von der 6490 auf, und dann findet gupnp/gssdp sie auch - dauert aber ewig.

Besteht überhaupt eine Chance, dass AVM das gefixt bekommt...?

 

[PeterPawn]

So richtig 100% ist das für mich auch nicht ersichtlich, wie da nun genau der Paketfluß vom und zum WLAN läuft. Ich hätte eigentlich erwartet, daß der APP selbst das Bridgen zwischen dem WLAN und dem LAN übernimmt:

# cat /proc/net/vlan/config
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.2         | 2  | eth0
eth0.99        | 99  | eth0
eth0.1000      | 1000  | eth0
# brctl show
bridge name     bridge id               STP enabled     interfaces
lan             8000.c80e14dead94       no              eth0.2
                                                        ath0
                                                        ath1
guest           8000.c80e14dead94       no              eth0.99
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: acc0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether c8:0e:14:de:ad:af brd ff:ff:ff:ff:ff:ff
4: lan: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
    link/ether c8:0e:14:de:ad:94 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.254/24 brd 192.168.178.255 scope global lan
    inet 169.254.1.2/16 brd 169.254.255.255 scope global lan:0
    inet6 fd00::ca0e:14ff:fede:ad94/64 scope global dynamic
       valid_lft 6848sec preferred_lft 3248sec
    inet6 fe80::ca0e:14ff:fede:ad94/64 scope link
       valid_lft forever preferred_lft forever
5: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue master lan
    link/ether c8:0e:14:de:ad:af brd ff:ff:ff:ff:ff:ff
6: guest: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
    link/ether c8:0e:14:de:ad:94 brd ff:ff:ff:ff:ff:ff
7: eth0.99@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue master guest
    link/ether c8:0e:14:de:ad:af brd ff:ff:ff:ff:ff:ff
8: eth0.1000@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether c8:0e:14:de:ad:af brd ff:ff:ff:ff:ff:ff
9: wifi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 511
    link/ieee802.11 c8:0e:14:de:ad:95 brd ff:ff:ff:ff:ff:ff
10: wifi1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 511
    link/ieee802.11 c8:0e:14:de:ad:96 brd ff:ff:ff:ff:ff:ff
11: ath0: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue master lan
    link/ether c8:0e:14:de:ad:95 brd ff:ff:ff:ff:ff:ff
12: ath1: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue master lan
    link/ether c8:0e:14:de:ad:96 brd ff:ff:ff:ff:ff:ff
# rpc brctl show
bridge name     bridge id               STP enabled     interfaces
guest           8000.c80e14dead93       no              l2sd0.99
lan             8000.c80e14dead93       no              l2sd0.2
# rpc ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: acc0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: tunl0: <NOARP> mtu 1480 qdisc noop
    link/ipip 0.0.0.0 brd 0.0.0.0
4: l2sd0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether c8:ff:00:00:a0:01 brd ff:ff:ff:ff:ff:ff
5: adsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 2000 qdisc pfifo_fast qlen 32
    link/[19]
6: l2sd0.2@l2sd0: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue master lan
    link/ether c8:ff:00:00:a0:01 brd ff:ff:ff:ff:ff:ff
7: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP100> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:f1:80:00:00 brd ff:ff:ff:ff:ff:ff
8: lbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc tbf qlen 1000
    link/ether 00:50:f1:00:00:00 brd ff:ff:ff:ff:ff:ff
9: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP100> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether c8:0e:14:de:ad:92 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global lan0
10: wan0: <BROADCAST,MULTICAST100> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether c8:0e:14:de:ad:90 brd ff:ff:ff:ff:ff:ff
11: l2sd0.99@l2sd0: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue master guest
    link/ether c8:ff:00:00:a0:01 brd ff:ff:ff:ff:ff:ff
12: l2sd0.1000@l2sd0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether c8:ff:00:00:a0:01 brd ff:ff:ff:ff:ff:ff
13: lan: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
    link/ether c8:0e:14:de:ad:93 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.1/24 brd 192.168.178.255 scope global lan
    inet 169.254.1.1/16 brd 169.254.255.255 scope global lan:0
    inet6 fd00::ca0e:14ff:fede:ad93/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ca0e:14ff:fede:ad93/64 scope link
       valid_lft forever preferred_lft forever
14: guest: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
    link/ether c8:0e:14:de:ad:93 brd ff:ff:ff:ff:ff:ff
    inet 192.168.179.1/24 brd 192.168.179.255 scope global guest
    inet6 fd00::1:ca0e:14ff:fede:ad93/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ca0e:14ff:fede:ad93/64 scope link
       valid_lft forever preferred_lft forever
15: dsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen 100
    link/ppp
    inet 192.168.178.1/32 scope global dsl
    inet6 fe80::ca0e:14ff:fede:ad93/64 scope link
       valid_lft forever preferred_lft forever
16: erouter0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether c8:0e:14:de:ad:93 brd ff:ff:ff:ff:ff:ff
17: esafe0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

Da werden ja die WiFi-Interfaces und das eth0.2 zusammengebunden in der "lan"-Bridge - allerdings kommen die SSDP-NOTIFY-Pakete ja auch von beiden Cores (IGD2 vom ARM, MediaServer und L2TPv3-Endpoint vom x86) - jeweils mit der eigenen IP- und MAC-Adresse.

Wie das jetzt mit Paketen ist, die vom ARM-Core direkt ins LAN sollen (da sollten dann ja keine Tags mehr drin sein ab den Ethernet-PHYs, die LAN-Interfaces arbeiten ja auch bei der 6490 ohne VLANs), weiß ich auch nicht so richtig ... ich habe auch noch keine Möglichkeit gefunden, auf dem ATOM-Core in den (internen) Netzwerkverkehr zu schauen und dem, was die Box auf dem ARM-Core im Capture liefert, sieht man nicht an, an welches Interface das Paket am Ende geht, wenn es im ARM-Core erzeugt wurde.

Da das ja Multicast-Pakete sind beim SSDP, kann ich mir nicht vorstellen, daß die von beiden Cores je einmal ins LAN gepumpt werden (bei einer Bridge auf beiden Seiten würde ich das erwarten) - sieht auch nicht so aus, wenn man auf einem Host im LAN mitschneidet. Wie das nun genau laufen soll beim "Ausleiten" der internen Kommunikation an irgendeinen Switch-Port oder eines der WLAN-Interfaces, habe ich auch noch nicht sicher erkennen können (auch nicht in den Kernel-Sources).

Andererseits macht es ja irgendwie auch keinen Sinn, wenn ein MC-Paket erst vom ARM zum ATOM geht, damit es dann weiter ins LAN seinen Weg findet - das paßt auch nicht so richtig dazu, daß der ARM-Core das primäre Gateway ist - da steht ja auch die MAC des ARM-Cores in den Paketen im LAN, wenn sie von dort kommen.

Also muß es ja irgendeine Form der Entscheidung geben, auf welchen Interfaces so ein Paket nun auf die Reise gehen soll und nachdem es erst einmal nicht für jeden physikalischen Port ein Interface gibt (bei der 7490 werden da ja eth0 bis eth3 einzeln erzeugt), muß es ja irgendeine Möglichkeit der Konfiguration des internen Switches geben. Einige Dateien (z.B. /etc/l2switch.conf und /nvram/3/lsddb.ini) geben so einer Vermutung weitere Nahrung, aber die genauen Zusammenhänge kenne ich auch noch nicht. Wenn das VPN bei der 6490 auch das Verwenden eines "ipsecbrX"-Interfaces kennen sollte (ein weiterer offener Punkt für Tests), dann sieht man vielleicht mehr, wenn man mal einen dieser Ports als "einzeln" konfiguriert.

Ich hätte tatsächlich vermutet (weil es für Repeater ja ohnehin vorhanden ist), daß da ein L2TPv3-Tunnel zwischen dem ARM- und dem x86-Core etabliert wird (der ARM als Server) und der ATOM-Core mit dem WLAN damit als eine Art integrierter AP für den ARM-Core arbeitet - das ist ja ziemlich erprobte Technik bei AVM. Aber wie gesagt ... bis ich zu einem ausführlichen Test des WLANs jemals kommen werde, gibt es noch genug andere spannende Stellen mit Potential für "Entdeckungen".

 

[PeterPawn]

Kenne ich, läuft jetzt aber anders.

Es gibt auch in den 7490-Quellen ein Beispiel-Programm zur Konfiguration des Switches (in drivers/net/avm_cpmac/switch/ifx/7port/ifxmips_switch_api - nennt sich "switch_utility"), dort fehlt aber das notwendige Device für die IOCTL-Aufrufe in AVM-Firmware (der Driver sollte "switch_api" heißen) und das müßte man erst einmal anlegen (major 81, s. /proc/devices), bevor man sich vielleicht mit einem übersetzten Utility an den Switch-Einstellungen vergreifen kann.

Bei der 7580 (bei der 7560 ist es mir schon wieder entfallen) sollte das passende Programm aber tatsächlich im System enthalten sein (unter /usr/bin/switch_cli), wobei ich nicht weiß, ob dort auch das notwendige Device existiert - über reines Ansehen bin ich da noch nicht hinaus.

 

[PeterPawn]

@opto:
Weiß ich tatsächlich nicht ... aber die Konfigurationsdatei für den Switch im ARM-Teil sieht irgendwie nicht danach aus. Ein System wird sicherlich den Hut aufhaben bei der Konfiguration des Switches und in einer lsddb.ini steht auch ein "APP"-Port neben den vier LAN-Anschlüssen:

# cat /nvram/3/lsddb.ini

[switchport.app0]
# normal
group   = 1
active  = 1
basedevice      = l2sd0
PredefinedVlanId        = 2
lifecycle       = permanent

[switchport.ext1]
# normal
group   = 1
active  = 1
basedevice      = l2sd0
PredefinedVlanId        = 2

[switchport.ext2]
# normal
group   = 1
active  = 1
basedevice      = l2sd0
PredefinedVlanId        = 2

[switchport.ext3]
# normal
group   = 1
active  = 1
basedevice      = l2sd0
PredefinedVlanId        = 2

[switchport.ext4]
# guest
group   = 3
active  = 1
basedevice      = l2sd0
PredefinedVlanId        = 4

Wenn das "app0" tatsächlich der APP-Core im CEFDK ist, dann könnte das sein.

Wobei da ohnehin so einiges im Argen liegt bei der 6490, wie ich gerade konstatieren konnte.

Ich habe eine Box mit dieser Firmware-Version auf die Werkseinstellungen zurückgesetzt, den Einrichtungsassistenten brav abgearbeitet (aber keine BK-Verbindung vorhanden) und dann als einzige den LAN4-Port zum Gastzugang erklärt. In der Realität würde da jetzt z.B. ein WLAN-AP dran hängen (etwas weiter weg, deshalb Ethernet-Kabel). Jetzt sollte man ja eigentlich erwarten dürfen, daß der per Ethernet-Kabel an diesem LAN4 angeschlossene Laptop eine IP-Adresse aus dem Gastnetz (192.168.179.0/24) per DHCP erhält und das klappt auch problemlos ... in den "Netzwerkverbindungen" wird der Laptop jetzt mit dem Koffer als "Reisender" dargestellt.

Ansonsten hängt der Rest des Netzes hinter einem Switch, der an LAN3 steckt.

So weit, so gut ... ich würde jetzt eigentlich erwarten, daß an LAN4 kein Traffic aus dem Netz hinter dem Switch an LAN3 auftaucht, aber das ist absolut nicht so. Multicast- und Broadcast-Pakete (MDNS, SSDP, ARP, MSBROWSER, usw.) von diesen Geräten tauchen praktisch unablässig im Gastnetz auf und von dort ist auch das Ermitteln der IP-Adresse des LAN-Interfaces für das normale Netz möglich, denn auf ein "ping 192.168.178.1" aus dem Gastnetz antwortet die FRITZ!Box. Damit ist das Ermitteln der tatsächlich verwendeten Adressen (der erste Schritt, wenn ich jemanden angreifen will - ich muß erst einmal ermitteln, wo der eigentlich ist) reine Fleißarbeit - mal vollkommen abgesehen davon, daß die Auswertung von mDNS-Messages natürlich auch eine wahre Fundgrube sein kann.

Ich weiß nicht, wie AVM dazu steht ... aber für mich ist das keine Isolation des Gastnetzes, wenn dort ein Client quasi die Topographie des normalen LAN in aller Ruhe "mithören" kann. Es macht auch gar keinen Sinn, solche Broadcasts oder Multicasts aus dem normalen LAN ins Gastnetz weiterzureichen, denn nach der Theorie soll ja ein Gerät aus dem Gastnetz ohnehin kein Chance für eine eigene Antwort haben - mal sehen, ob das tatsächlich stimmt, auch wenn man da mit eigenen Broadcasts antwortet ... nicht daß die dann auch noch irgendwo in einem anderen Netz (außer dem Gast-WLAN) landen.

 

[Pokemon20021]

ergänzend die Revision-Number zur 06.63:

http://fritz.box/jason_boxinfo.xml

<j:BoxInfo>
  <j:Name>FRITZ!Box 6490 Cable</j:Name>
  <j:HW>213</j:HW><j:Version>141.06.63</j:Version>
  [COLOR=#0000FF]<j:Revision>34787</j:Revision>[/COLOR]
SNIP