[Info] FRITZ!Box 6490 Firmware 141.06.62 von 23.08.2016

Wotan-Box · 25 Aug 2016

Verbesserungen in FRITZ!OS 6.62

Internet:

Verbesserung - Einrichtungsassistent für den Internetzugang

Telefonie:

Verbesserung - Anbieterauswahl für Telefonie-Anbieter überarbeitet
Verbesserung - mehrere Kabelanbieter als Internettelefonie-Anbieter hinzugefügt
Behoben - Internetrufnummern ließen sich vereinzelt nicht bearbeiten

System:

Verbesserung - Stabilität

simpel · 25 Aug 2016

GSM-Telefonie über Huawei E173 geht auch mit dieser Firmware nicht. Schade !!!

Jowi · 27 Aug 2016

Hallo,

wir haben in der letzten Woche bei meinem Schwager eine freie Fritz!Box 6490 Cable in Betrieb genommen. Er hatte vorher eine Fritz!Box 6320 von UM mit anhängender Fritz!Box 7390 für das WLAN und die Telefonie. Die beiden alten Boxen haben wir nun eingemottet. Die Einrichtung verlief soweit Problemlos und wir haben alles manuell neu konfiguriert. In dieser Woche viel meinem Schwager auf das sein Medienserver von einer Synology DS109 auf einigen Clients im Hause nicht mehr angezeigt wird. Es handelt sich hierbei um TV´s von Samsung und LG die per WLAN an der 6490 angebunden sind. Wir haben dann die DS109 und auch die 6490 stromlos gemacht und neu gestartet. Danach war der Medienserver auf den Clients für ca. 15 Minuten sicht- und auswählbar. Wir haben mehrfach Videostreams angestartet die auch Problemlos anliefen. Kurze zeit später verschwand der Medienserver aber wieder in der Auswahl auf den Clients.!!! Ein neustarten der Fritz!Box oder der DS109 machen den Medienserver auf den Clients wieder für kurze Zeit sichtbar. Nach ca. einer viertel Stunde verschwindet dieser aber wieder in der Übersicht. Vorher mit den alten Fritzboxen lief alles ohne Probleme. Es wurde auch sonst nicht geändert, kein Update vom NAS oder so. Wir haben nur die beiden alten Fritten gegen die 6490 getauscht.

Hat von Euch vielleicht jemand einen Medienserver an einer 6490 hängen und kann ähnliches berichten?

Ich hatte vor längerer Zeit mal ein solches Problem mit meiner 7490. Da verschwand immer der Medienserver von Raumfeld und Synology im Wechsel auf meinen Clients. Nach einem Reboot der 7490 waren die Server wieder für eine bestimmte Zeit auf den Clients sichbar. Das hat sich dann aber nach mehreren FW Updates der 7490 und Feedback an AVM in Luft aufgelöst.

Ansonsten werde ich die 6490 in der nächsten Woche noch mal in den Auslieferungszustand versetzen und komplett neu einrichten.

Viele Grüße

Joachim

PeterPawn · 28 Aug 2016

Eine gute Nachricht für die Leute, die auf der Suche nach der "capture.lua" bei der 6490 waren und sind ... bei der 06.62 hat AVM die mehrfach zitierte Abfrage nunmehr auf

Code:

--- 141.06.61/usr/www/avm/capture.lua   2016-07-26 17:58:51.000000000 +0200
+++ 141.06.62/usr/www/avm/capture.lua   2016-08-23 16:30:27.000000000 +0200
@@ -8,7 +8,7 @@
 g_page_title = [[{?946:222?}]]
 ------------------------------------------------------------------------------------------------------------>
 dofile("../templates/global_lua.lua")
-if config.DOCSIS and config.gu_type == 'release' then
+if config.DOCSIS and config.gu_type == 'release' [COLOR="#FF0000"]and config.oem ~= "avm"[/COLOR] then
 http.redirect("")
 end
 if box.get.xhr and box.get.wlantrace

geändert ... damit ist dann bei Branding "avm" der Paketmitschnitt auch wieder "freigegeben". Alle Spekulationen, daß dieser "unerwünscht" sein könnte, sind damit obsolet - es war also wohl doch nur ein Versehen, wenn es bisher fehlte. Das ist nunmehr auch nicht nur eine versehentliche oder falsche Änderung (das hätte bei drei AND-Verknüpfungen ja auch vorkommen können), die korrespondierenden Stellen in der "menu_data.lua" und der "support.lua" wurden ebenfalls geändert.

Damit fehlt in der Liste der Änderungen in #1 also noch die Feststellung, daß der Paketmitschnitt nunmehr bei der 6490 auch möglich ist - was mich persönlich zwar verblüfft, aber AVM wird sich ja etwas dabei gedacht haben (das ist keine zufällige Änderung).

Damit kann man dann endlich auch auf Spekulationen verzichten, wie so eine Provisionierung im Kabelnetz abläuft ... wer sich wirklich dafür interessiert, sollte das eigentlich auf dem "DOCSIS Management"-Interface mitschneiden können (wenn meine Interpretation des "DOCSIS Management" nicht falsch ist, leider habe ich genau für dieses Interface keinen alten Mitschnitt aus 2015 mehr). Damit der Mitschnitt auch rechtzeitig beginnt (das GUI steht ja erst später zur Verfügung), kann man ja auch das Kabel für das eCM erst später verbinden.

Die Interfaces unterscheiden sich ja deutlich von denen anderer Boxen, hier kann zur Einordnung dann ein Blick in die eDOCSIS-Spezifikation nicht schaden (S. 11, Bild 5-1 und S. 21, Bild 5-16).

So weit ich weiß (und das ist nicht allzu weit), verbirgt sich hinter den Namen dann folgendes (ich kann die Box aber im Moment nicht am Kabelanschluß betreiben, mangels Vertrag):

acc0	keine Ahnung
tunl0	ein Interface für Linux-IP-Tunnel, habe ich bisher auch noch nicht aktiv erlebt entweder es kommt bei L2TPv3 für Repeater zum Einsatz oder eben bei einem Tunnel zum Provider für die "Homespot"-Geschichte (oder wie auch immer das bei UM heißen mag) ist die erste Vermutung richtig, wird man bei aktivem Repeater hier etwas sehen (nur, wenn der "LAN-Bridge" ist, das WLAN kommt aus einem anderen Interface) den Tunnel zum Provider gibt es m.W. in den Retail-Boxen nicht, auch wenn sicherlich jedem schon mal der leere Eintrag "hotspotcfg" in einer exportierten Datei (in der ar7.cfg) aufgefallen ist
l2sd0*	anders als in den DSL-Modelle heißen hier die Schnittstellen des Switches in der Box nicht "ethX", sondern l2sd0.X m.E. (das ist jetzt ungetestet) ist der Uplink bei LAN1-Modus dann l2sd0.1000 und das Gastnetz, sofern es über WLAN "ankommt", die l2sd0.99 - das kommt hier vom ATOM-Core, weil der das WLAN verwaltet das Gastnetz, wenn es über das LAN-Kabel geht, l2sd0.4 die "allgemeine" l2sd0-Schnittstelle ist dann nach meinen Begriffe die Zusammenfassung aller l2sd0-Interfaces
cni0	das müßte die "netzseitige" Schnittstelle des eCM sein (cable network interface), ob das nun die MAC-Bridge (in den Bilder 5-3 ff. bei den einzelnen eSAFE-Modellen das, was links steht und in Bild 5-1 das rechte Interface des mittleren "Kastens" bei den eCM-Interfaces) oder das linke im mittleren Kasten in Bild 5-1 ist, weiß ich auch nicht, spielt für die meisten wahrscheinlich ohnehin keine Rolle noch weiter "nach links" in die Richtung des RF-Interfaces dürfte es nicht gehen, das sollte "in Hardware" laufen und nicht für das CM bestimmte Pakete sollten es auch nicht bis zu dieser Schnittstelle schaffen wobei es wohl eher die linke Schnittstelle in 5-1 ist, denn die rechte ist (nach meinem Verständnis) eher "lbr0"
lbr0	das müßte die "clientseitige" Schnittstelle des eCM sein (local bridge), im Prinzip das gesamte CMCI, was aus so einem CM "rauskommen" darf bzw. soll
lan0	das ist das LAN-seitige Diagnose-Interface mit der IP-Adresse 192.168.100.1, siehe OSSI-Spezifikation, Punkt 9.1
wan0	hier bin ich mir ziemlich unsicher ... von meiner alten 6490 kenne ich dieses Interface (aus den Supportdaten) als eines, wo der netzseitige Zugriff auf den SNMP-Stack möglich war praktisch das netzseitige Pendant zum lan0, wobei da m.W. mehr Kontrolle machbar war/ist, als von lan0 aus ... siehe wieder die OSSI-Spec, wer da was steuern darf und was nicht
lan/guest	die normalen "Bridges", wie man sie auch aus den DSL-Boxen kennt praktisch das netzseitige Pendant zum lan0, wobei da m.W. mehr Kontrolle machbar war/ist, als von lan0 aus ... siehe wieder die OSSI-Spec, wer da was steuern darf und was nicht
erouter0	das (wohl einzige) "embedded Service/Application Functional Entities"-Interface, was in einer Retail-Box implementiert ist, m.E. ist das für die Telefonie kein eMTA im Sinne der DOCSIS-Spezifikation, anders als bei den Provider-Boxen
esafe0	das ist in meiner Vorstellung die "Zusammenfassung" sämtlichen eSAFE-Verkehrs, was wohl dann auch wieder eine 1:1-Kopie des erouter0 ergeben könnte in einer Retail-Box
WLAN	hier ergibt sich bei der 6490 wohl das Problem, daß die WLAN-Implementierung seit einigen Versionen auf dem ATOM-Core läuft und damit auf dem ARM-Core (wo die anderen Interfaces alle liegen, auf dem ATOM-Core heißen die Schnittstellen dann auch wieder wie gewohnt "ethX" und man sieht schon an deren Fehlen, daß es eben nur ARM-Interfaces in der Liste gibt) nichts mitgeschnitten werden kann ... selbst wenn am Ende irgendein l2sd0.irgendwas-Interface vielleicht den resultierenden Traffic bieten könnte, das ganze Management, was man bei den anderen Boxen auch noch mitschneiden kann im WLAN, das fehlt hier
DOCSIS management	das ist in meinen Augen dann auch das interessanteste Interface, wenn man sich für DOCSIS-Spezialitäten interessiert, denn hier müßten sich (wenn ich das nicht vollkommen falsch interpretiere) auch die ganzen "pre-registration"-Pakete wiederfinden (und wieder kann ich nicht wirklich nachsehen bzw. hier will ich es nicht, weil ich die Box nicht mit eingeschaltetem eCM an den Kabelanschluß hängen will - bei mir ist auf diesem Interface jedenfalls absolute Ruhe im LAN1-Modus) vielleicht macht ja mal jemand mit einer 6490 (mit aktivem eCM) an einem BK-Anschluß und der 06.62 in der Box einen Mitschnitt auf diesem Interface ... bei der Interpretation bin ich gerne behilflich

Das bitte alles mit einer gehörigen Portion Skepsis lesen ... es ist bei einer Box im LAN1-Modus nicht ohne weiteres möglich, die Daten auf den ganzen eDOCSIS-Schnittstellen mitzuschneiden und zu interpretieren - einfach weil diese ohne aktiven CM-Modus fast alle gar nicht aktiviert werden. Einiges ist also auch nur Rückschluß aus meiner alten 6490 mit 06.10 aus dem Frühjahr 2015 - wobei sich Schnittstellennamen und Inhalte sicherlich nicht so grundlegend ändern - und ein paar älteren Mitschnitten aus dieser Box, als ich noch bei KDG Kunde mit einem Internet-Anschluß war.

Sollte jemand Fehler finden, korrigiere ich diese gerne ...

Ob das interne Interface (das hat sicherlich jeder auch schon in seinen Support-Daten gesehen, es ist das mit der 169.254.1.1 und die kann man - anders als bei den DSL-Modellen und auch da geht das im Prinzip seit einiger Zeit nicht mehr komplikationslos - hier auch nicht guten Gewissens ändern) auch irgendwo in einem Mitschnitt auftaucht, habe ich noch nicht probiert, in den Support-Daten steht es als "lan:0" (nicht mit "lan0" verwechseln). Schaut man dann bei der ar7.cfg (in den Export-Daten) einer 6490 vorbei, sieht man dort zwar das Interface "lan:0" auf beiden Cores (der ATOM-Core kriegt seine IP-Konfiguration aus "br2interfaces") und es steht dort in trauter Eintracht mit den lokalen Bridges (lan und guest), aber intern ist es wohl doch anders geregelt, denn bei den "richtigen" Bridges taucht es dann wieder nicht mehr auf.

Ich kann auch nur dringend davon abraten, an den Adressen dieser LAN-Interfaces (also lan:0 auf beiden Kernen) irgendwie "herumzuspielen" ... deren Adressen werden intern noch oft genug verwendet und zwar genau in der Form 169.254.1.1 und .2 - wer hier also experimentieren will, sollte sich lange vorher einen Plan zurechtlegen, wie er im Falle eines Problems seine Box wieder so weit gestartet bekommt, daß er so eine Änderung dann rückgängig machen kann; das ist nicht so einfach, wie das auf den ersten Blick wirken mag, solange es kein Recovery-Programm gibt.

Ähnliches gilt auch für die Konfiguration des LAN-Segments auf die IP-Adresse 192.168.100.1/24 ... wegen des möglichen Konfliktes mit der 192.168.100.1 aus der OSSI-Spezifikation würde ich das ebenfalls nur probieren, wenn ich einen Plan hätte, wie ich im Notfall wieder zurück komme ... sollte der "ctlmgr" aus irgendeinem Grund nicht starten wollen oder abstürzen, wenn die "lan"-Bridge nicht richtig konfiguriert werden kann (falls das lan0-Interface seine Adresse zuerst erhält, was ich nicht einschätzen kann), dann könnte auch der Zugriff auf das Wiederherstellen von Einstellungen oder sogar auf "Werkseinstellungen" zum Problem werden.

PeterPawn · 29 Aug 2016

Da ich die Box die ganze Zeit schon im LAN1-Modus betreibe, kann ich nichts dazu sagen, ob der NetBIOS-Filter abschaltbar ist oder nicht ... wenn ich das richtig verstanden hatte, war das bei Dir doch ohnehin von der Provisionierung durch den Provider beeinflußt?

Ich selbst bin auch alles andere als "böse" darüber, wenn der tatsächlich ständig aktiviert ist ... die denkbaren Einsatzfälle für den Versand von NetBIOS-Paketen über die WAN-Verbindung (die Box arbeitet ja immer als Router, kommt ich gleich zu) sind m.E. so wenige (und mit so vielen Problemen behaftet), daß man diese Einstellung - wenn es nach mir gehen würde - auch bei den DSL-Boxen komplett abschaffen (und damit immer einschalten) könnte.

Wer wirklich vor der Notwendigkeit steht, NetBIOS-Pakete über die WAN-Verbindung zu senden (das kann eigentlich nur dann gutgehen, wenn diese WAN-Verbindung bereits eine VPN-Verbindung ist, also irgendwas in der Richtung der Nutzung von FRITZ!Boxen als VPN-Clients in IP-Netzwerken, event. i.V.m. dem AVM-RAS), der greift als Privatmann (oder -frau) dann eben nicht zu einer FRITZ!Box.

Schon die potentiellen Gefahren aus einer falschen Einstellung sind für meinen Geschmack in den Händen des "normalen Benutzers" deutlich zu groß und das nicht erst, seitdem sich Ransomware auch über Windows-Freigaben verbreitet.

Als WLAN- oder IP-Client kann man die Box auch mit 06.62 natürlich nicht benutzen ... ich persönlich sehe auch den Sinn an der Sache nicht so richtig; zu den (m.E. unzulässigen) Analogien zu den DSL-Modellen habe ich ja anderenorts schon meine Meinung aufgezeigt.

Persönlich glaube ich auch nicht wirklich daran, daß AVM das nachrüsten wird (aber ich habe gerade bei der 6490 inzwischen so oft und so weit daneben gelegen - s.o. -, daß ich geradezu erwarte, mich auch hier zu täuschen) ... der "dsld" hat m.E. schon genug damit zu tun, den Unterschied zwischen eCM/eRouter und "normalem" Router (LAN1-Mode) zu bewältigen.

Da dann auch noch der WLAN-Teil (wie Du weißt) auf dem ATOM-Core läuft, wäre das irgendwie ein Zwitter - wenn der ATOM-Core auf einmal über den Modus als WLAN-STA zum "Tor zur Welt" würde (dann müßte der auch wieder die Unterscheidung zwischen lokalem und "öffentlichem" WLAN-Traffic treffen - jedenfalls bei einem "einzelnen Link" zwischen den Cores) und letztlich sehe ich einen weiteren Grund für den fehlenden Modus als IP-Client eben auch in den zwei Prozessoren - da müßte man schon arge Kopfstände betreiben, damit der Modus "IP-Client" (dann ja für beide Cores und die müssen dann auch noch weiterhin miteinander kommunizieren und zwar getrennt vom Rest des Netzwerkes, was im Router-Mode deutlich leichter umzusetzen ist) am Ende sinnvoll funktioniert.

Ich würde also auch bei der 6590 nicht unbedingt darauf warten (wie gesagt, ich irre mich deutlich zu oft für meinen Geschmack bei den DOCSIS-Modellen), daß da die von Dir so schmerzlich vermißten Funktionen vorhanden sein werden.

PeterPawn · 29 Aug 2016

opto schrieb:
Hast du im Lan1 Modus eigentlich Optionen für "natives"-IPv6?

Ja (06.61):

PeterPawn · 29 Aug 2016

Wieviele IP-Adressen hatte denn Deine FRITZ!Box 6490 mit Version 06.26 im LAN?

Wie bist Du denn an den NAS dieser Box gelangt oder an ihr WLAN?

Wieviele Adressen hast Du denn für die Box konfigurieren können (kleiner, aber feiner Unterschied zu Frage 1)?

Daß es früher möglich war (m.E. funktioniert es auch heute noch, wenn man es manuell einrichtet), heißt ja noch nicht automatisch, daß es richtig, notwendig und sinnvoll war und daß es problemlos funktioniert hätte.

Vielleicht hat es ja bei Dir keine Probleme gemacht ... bei anderen kannst Du schon nachlesen, daß die zwei lokalen IP-Adressen weitgehend unbekannt sind und sich genug Leute schon im Router-Modus (wo die Box selbst als DHCP-Server noch dafür sorgen kann, daß ihre zweite Adresse nicht von jemand anderem belegt wird) darüber wundern, warum bei ihnen einiges nicht mehr wie erwartet funktioniert.

Auch bei mir sind normalerweise die letzten Adressen vor der Broadcast-Adresse in einem Segment die Router, ich mußte der 6490 (trotz Router-Modus) für ihr eigenes VLAN in meinem Netz auch eine kleinere Maske als üblich spendieren, damit der x86-Core nicht mit meinem Router kollidiert.

Selbst wenn es also früher mal funktionierte und bei Dir vielleicht sogar ohne Probleme, war das m.E. bereits "von Hand gesetzt" (wenn nicht, war es auch nur nicht richtig gesperrt, auch das gab es ja noch an weiteren Stellen) und das geht "von Hand" wohl auch heute noch. Schon die Frage, wie man diese Einstellungen bei einem Provider-Branding zum Vorschein bringt, macht das in der 06.26 für mich eher zu einem sehr exotischen Feature - die "offiziellen" Boxen mit "avm"-Branding vor den Retail-Modellen sind sicherlich nicht wirklich "eine Macht", wenn es um Stückzahlen geht.

Daß der "dsld" (und der ist für die Umsetzung dieser Einstellung verantwortlich) weitgehend mit dem bei den DSL-Modellen übereinstimmt und noch einige Modi kennt, die bei einem DOCSIS-Gerät wenig Sinn machen, ist auch bekannt. Die AVM-Leute nutzen selbst auch einen "versteckten" Modus des "dsld" (staticnet, über "box:settings/static_net/...") zum schnellen Einbinden von Boxen ins LAN, wie man in den "internen" Versionen sehen konnte ... die so intern nun auch wieder nicht sind, zumindest bei der 7490 ja nicht, mal sehen, ab wann das auf die 7580 umschwenkt.

Daraus würde ich jetzt nicht die Schlußfolgerung ableiten, daß im GUI auch die Konfiguration von "static_net" möglich sein muß (weil "es geht" oder ich das schon mal gesehen habe) oder daß der ja auch verwendete "Shell in a Box"-Service es nun auch in eine Release-Firmware schaffen muß.

Welchen tieferen Sinn eine 6490 mit nur einer Adresse im LAN haben sollte (wo dann nicht einmal die DVB-C-Funktionen nutzbar wären, denn die laufen ja auch dem x86-Core), kann ich auch nicht erkennen ... also bräuchte so ein Modus als "IP-Client" (von dem ich nicht behaupte, daß man ihn nicht korrekt implementieren könnte, wenn man denn will) schon noch etwas mehr an Einstellungen (und damit an Arbeit beim Erstellen und Testen des GUI), als es eine "übliche DSL-Box" benötigt. Wenn man so etwas implementiert, dann eben auch richtig ... ansonsten gibt es in einer Retail-Box schnell Ärger mit dem Kunden - bei den Provider-Modellen war/ist diese Einstellung ohnehin nicht zu erreichen, da stört so ein "Blinddarm" dann auch nicht wirklich.

- - - Aktualisiert - - -

opto schrieb:
Nein... 6.61 hat das nicht, selbst getestet! Deshlab frag ich ja im 6.62 Thread
Die Betonung lag auf "nativ". IPv6 ist im modem-Modus auch da, ABER nur durch Tunnel

Keine Ahnung, was Du getestet hast ... Du hast auch gefragt, ob die Einstellung vorhanden ist und nicht ob sie funktioniert und von mir selbst getestet wurde (in dem VLAN mit der 6490 gibt es bei mir derzeit kein IPv6).

- - - Aktualisiert - - -

Nochmal etwas weiter "aufgezogen", damit der Typ auch im Bild erscheint:

scuros · 29 Aug 2016

Das findne ich ja nun wieder interessant das es im Lan1 Modus funktioniert mit v6 , denke da weiß ich sogar wo das Problem ist. Ich melde das mal an AVM.

enno25 · 29 Aug 2016

@ PeterPawn

Gibt es eine liste was alles über den Atom Kern läuft und was nicht ?

@ all

Nativ IPv6 gibt es auch mit dieser Firmware nicht, witziger weise habe ich nun aber nativ IPv6 wenn ich das KDG Router/Modem Standard Teil per Bridge Modus vor eine 7490 schalte.

PeterPawn · 29 Aug 2016

Wenn Du "funktioniert" auf die Anzeige der Optionen im GUI beschränkst ... nochmal ganz deutlich: Ich habe nicht getestet, ob/was bei nativem IPv6 funktioniert (u.a. die Geschichte mit der Delegierung eines Präfixes an kaskadierte Router wird wohl genauso aussehen (und damit nicht funktionieren), wie bei den DSL-Modellen). Die Frage von @opto war, ob ich die Einstellungen im LAN1-Modus habe ... und die habe ich (s. Screenshot), mehr aber auch nicht getestet.

scuros · 29 Aug 2016

Ah ok ich hatte das so interpretiert das ein Prefix funktioniert hat nicht nur die Einstellung zu sehen war. Bei DSL Modellen tritt der Fehler auch auf? Ich weiß ja wo das Problem bei den Kabel Boxen ist (TLV 202). Aber genau, gibt es bei DSL Modellen diese Option? Oder funktioniert sie nur auch nicht? Weil da könnte es dann einen roten Faden geben, auch wenn ich bei DSL nun wenig in der Technik bin.

PeterPawn · 29 Aug 2016

@enno25:
Die Prozessliste auf einem x86-Core sieht so aus:

Code:

# ps wl
S   UID   PID  PPID   VSZ   RSS TTY   STIME TIME     CMD
S     0     1     0  1288   360 0:0   09:44 00:00:01 init
S     0     2     0     0     0 0:0   09:44 00:00:00 [kthreadd]
S     0     3     2     0     0 0:0   09:44 00:00:00 [ksoftirqd/0]
S     0     5     2     0     0 0:0   09:44 00:00:02 [kworker/u:0]
S     0     6     2     0     0 0:0   09:44 00:00:00 [migration/0]
S     0     7     2     0     0 0:0   09:44 00:00:00 [watchdog/0]
S     0     8     2     0     0 0:0   09:44 00:00:00 [migration/1]
S     0     9     2     0     0 0:0   09:44 00:00:00 [kworker/1:0]
S     0    10     2     0     0 0:0   09:44 00:00:00 [ksoftirqd/1]
S     0    11     2     0     0 0:0   09:44 00:00:03 [kworker/0:1]
S     0    12     2     0     0 0:0   09:44 00:00:00 [watchdog/1]
S     0    13     2     0     0 0:0   09:44 00:00:00 [cpuset]
S     0    14     2     0     0 0:0   09:44 00:00:00 [khelper]
S     0    15     2     0     0 0:0   09:44 00:00:00 [kworker/u:1]
S     0   167     2     0     0 0:0   09:44 00:00:00 [sync_supers]
S     0   169     2     0     0 0:0   09:44 00:00:00 [bdi-default]
S     0   170     2     0     0 0:0   09:44 00:00:00 [kintegrityd]
S     0   172     2     0     0 0:0   09:44 00:00:00 [kblockd]
S     0   276     2     0     0 0:0   09:44 00:00:00 [ata_sff]
S     0   287     2     0     0 0:0   09:44 00:00:00 [khubd]
S     0   322     2     0     0 0:0   09:44 00:00:00 [rpciod]
S     0   346     2     0     0 0:0   09:44 00:00:00 [khungtaskd]
S     0   351     2     0     0 0:0   09:44 00:00:00 [kswapd0]
S     0   352     2     0     0 0:0   09:44 00:00:00 [fsnotify_mark]
S     0   353     2     0     0 0:0   09:44 00:00:00 [nfsiod]
S     0   355     2     0     0 0:0   09:44 00:00:00 [crypto]
S     0   405     2     0     0 0:0   09:44 00:00:00 [avm_debugd]
S     0   406     2     0     0 0:0   09:44 00:00:03 [avm_event_node]
S     0   473     2     0     0 0:0   09:44 00:00:00 [0000:01:17.0]
S     0   479     2     0     0 0:0   09:44 00:00:00 [mtdblock0]
S     0   485     2     0     0 0:0   09:44 00:00:00 [mtdblock1]
S     0   491     2     0     0 0:0   09:44 00:00:00 [mtdblock2]
S     0   497     2     0     0 0:0   09:44 00:00:00 [mtdblock3]
S     0   503     2     0     0 0:0   09:44 00:00:00 [mtdblock4]
S     0   509     2     0     0 0:0   09:44 00:00:00 [mtdblock5]
S     0   515     2     0     0 0:0   09:44 00:00:00 [mtdblock6]
S     0   521     2     0     0 0:0   09:44 00:00:00 [mtdblock7]
S     0   546     2     0     0 0:0   09:44 00:00:00 [ACC work thread]
S     0   547     2     0     0 0:0   09:44 00:00:04 [kworker/1:1]
S     0   574     2     0     0 0:0   09:44 00:00:00 [kpsmoused]
S     0   591     2     0     0 0:0   09:44 00:00:00 [mmcqd/0]
S     0   622     2     0     0 0:0   09:44 00:00:00 [tffsd_mtd_0]
S     0   771     2     0     0 0:0   09:44 00:00:01 [pm_remote]
S     0   781     2     0     0 0:0   09:44 00:00:00 [jbd2/mmcblk0p9-]
S     0   782     2     0     0 0:0   09:44 00:00:00 [ext4-dio-unwrit]
S     0   858     1  1216   584 0:0   09:44 00:00:00 /sbin/udevd --daemon
S     0   883     1  1284   280 0:0   09:44 00:00:02 tail -f /nohup.out
S     0   884     1  1756   824 0:0   09:44 00:00:02 /usr/bin/ptestd -c1
S     0   929   884  1744   384 0:0   09:44 00:00:00 /usr/bin/ptestd -c1
S     0   931     1  1284   280 0:0   09:44 00:00:02 tail -f /var/ptestd/ptestd.log
S     0   968     1  2300   796 0:0   09:44 00:00:01 avmipcd
S     0   971     1  2984  1448 0:0   09:44 00:00:06 multid2
S     0   995     1  2596  1012 0:0   09:44 00:00:03 l2tpv3d
S     0  1000     1  5988  2552 0:0   09:44 00:00:24 nas_ctlmgr
S     0  1013     1  4864  2224 0:0   09:44 00:00:22 upnpd
S     0  1023     1  2844  1044 0:0   09:44 00:00:03 upnpdevd
S     0  1034     1  3692  2252 0:0   09:44 00:00:20 wland -B
S     0  1113     1  1340   656 0:0   09:45 00:00:00 rpcbind
S     0  1128     1  1252   460 0:0   09:45 00:00:00 rpc.mountd
S     0  1130     1  1364   484 0:0   09:45 00:00:00 rpc.idmapd
S     0  1132     2     0     0 0:0   09:45 00:00:00 [lockd]
S     0  1133     2     0     0 0:0   09:45 00:00:00 [nfsd4]
S     0  1134     2     0     0 0:0   09:45 00:00:00 [nfsd4_callbacks]
S     0  1135     2     0     0 0:0   09:45 00:00:00 [nfsd]
S     0  1136     2     0     0 0:0   09:45 00:00:00 [nfsd]
S     0  1137     2     0     0 0:0   09:45 00:00:00 [nfsd]
S     0  1138     2     0     0 0:0   09:45 00:00:00 [nfsd]
S     0  1139     2     0     0 0:0   09:45 00:00:00 [nfsd]
S     0  1140     2     0     0 0:0   09:45 00:00:00 [nfsd]
S     0  1141     2     0     0 0:0   09:45 00:00:00 [nfsd]
S     0  1142     2     0     0 0:0   09:45 00:00:00 [nfsd]
S     0  1190     1  1288   324 0:0   09:45 00:00:00 /usr/sbin/inetd
S     0  1206     1   916   148 0:0   09:45 00:00:00 /bin/run_clock -c /dev/tffs -d
S     0  1213     1  1288   180 ttyS0 09:45 00:00:00 init
S     0  1216     1  1284   280 0:0   09:45 00:00:00 /usr/sbin/telnetd -l /sbin/ar7login
S     0  1278     2     0     0 0:0   09:45 00:00:00 [SEC int]
S     0  1305     2     0     0 0:0   09:45 00:09:24 [Clock_ISR]
S     0  1317     2     0     0 0:0   09:45 00:00:00 [TSI_ISR]
S     0  1318     2     0     0 0:0   09:45 00:00:01 [Demux_ISR]
S     0  1324     2     0     0 0:0   09:45 00:07:58 [Demux_IO]
S     0  1331     1  5024  2084 0:0   09:45 00:02:41 cableinfo -N
S     0  1390     1  1256   528 0:0   09:46 00:00:00 hostapd -B -g /var/run/hostapd/global
S     0  1393     1  1208   220 0:0   09:46 00:00:00 wpa_supplicant -B -g /var/run/wpa_supplicant/global -D athr
S     0  1410     2     0     0 0:0   09:46 00:00:00 [kworker/0:2]
S     0  1836   858  1172   512 0:0   09:46 00:00:00 /sbin/udevd --daemon
S     0  1837   858  1172   508 0:0   09:46 00:00:00 /sbin/udevd --daemon
S     0  2100     1  2748  1304 0:0   09:46 00:00:00 /sbin/nmbd
S     0  2213   971  1744   576 0:0   09:46 00:00:00 /sbin/chronyd -n -f /var/tmp/chrony.conf
S     0  2257     1  1884   684 0:0   22:19 00:00:00 speedtestd
S     0  2275  1216  1304   444 pts0  22:20 00:00:00 -sh
R     0  2322  2275  1280   340 pts0  22:20 00:00:00 ps wl

Das sind also die NAS-Services (nmbd läuft ständig, smbd und ftpd werden über den inetd gestartet - der nas_ctlmgr macht auch das GUI für "FRITZ!NAS", der ARM-Core leitet auf den x86-Core weiter), der WLAN-Service (hostapd, wpa_supplicant), der gesamte USB-Stack hängt am x86-Core (auch die Partition mit dem ext4-FS als internes Dateisystem für das NAS wird hier gemountet) und wird ggf. für den ARM-Core über NFS(v4) bereitgestellt (damit läuft eben auch der NFS-Server auf dem x86-Core). Dann kommt noch der gesamte TV-Empfang dazu, auch die anderen Interfaces für diesen Service (z.B. SAT-IP, deshalb funktioniert das Einbinden der 4 Tuner der freien Boxen in Kodi auch nur dann, wenn man die IP-Adresse des x86-Core verwendet).

Bei den "üblichen" NAS-Services hat AVM m.E. auch noch so einige Probleme mit der "Zuordnung" ... bei mir funktioniert der Zugriff (per Samba) über die IP-Adresse des ARM-Cores genau nur so weit, daß ich auf die (angebliche) Freigabe "fritz.nas" komme. Hier ist nichts umgestellt, alles original AVM-Einstellungen ... aber trotzdem greift der Versuch des smbd auf dem ARM-Core, die tatsächliche Freigabe über DFS als "\fritz.nas\FRITZ.NAS" an den x86-Core weiterzureichen, irgendwie ins Leere - warum das so ist, habe ich noch nicht genauer untersucht.

Der FTP-Service greift eigentlich irgendwann auch auf den x86-Core zu, mit jeder passiven Datenverbindung zum ARM-Core kommt eine interne Verbindung zwischen ARM- und x86-Core hinzu. Frühere Probleme (schnelle FTP-Verbindungen nacheinander ließen die Box abstürzen) sind offenbar behoben.

Trotzdem kann man nur jedem Benutzer raten, bei der 6490 gleich von Beginn an auf den x86-Core zuzugreifen, wenn man NAS-Dienste nutzen will.

Code:

ftp> get 6490.en-de-es-it-fr-pl.141.06.50.120308002013.image
local: 6490.en-de-es-it-fr-pl.141.06.50.120308002013.image remote: 6490.en-de-es-it-fr-pl.141.06.50.120308002013.image
229 Entering Extended Passive Mode (|||31843|)
150 Opening BINARY mode data connection for '6490.en-de-es-it-fr-pl.141.06.50.120308002013.image' (34809344 bytes).
100% |******************************************************************| 33993 KiB    1.59 MiB/s    00:00 ETA
226 Transfer complete.
34809344 bytes received in 00:20 (1.59 MiB/s)
====================================
ftp> get 6490.en-de-es-it-fr-pl.141.06.50.120308002013.image
local: 6490.en-de-es-it-fr-pl.141.06.50.120308002013.image remote: 6490.en-de-es-it-fr-pl.141.06.50.120308002013.image
229 Entering Extended Passive Mode (|||45826|)
150 Opening BINARY mode data connection for '6490.en-de-es-it-fr-pl.141.06.50.120308002013.image' (34809344 bytes).
100% |******************************************************************| 33993 KiB   11.24 MiB/s    00:00 ETA
226 Transfer complete.
34809344 bytes received in 00:03 (10.31 MiB/s)

Das ist tatsächlich die Übertragung derselben Datei von ca. 34 MB Größe (aus der ext4-Partition im eMMC) ... jeweils über eine kabelbasierte Ethernet-Verbindung (WLAN oder nicht, spielte also für die 6490 keine Rolle), halt direkt vom x86-Core mehr als 5x so schnell.

PeterPawn · 30 Aug 2016

Wenn man eine Retail-Box ordentlich als IP-Client in einem Netzwerk konfigurieren will, braucht man eine andere Maske (und logischerweise auch eine andere "Logik" bei der Auswertung der Eingaben über diese Maske).

Einer 6490 als "IP-Client" nur eine einzelne IP-Adresse im lokalen Netzwerk zuzuordnen, ist ziemlich nutzlos - eben weil man die Funktionen auf dem x86-Core dann nicht mehr nutzen kann.

Zwar verwenden beide Cores am Ende unterschiedliche MAC-Adressen (der x86 nimmt die "macb") und damit ginge zumindest mal DHCP ziemlich problemlos, trotzdem schreit bei einer "echten Einstellung" als "IP-Client" der nächste Kunde garantiert wieder (auch wenn Du das vielleicht nicht sein würdest), daß er gar keinen DHCP-Server in seinem Netz betreiben will und bei ihm alles nur "handgeschöpte IP-Adressen" sind.

Da dieser Standpunkt auch nicht von der Hand zu weisen ist, braucht es für eine "ordnungsgemäße Konfiguration" einer 6490 als IP-Client eben eine Maske, wo man der Box auch zwei statische IP-Adressen geben kann (inkl. der Logik dahinter, die darf man nicht außer acht lassen ... schon die derzeitige "Suche" nach der Adresse des x86-Cores (die letzte "non-broadcast"-Adresse im Segment) ist ja nicht so ganz unproblematisch).

PeterPawn · 30 Aug 2016

Ich habe auch nicht geschrieben, daß ich das in den anderen Modi gut finde (ich hoffe im Gegenteil, daß AVM das irgendwann auch mal konfigurierbar hinbekommt) ... aber im Router-Modus funktioniert das tatsächlich noch (in der überwiegenden Zahl der Fälle), weil eben die FRITZ!Box dann auch den DHCP-Server gibt und da sorgt sie nun mal alleine dafür, daß es eben keine Überschneidungen für die letzte Adresse gibt. Da ist zumindest die Wahrscheinlichkeit eines Problems aus dieser Besonderheit wesentlich kleiner ... und wenn Du reagieren willst auf meine Einwände, würde ich es begrüßen, daß Du diese nicht immer nur isoliert voneinander siehst. Gerade zu dem Unterschied, ob eine Box als Client ein Netzwerk "mitbenutzt" oder als Router selbst der zentrale Dienst im Netzwerk ist, habe ich auch weiter vorne schon geschrieben und das nur nicht noch einmal in #18 wiederholt.

Aber ich will mich auch gar nicht streiten, ob die Box nun als IP-Client laufen soll oder nicht ... die Frage, woher Du (außer aus alten Firmware-Versionen, da ging aber bei anderen Modellen auch mal WDS, was heute auch keine neue Firmware kann, das "Abschalten" früher bekannter Merkmale ist also nicht nur ein Problem der 6490, selbst den nmbd diverser Modelle kann man in so eine Reihe einordnen) die Gewißheit nimmst oder die Forderung ableitest, eine 6490 müsse nun auch als IP-Client oder gar als WLAN-STA arbeiten (die Frage des Mobilfunks haben wir ja wohl geklärt?) plagt mich immer noch oder ich habe die Antwort darauf vielleicht auch nur überlesen.

Daß es keine 1:1-Analogie zu den DSL-Modellen gibt (die 6490 wird auch kaum der 7390 das Wasser reichen können als DECT-Repeater), wird sich wohl irgendwann mal "rumsprechen". Warum jemand mit dem Bedarf für einen IP-Client im Netzwerk jetzt ausgerechnet zu einer 6490 greifen sollte (oder zu einer 6840), verstehe ich auch nicht so richtig ... braucht man einen "IP-Client", nimmt man eben eine andere Box. Nur weil auf der A-Klasse und dem MB-Transporter ein Stern ist und die von demselben Hersteller sind, wird ja auch niemand auf die Idee kommen, die Einbauküche im Kofferraum der A-Klasse von IKEA nach Hause zu fahren, weil er das bei einem anderen Auto desselben Herstellers ja auch konnte. Wenn das "Auto" jetzt zu sehr hinkt, nimm den Kühlschrank oder die Espresso-Maschine oder was auch immer ... es gibt Geräte für einen definierten Einsatzzweck und nur weil es von demselben Hersteller andere Geräte gibt, die etwas ähnliches machen, müssen ja noch lange nicht alle genauso funktionieren. Das läuft bei anderen Routerherstellern auch nicht anders, auch da gibt es Geräte mit unterschiedlichen Funktionen (und unterschiedlichen Zielgruppen).

thtomate12 · 31 Aug 2016

Das UMTS-Feature der 6490 sah schon immer so aus; was hat das mit dem 1.8. zu tun?

PeterPawn · 31 Aug 2016

@opto:
Das Verhalten bei der Verwendung eines UMTS-Sticks ist bei der 7490 genauso wie bei der 6490 - da müßte ich mich schon schwer täuschen oder Du meinst wieder einmal etwas anderes als ich (ich schreibe die ganze Zeit vom Menüpunkt "Mobilfunk" unterhalb von "Internet").

Der Betrieb einer 6490 ohne das eCM ist nicht automatisch dasselbe wie die Betriebsart "IP-Client". Auch ohne korrekte CM-Zertifikate kann eine 6490 als kaskadierter Router benutzt werden. Bei eDOCSIS-Geräten kommt halt noch ein Modus hinzu, das wäre der mit ausgeschaltetem eRouter (TLV 202.1 = 0), der wird hier (bei eDOCSIS-Geräten allgemein, nicht bei der 6490 konkret) aber nur in Verbindung mit einem aktivierten eCM beschrieben. Das wäre dann die von Dir auch irgendwo gesuchte "LAN-Bridge", bei der das eCM ohne den eRouter das CMCI 1:1 an die LAN-Anschlüsse durchreicht. Auch diese Betriebsart wird aber über die CM-Konfiguration "von außen" eingestellt. Im Prinzip ist eine FRITZ!Box schon im LAN1-Modus gar kein DOCSIS-Gerät mehr, denn da ist weder das eCM noch der eRouter aktiv (letzterer kann gar nicht initialisiert werden ohne das eCM) ... damit ist die FRITZ!Box nur noch "ein normaler Router".

Ob/wann AVM sich entschließt, da noch eine weitere Betriebsart offiziell(!) hinzuzufügen, werden sie Dir sicherlich irgendwann mitteilen. Ich halte einen derartigen Modus weiterhin für nicht notwendig (es gibt andere Geräte, die das können, wenn der Bedarf danach besteht) und wenn ich mir bei den DSL-Boxen so ansehe, was da schon bei vielen an Unklarheiten zwischen dem Betrieb als Router und als "normaler LAN-Client" vorhanden ist, dann wird mir eher angst und bange, wenn da bei einem (potentiellen) DOCSIS-Gerät noch ein zusätzlicher Modus hinzukommt. Gerade Dein angetexteter Einsatz der 6490 als "aufgebohrter DVB-C-Repeater" ist ja das, was ich die ganze Zeit versucht habe, Dir näher zu bringen ... das ist dann eben nicht der Betrieb als ein IP-Client, sondern der als zwei getrennte Clients, sonst kommst Du an den TV-Teil gar nicht heran.

Da das eben auch irgendwie konfiguriert werden muß, ist das bisher noch gar nicht (funktionierend) umgesetzt. Als "Nicht-Router" hat so eine Box dann mit der Konfiguration des LAN aber auch so gar nichts mehr zu tun und die bei der eigenen Verwaltung des LAN gerade noch so akzeptable, eigenmächtige Konfiguration der Adresse des zweiten Kerns geht beim Einsatz als IP-Client mal gar nicht mehr.

Also muß neben der Konfiguration über DHCP noch die Möglichkeit der Konfiguration mit statischen IP-Adressen her - es soll auch Leute geben, die keinen DHCP-Server in ihrem LAN betreiben und ohne IP-Adresse ist der Betrieb als IP-Client (egal für welchen Kern) auch nicht möglich.

Die Konfiguration über DHCP ist eben für beide[/] Kerne bisher auch nicht umgesetzt, jedenfalls nach meiner Meinung und das ist dann wirklich mal ein Punkt, wo man durch eigenen Test das Gegenteil nachweisen könnte, das steht auch Dir frei - zeige mir einfach, wie eine 6490 nach der manuellen Umschaltung auf "IP-Client" ihrerseits jetzt schon zwei DHCP-Requests sendet, um sich die beiden notwendigen IP-Adressen zu besorgen und dann reden wir darüber, daß da "mutwillig" diese Funktion entfernt wurde, wobei das Problem bei statischen Adressen dann weiterhin besteht und das ist deutlich einfacher "zu sehen", wie die Firmware da bisher aussieht - ich habe noch keine Lua-Datei gesehen, die eine Konfiguration der beiden erforderlichen IP-Adressen enthalten hätte.

Es gibt wohl schon genug (Billig-)HDMI-Sticks, wo man keine statischen IP-Adressen einstellen kann ... meines Erachtens sollte sich die FRITZ!Box nicht in die Reihe solcher Geräte einordnen. Also muß da für die ordentliche Konfiguration als IP-Client zusätzlicher Aufwand in die Firmware gesteckt werden und das "Abschalten" ist erst einmal einfacher.

Ob das nun für alle Zeiten ist oder AVM da die Arbeit noch investiert, weiß ich genauso wenig wie Du ... aber ich weiß zumindest, daß es keine 1:1-Umsetzung der Lösung bei anderen Geräten geben kann, weil (1) die anderen nicht aus zwei LAN-Clients bestehen und (2) das "Errechnen" irgendeiner IP-Adresse für den zweiten Kern - wie im Router-Modus - auf der Basis einer einzelnen eingestellten statischen IP-Adresse schon fragwürdig wäre und spätestens dann, wenn die Box selbst ihre IP-Adresse über DHCP aus dem LAN erhält, geht so etwas gar nicht mehr (schon weil eben nur eine Adresse reserviert wird und der richtige/zuständige DHCP-Server die andere jederzeit anders vergeben würde).

Also braucht auch das eine Änderung der Firmware (jeder Core muß seinen eigenen DHCP-Request absetzen) und auch das ist wieder zusätzlicher Aufwand, so etwas zu implementieren. Aber ich wiederhole mich halt (gezwungenermaßen), besser kann ich aber auch nicht mehr "erklären", warum ich Deinen Standpunkt (wird alles nur ausgebaut, geht woanders ja auch) nicht nachvollziehen kann und darum auch nicht teile.

Warum Du ständig darauf beharrst, die 6490 müsse alle Funktionen der 7490 bieten, verstehe ich schon prinzipiell nicht. Sie ist z.B. 40 EUR günstiger bei der UVP, anders aufgebaut (schon die Aufteilung der Funktionen auf die beiden Kerne erfordert in meinen Augen andere Wege und auch andere Kompromisse, beim UMTS-Stick habe ich das aufgedröselt, paßt Dir nicht, auch gut - ich habe es nicht programmiert, nur analysiert) und die Firmware ist/muß abgeschottet sein. Im Prinzip wäre jeder mit dem Klammerbeutel gepudert, wenn er unbedingt ein Gerät mit einer dermaßen "verschlossenen" Firmware in seinem Netz als IP-Client betreiben will, wenn es doch genug Alternativen gibt, die deutlich "offener" wären.

Aber ich bin es auch leid, mich ständig zu wiederholen ... das Thema "Warum macht die 6490 das nicht so oder so?" ist für mich hiermit offiziell durch.

Ich habe darauf auch keine definitiven Antworten, nur Versuche der Erklärung anhand des Aufbaus. Die können stimmen, müssen es nicht (habe ich auch nie behauptet) ... wenn Du auf "Angebote" möglicher Erklärungen ohnehin nur mit "aber der X hat das auch (gesagt oder was auch immer) und ich will das jetzt auch so" reagierst und nicht einmal mehr Deine Beispiele stimmen, wird das echt unangenehm und unproduktiv.

Deine erste Feststellung für die 6490 war es ja sogar, UMTS-Sticks gingen gar nicht und gerade Du solltest eigentlich selbst in der Lage sein - zumindest der Zugang sollte vorhanden sein - die Firmware selbst an solchen Stellen zu untersuchen und zumindest einmal nachzusehen, bevor Du etwas schreibst.

Das ziemlich wilde "Gespringe" in der Diskussion und abweichende Testergebnisse bei Dir und bei mir zieht sich bis in diesen Thread ... (1) die Bilder von mir zu IPv6 sind nun mal definitiv von einer 06.61 im LAN1-Modus, also ohne aktiviertes eCM) und (2) wie sich das GUI bei einer 7320 bzgl. der Menüpunktes "Mobilfunk" verhält, kann ich nicht selbst prüfen, mangels Gerät - es ist mir auch schlicht egal, weil ich die Notwendigkeit einer Parallele beim Verhalten genauso wenig sehe, wie ich so einen Vergleich verstehe.

Trotz bisheriger Ungenauigkeiten und/oder Meinungsverschiedenheiten, welche Einstellungen nun anders oder nicht vorhanden sind, bin ich bereit, Dir das bei der 7329 zu glauben - ich würde es trotzdem nicht verstehen, warum die sich nun ausgerechnet anders verhalten sollte als die mir zugänglichen Modelle und warum Du dann ausgerechnet das Verhalten der 7320 (die sich dann immer noch anders verhält als meine 7490 und mit der vergleichst Du die 6490 dann selbst) als "richtig" ansiehst und bei diesem Punkt darauf besteht, die 6490 müsse sich hier an der 7320 orientieren, ist mir ein echtes Rätsel ...

Aber Du hast zweifellos recht ... das ist hier OT.

Ich wollte auch keine Diskussion mit Dir hier beginnen, ich wollte auf das Vorhandensein des Paketmitschnitts hinweisen und habe dann noch Deine Frage (mit Screenshot) beantwortet, wie das bei dieser Version mit der "nativen IPv6-Unterstützung" aussieht, wenn die Box im LAN1-Modus ist:

opto schrieb:

Hast du im Lan1 Modus eigentlich Optionen für "natives"-IPv6?

Zum Vergrößern anklicken....

Da ich bereits vorher die Unterschiede der Versionen 06.61 und 06.62 untersucht hatte (dabei fiel es mir ja auf, daß sich das Capture geändert hat) und mir sicher war, daß es an dieser Stelle keinen Unterschied geben sollte, war ich so kühn, gleich das Bild von der 06.61 zu verwenden - selbstverständlich nicht, ohne mich vorher zu vergewissern, daß ich Deine Frage nach "nativem IPv6" auch wirklich mit "ja, ist sichtbar" beantworten kann. Wenn Du mir gleich im Anschluß dann erklärst, das wäre bei der 06.61 aber nicht da:

opto schrieb:

Nein... 6.61 hat das nicht, selbst getestet! Deshlab frag ich ja im 6.62 Thread
Die Betonung lag auf "nativ". IPv6 ist im modem-Modus auch da, ABER nur durch Tunnel

Zum Vergrößern anklicken....

und ich wüßte vermutlich nicht, was "nativ" meint, dann nervt das ziemlich ... aber gut. Meinen Versuch, das mit dem nächsten Screenshot dann noch einmal zu untermauern und die Feststellung, daß Du dann wohl etwas anderes getestet haben mußt, ignorierst Du dann (ist ja hier OT, geht ja eigentlich um die 06.61) und reitest weiter auf dem schmerzlich vermißten IP-Client herum.

Wenn Du jemanden suchst, der Deiner Kritik an der Firmware 1:1 zustimmt, kann ich damit leider nicht dienen ... das will ich u.a. deshalb nicht, weil eben so eine Firmware für ein DOCSIS-Gerät per se schon noch komplizierter ist als eine für einen DSL-Router und bei Puma6-Geräten kommt dann noch das Problem hinzu, daß man zwei Kerne aufeinander abstimmen muß und ihre Aktionen irgendwie zu synchronisieren sind. Das ist in etwa dasselbe wie zwei getrennte Geräte im Netzwerk und wenn sich daraus einige Einschränkungen ergeben ggü. einem Gerät, auf dem alle Funktionen versammelt sind, kann ich das (in Grenzen) nachvollziehen.

Nur weil das Ding ein einziges Gehäuse hat, ist es aus programm- und netzwerktechnischer Sicht noch lange kein einzelnes Gerät ... wer da ständig mit "aber da und da geht das doch auch" anfängt, der hat vermutlich sogar recht, daß man alles (zumindest vieles) auch so umsetzen/nachbauen könnte, daß es nach außen wieder wie ein Gerät wirkt.

Wenn so jemand dann aber (trotz meinerseits unterstelltem Verständnis der Grundbegriffe) nicht verstehen oder einsehen will, daß es schon noch einen Unterschied gibt und so ein "Rückbau" eben gar nicht unbedingt absichtlich erfolgt sein muß, sondern durch den abweichenden Aufbau tatsächlich zusätzliche Maßnahmen erforderlich sein können/sollten und es so zusätzlichen Aufwands nicht für den Rückbau, sondern für den Nachbau erfordern könnte, dann wird mir das auch irgendwann zu müßig.

Fazit:
Ich bin nicht Deiner Meinung, ich kann damit leben, Du mußt es auch.

Weitere Argumentationen/Spekulationen/Erklärungsversuche, warum das eine oder andere so sein könnte, spare ich mir ... Du willst sie weder lesen noch auf sie eingehen (und sie meinetwegen auch tatsächlich widerlegen, dann aber bitte nicht mit "da und da ist das so" und wenn schon mit diesen Vergleichen, dann solltest Du Dich mal auf ein (Schwester-)Gerät festlegen und nicht unter dem Dach der 6490 jede Funktion versammeln wollen, die Du mal in irgendeinem anderen Gerät gefunden hast - das macht die Gegenargumentation nämlich auch ausgesprochen mühsam) und dann kann ich mir die Mühe des Schreibens auch ersparen.

Ich erwarte nicht, daß Du mir zustimmst, aber sich auf den Boden zu werfen und immer wieder "ich will aber einen IP-Client in der 6490 haben" zu artikulieren, wird Dich (meiner Meinung nach, daß ich mich bei der 6490 für meinen Geschmack bei den Absichten von AVM deutlich zu oft irre, habe ich auch selbst schon in diesem Thread festgehalten) nicht wirklich weiterbringen.

Nachdem Du nun Deine 6490 zurückgegeben hast, wird Dir das Nachvollziehen weiterer Änderungen in der Firmware ja schwerer fallen ... sollte ich in einer künftigen Version feststellen, daß der Betrieb als IP-Client oder als WLAN-STA für die WAN-Verbindung möglich ist, werde ich das nicht unter den Tisch fallen lassen und Dich über das IPPF (quasi "über Bande") benachrichtigen, falls das AVM nicht tut im Rahmen der von Dir eingetüteten Support-Anfragen zu diesen Themen.

PeterPawn · 31 Aug 2016

@opto:
Du hast schon gelesen, was unter der Select-Box steht, wenn Du da "Mobilfunkanbieter" einstellst?

Bei der 6490 gibt es diese schicke Select-Box nicht. Wozu auch, sie unterstützt den Zugang über DOCSIS - da interessiert der Provider erst mal gar nicht - und über LAN1 und auch dort ist der Provider ziemlich egal. Kaum steckt dann der UMTS-Stick an der Box, sieht das wieder genauso aus wie bei den anderen Modellen ... da wird der tatsächliche Mobilfunk-Betreiber genauso unter "Mobilfunk" eingestellt, wie bei der 6490 auch.

Dir fehlt also am Ende nur diese Box? Was sollte denn da bei einer 6490 außer dem Punkt "Mobilfunkanbieter" (der ohnehin nur dafür sorgt, daß der Text darunter bei seiner Auswahl sichtbar wird und sonst nicht eine Einstellung ändert) da nach Deiner Meinung noch enthalten sein?

Wenn Du auch vermutest, daß bei DHCP-Modus für den "handgemachten" IP-Client-Modus die zweite Adresse errechnet wird, dann müßtest Du doch meinen Einwand in diesem Punkt erst recht verstehen ... was ist denn das für ein "Benehmen", wenn ein Netzwerk-Gerät aus einem DHCP-Request eine zweite verwendete Adresse einfach "ableitet" ... wie soll denn der zuständige DHCP-Server damit umgehen?

PeterPawn · 31 Aug 2016

Wenn jetzt eine Select-Box, die bei passend eingestelltem Auswahl-Wert dann per JS eine "div" ein- und ausschaltet, als "Feature" gelten soll, dann habe ich tatsächlich den Faden verloren. Meine Frage, was da neben "Mobilfunkanbieter" noch stehen sollte aus Deiner Sicht, hast Du vermutlich überlesen.

Ja, hier habe ich UMTS "eingebracht" ... das war dann so ziemlich das einzige der von Dir als "fehlend" monierten Features, das Du nicht selbst (erneut) aufgezählt hast, weil Du irgendwo anders auch feststellen mußtest, daß es funktioniert.

Hier habe ich es nur als Beispiel dafür angeführt, daß etwas gründlichere Tests (im anderen Thread habe ich noch von gründlicherem Überlegen geschrieben) manchmal auch nicht schaden können und das war nur als "Komplementär" (im Sinne von "Ergänzung") für meine Feststellung gedacht, daß Du Dich bei der nativen IPv6-Unterstützung (zumindest bei der Sichtbarkeit der Optionen) hier weiter vorne auch geirrt haben könntest oder zumindest, daß ich da andere Ergebnisse (für dieselbe Version) erhalten habe.

thtomate12 · 31 Aug 2016

opto schrieb:
ich davon aus gehe dass es kein UMTS gibt wenn die Auswahlmöglichkeit fehlt die man von Geräten aus der Generation vorher kennt?

Es liegt nicht an der Generation der Hardware, es liegt an der Software, diese Select-Box ist relativ neu, früher gab es dort "Zugang über LAN" und "Mobilfunk" nicht zur Auswahl, da musste man über Anderer Anbieter bzw. direkt den Menüpunkt "Mobilfunk" gehen. Da gibt es kein richtig oder falsch. Das ist Ansichtssache. Ich finde das neue Menü unpraktisch, da es nun zwei Wege (für Routing mit LAN1 als WAN) gibt.

simpel · 8 Sep 2016

Richtet man bei dieser Firmware einen Sipgate-Account ein, wird dieser mit einem Präfix in der Ortsvorwahl eingerichtet, (Z.B. 030 für Berlin), das führt dazu, dass man die Testrufnummern 10000, bzw 10005 nicht wählen kann. Diese Verhalten habe ich auch auf der 7490 mit aktueller Labor beobachtet. Soweit sogut, wenn ich jetzt hingehe und diese Rufnummer manuell anpassen möchte funktioniert das in der 7490 folgendermassen: Den "Stift" an der Rufnummer anklicken zum bearbeiten, dann den Telefonie-Anbieter von Sipgate in "andere Anbieter" ändern, dann werden weitere Felder zur Anpassung angezeigt, die bisherigen eingetragenen "Werte" wie z.B. Zugangsdaten und Server sind zu sehen, Präfix kann geändert werden. Bei der Aktuellen 6.62 auf der 6490 sind die Felder beim Wechsel auf "andere Anbieter" alle leer, und müssen nachgetragen werden. Dieses halte ich für einen Bug in der Firmware, kann das jemand bestätigen?

Gruß
Simpel

[Info] FRITZ!Box 6490 Firmware 141.06.62 von 23.08.2016

IPPF-Promi

Neuer User

Neuer User

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

Anhänge

Neuer User

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Promi

Neuer User

Statistik des Forums