[Problem] FRITZ!Box 6490 Cable (lgi) 141.06.50 mit Packet-Loss

odoll · 30 Aug 2016

Moin,

heute hat ein Sub von UnityMedia meinen neuen Internet-Zugang inkl. Unterverteilung und 6490 bereit gestellt (200/20 inkl. Tel-Komfort).

Die 6490 ersetzt die private 7490 bei meiner Tochter, wobei letztere eben an dieser Stelle bis dato als reiner AP lief.

Nur bin ich mit der Performance der 6490 nicht so wirklich glücklich, denn ich 'sehe' um die 20% Paketverluste bei pings von verschiedenen Rechnern zu ihr. (Von daher habe ich den Uplink vom meinem 16/1 ADSL noch gar nicht umgestellt.)

Da ich dachte, wir hätten beim Umbau evt. das GigE-Kabel beschädigt, welches den Router über einen D-Link DGS-100-24 an den Rest des Netzwerks anbindet, habe ich die "AP" 7490 noch mal in Stellung gebracht, aber hier alles tip top

Code:

Ping-Statistik für a.b.c.2:
    Pakete: Gesendet = 138, Empfangen = 138, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

Sobald ich die 6490 aber wieder anstöpsle

Code:

Ping-Statistik für a.b.c.10:
    Pakete: Gesendet = 145, Empfangen = 118, Verloren = 27
    (18% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 1ms, Mittelwert = 0ms

Das Kabel habe ich auch schon von "LAN 1" mal in "LAN 4" umgesteckt, aber mit dem gleichen Ergebnis.

Bevor ich ein Ticket bei UM aufmache, wollte ich mal eine '2.te' Meinung hören von Leuten, die sich mit der 6490 auskennen (ist die vt. zu busy - laut CPU Statistik würde ich sagen: Nein,da im Mittel bei 76%"

- - - Aktualisiert - - -

PS: was ich auch sehr unschön finde ist, dass sich dieses Modell die .254 aus dem lokalen IPv4 Adressbereich einfach für den integrierten NAS-Service grabscht, aber auch nicht freigibt, wenn man NAS und Streamuing deaktiviert.

Da dies mit meinem NAS kollidierte, der auch DHCP-Server u.v.m.im LAN ist, habe ich die Konfig per FBEditor entsprechend geändert und alle EInträge in der 6490 FB Konfig, von a.b.c.254 auf a.b.c.222 geändert, was wohl auch Wirkung zeigt. Die 222, bis datou nbenutzt habe ich nun erst mal zusätzlich für die FB reserviert.

Verbessert hat das an den Paket-Verlusten aber nichts.

PeterPawn · 30 Aug 2016

Die zweite IP-Adresse ist ja auch nicht nur für den NAS-Service und das Streaming ... die ist für den zweiten Prozessor in diesem Modell und auf dem läuft z.B. auch das WLAN.

Ich würde einfach mal testen, ob die Verluste auch dann auftreten, wenn (1) nicht an der IP-Konfiguration über die ar7.cfg gedreht wurde und (2) die Adressbereiche des eigenen LAN und der FRITZ!Box sich nicht überlappen. Es ist sicherlich nicht so schwierig/auswändig, die 6490 und einen Client am anderen Ende des Kabels in ein eigenes LAN-Segment zu verfrachten und dann mal zu testen.

Treten dabei keine Verluste auf, liegt es wohl an der (unerwünschten) Interaktion mit dem vorhandenen Server und wie man so eine 6490 auch ohne Editieren der ar7.cfg zur Verwendung anderer Adressen "überredet", habe ich gerade erst irgendwo geschrieben ... der ARM-Core nimmt die erste, der x86-Core die letzte im Segment - solange der Rest seitens der 6490 an Adressen außerhalb des eigenen kleineren Segments direkt an das Gateway geht und von diesem geroutet wird (notfalls eben einfach weitergeleitet im LAN), funktioniert das auch, wenn die anderen Clients eine andere Maske verwenden.

Ich würde jedenfalls gerade für die Fehlersuche nicht von Hand in der ar7.cfg ändern ... dann kann man daraus resultierende Probleme nicht mehr sicher ausschließen.

odoll · 31 Aug 2016

PeterPawn schrieb:
[...] Es ist sicherlich nicht so schwierig/aufwändig, die 6490 und einen Client am anderen Ende des Kabels in ein eigenes LAN-Segment zu verfrachten und dann mal zu testen.[...]

Ja, das werde ich mal machen. Was mir gestern schon aufgefallen war ist, dass die PINGs zur Default-GW-IP (.10) der 6490 und nun .222 alle von den Aussetzern betroffen sind. Ein per WLAN an der FB eingebuchter PC hatte über die LAN-Strecke mit PINGs an den Server .254 keine Aussetzer.

PeterPawn schrieb:
[...] der ARM-Core nimmt die erste, der x86-Core die letzte im Segment - solange der Rest seitens der 6490 an Adressen außerhalb des eigenen kleineren Segments direkt an das Gateway geht und von diesem geroutet wird (notfalls eben einfach weitergeleitet im LAN), funktioniert das auch, wenn die anderen Clients eine andere Maske verwenden.

OK; ich hatte aus der eigenen Anzeige der 6490 geschlossen, dass die 192.168.178.1 (bei mir nun per GUI auf a.b.c.10/24 geändert) als DF-GW und die 192.168.178.254 (bei mir nun per FBEditor auf a.b.c.222/24 geändert) als NAS-IP propagiert werden.

- - - Aktualisiert - - -

PS: das sind übrigens die 3 Stellen wo ich per FBEditor vier mal a.b.c.254 durch a.b.c.222 ersetzt habe:

Code:

ar7cfg {
        br2interfaces {
                name = "lan";
                dhcp = no;
                ipaddr = a.b.c.222;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth0.2", "ath?*";
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                no_dnsd_static = no;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
        }
landevices {
        {
                ip = a.b.c.222;
                neighbour_name = "fritz.nas";
                mac = C8:0E:14:8A:DF:E0;
                auto_etherwake = no;
                ifaceid = ::ca0e:14ff:fe8a:dfe0;
                staticlease = no;
                ipv4forwardrules = "tcp 0.0.0.0:45495 a.b.c.222:443 0";
                ipv6firewall {
                        enabled = yes;
                        exposed_host = no;
                        ping6_allowed = no;
                        rules = "TCP 443";
                }
                allow_pcp_and_upnp = no;
        }
}
nas_cpu {
        ip = a.b.c.222;
        https_ipv4_external_port = 45495;
}

PeterPawn · 31 Aug 2016

Ich würde immer noch (bis das genauer getestet ist) auf die manuelle Änderung verzichten.

Erst dann, wenn ich wirklich sicher wäre, daß auch der letzte UPnP-Broadcast und die letzte darüber gesendete mDNS-Annonce oder auch die Info über den MediaServer (usw.) tatsächlich diese Änderung auch berücksichtigen (ich könnte mir z.B. vorstellen, daß der ARM-Core die mDNS-Informationen für beide Kernel sendet), erst dann würde ich darüber nachdenken.

Da die interne Kommunikation zwischen den Kernen nicht über diese Adressen läuft, kriegt der ARM das auch nicht unbedingt mit, wenn die von ihm "angenommene" Adresse des x86-Cores nicht stimmt ... solange der nicht auch "br2interfaces" auswertet und da stellt sich die Frage, warum er das tun sollte. Die anderen Angaben dort (169.254.1.2 für die interne Verbindung und noch irgendein Interface) interessieren den ARM-Core nicht, die interne Kommunikation ist (ziemlich) fest verdrahtet und kann ohnehin nicht geändert werden. Nicht undenkbar, daß der ARM den Abschnitt auch liest, aber nicht zwingend.

Wenn irgendwo noch einmal derselbe Algorithmus zur Ermittlung der IP-Adresse des x86-Core benutzt wird, wie bei der Änderung der Einstellungen (in boxnet.lua - das läuft intern im ctlmgr und ist nur ein ganz normales einzelnes Setzen der IP-Adresse für den ARM (lan0), der Rest ist Automatik), dann kommt der eben zu einem anderen Ergebnis und gerade bei der Diagnose von Netzwerk-Problemen macht die Einführung einer weiteren (unsicheren) Variablen nun nicht unbedingt Sinn - zumindest nicht am Beginn.

odoll · 31 Aug 2016

opto schrieb:
Der "landevices" Teil ist egal, das ist die Anzeige der Hostnamen im UI.

Yep, aber IMO nur konsequent das dann auch direkt mit zu korrigieren

(auch wenn ich die 'Aktualität' der Geräte-Übersicht der FBen - bei mir 7270v2/3 und 7490 immer suboptimal fand, insb. wenn die FB nicht selbst für die Vergabe von IPs zuständig sind, sondern eine autonomer dnsmasq. Und das, obwohl mir sogar (oder genau weil) einen offizieller IP PI /24 Bereich 'gehört', für den ich sowohl intern als auch extern die Vorwärts- und Rückwärts-Zonen administriere - die FB scheren sich meist nicht drum.)

opto schrieb:
Packetloss scheint mir ne Krankheit der aktuellen Firmware 6.5-6.6 zu sein. Ich hab das mit einem via Lan angeschlossenen Repeater. Klappt paar Wochen, dann wieder Verluste. Sehr nervig beim Streamen!

Oh :-( Werde allerdings erst heute Abend testen können - Ich hatte mit der Beauftragung bei UM eh auf den Fall des Router-Zwangs gewartet und bin moralisch darauf eingestellt, mir eine eigene 6490 zuzulegen.
Aber ich fürchte die 'freien' 6490 machen das gleiche "Gehampel" mit den zwei .1 .254 IPs?

odoll · 1 Sep 2016

Danke.

So, ich habe wie von PeterPawn angeregt mal ein paar (einfache) Tests gemacht, deren Ergebnisse wohl auf die Kombi 6490 und D-Link-Switch hindeuten, aber IMO die Frage des tatsächlich "Schuldigen" offen lassen!?

Als Erstes habe ich die "unverbogene" Konfig wieder eingespielt, bei der die .254 aktiv ist. Mit dem Laptop (W10pro) meiner Frau bewaffnet habe ich PING-Tests in folgenden Szenarien durchführt (noch ohne die 6490 vom restlichen Netz zu trennen.)

Per WLAN an 6490:

Code:

Ping-Statistik für a.b.c.10:
    Pakete: Gesendet = 141, Empfangen = 141, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 1ms, Maximum = 64ms, Mittelwert = 4ms

Per LAN1 an 6490:

Code:

Ping-Statistik für a.b.c.10:
    Pakete: Gesendet = 84, Empfangen = 84, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 2ms, Mittelwert = 0ms

Von Server via Switch (Port5<->Port3)

Code:

--- tubedoor.mydomain.de ping statistics ---
86 packets transmitted, 74 received, 13% packet loss, time 85072ms
rtt min/avg/max/mdev = 0.659/0.801/1.935/0.162 ms

Von PC via Switch (Port4<->Port3)

Code:

Ping-Statistik für a.b.c.10:
    Pakete: Gesendet = 68, Empfangen = 60, Verloren = 8
    (11% Verlust),
Bytes=32 Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 1ms, Mittelwert = 0ms

Und letztlich das Kabel der 6490 LAN4 zum Switch Port3 ausgestöpselt und mit dem PC verbunden, wieder Alles OK. Da die 6490 nun vom "Rest" des Netzes getrennt war, habe ich per nmap auch einen 'Quick Scan' über den .1-.254 laufen lassen.

Code:

Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2016-08-31 20:23 Mitteleuropäische Sommerzeit

Nmap scan report for a.b.c.10
Host is up (0.0000060s latency).
Not shown: 95 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
111/tcp  open  rpcbind
443/tcp  open  https
5060/tcp open  sip
MAC Address: C8:0E:14:XX:YY:ZZ (AVM Audiovisuelles Marketing und Computersysteme GmbH)

Nmap scan report for a.b.c.91
Host is up (0.0015s latency).
All 100 scanned ports on a.b.c.91 are closed (50) or filtered (50)
MAC Address: E0:B5:2D:XX:YY:ZZ (Apple)

Nmap scan report for a.b.c.102
Host is up (0.0000020s latency).
All 100 scanned ports on a.b.c.102 are closed
MAC Address: B0:05:94:XX:YY:ZZ (Liteon Technology)

Nmap scan report for a.b.c.153
Host is up (0.00s latency).
Not shown: 99 closed ports
PORT     STATE SERVICE
8008/tcp open  http
MAC Address: 0C:47:C9:XX:YY:ZZ (Amazon Technologies)

Nmap scan report for a.b.c.254
Host is up (0.0000070s latency).
Not shown: 96 closed ports
PORT     STATE SERVICE
80/tcp   open  http
111/tcp  open  rpcbind
443/tcp  open  https
2049/tcp open  nfs
MAC Address: C8:0E:14:XX:YY:ZZ (AVM Audiovisuelles Marketing und Computersysteme GmbH)

Nmap scan report for a.b.c.13
Host is up (0.00022s latency).
Not shown: 95 closed ports
PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
3389/tcp open  ms-wbt-server
5357/tcp open  wsdapi

Nmap scan report for a.b.c.14
Host is up (0.00s latency).
Not shown: 96 closed ports
PORT     STATE SERVICE
135/tcp  open  msrpc
445/tcp  open  microsoft-ds
3389/tcp open  ms-wbt-server
5357/tcp open  wsdapi

Nmap done: 254 IP addresses (7 hosts up) scanned in 46.93 seconds

.13 u. .14 sind die (W)LAN IP Adresses des PCs, zudem sah man halt noch ein paar Geräte die per WLAN an der 6490 angemeldet waren (.91, .102, .153). .1 u. .254 sind die 6490.

Zusammenfassung: Die Paketverluste treten auf, sobald der Verkehr über den D-Link DGS 1100-24 Switch läuft (habe auch andere Port Kombinationen probiert, verbessert sich aber nicht).

Nur wer ist der Schuldige? (Zur Erinnerung, bei einer 7490 anstatt 6490 konnte ich die Paket-Verluste bisher nicht beobachten!)

PeterPawn · 1 Sep 2016

Kabel event. mal ausgetauscht?

Die 6490 hat natürlich einen anderen internen Switch und (vermutlich) auch andere PHYs ... da kann schon mal beim "auto sensing" etwas daneben gehen. Was passiert denn, wenn die Gechwindigkeit des Ports am Switch geändert wird bzw. der auf feste Einstellungen gesetzt wird (wenn er das kann)?

Solche Probleme beim Zusammenspiel treten ja immer mal wieder auf (irgendein Fernseher wollte vor nicht allzu langer Zeit mal nicht direkt mit der FRITZ!Box reden bzw. es gab dann Probleme beim Streaming, die durch einen zwischengeschalteten Switch verschwanden) ... ohne Protokoll-Analysator, der das richtig "elektrisch" untersucht, wird man nur mit Kreuztests zu einem (wahrscheinlich auch eher unbestimmten) Ergebnis kommen.

odoll · 1 Sep 2016

PeterPawn schrieb:
Kabel event. mal ausgetauscht?

Nein, das Kabel läßt sich nicht so einfach austauschen (habe ich gerade erst - es ist zwar 'nur' 30 m lang, läuft aber durch diverse Schächte und Leerrohre ...)

Die 6490 hat natürlich einen anderen internen Switch und (vermutlich) auch andere PHYs ... da kann schon mal beim "auto sensing" etwas daneben gehen. Was passiert denn, wenn die Gechwindigkeit des Ports am Switch geändert wird bzw. der auf feste Einstellungen gesetzt wird (wenn er das kann)?

Ja, das kann er (und ich kann es auch Remote

)

Wenn ich den Switch Port von Auto fest auf "1000M Full" setze habe ich weiterhin die Paketverluste ("Flow Control" On bringt auch nix).

Gehe ich auf "100M Full" sind die Paketverluste (quasi) 0. Nur ist das keine Lösung, da ja gerade der Router alle im Netz mit 200/20 bedienen soll. (auch die, die nicht direkt dran hängen - auch wenn es wohl sehr selten sein sollte, dass man tatsächlich ein Bottleneck haben wird, nur einbauen will ichs nicht.)

Dann bleibt wohl noch die Option andere GigE-fähige Geräte anstelle der 6490 an der 'Strippe' zu testen und sich dann auf die Quote zu berufen. Oder einen weiteren Gig-E-Switch (davor) auszuprobieren.

PS: zudem muss ich wohl auch noch mit mir ins Reine kommen, ob ich nicht lieber meinen Server von der .254 "vertreibe" und der 6490 gezwungener Maßen den "Vortritt" lasse. Denn soweit ich Deinen Ausführen folgen konnte braucht die (IMO "kranke") Konstruktion der 6490 ja beide IPs um sauber arebiten zu können (auch wenn gar kein NAS Service gebracuht wird, bzw. dieser ausgeschaltet ist.)

PeterPawn · 1 Sep 2016

odoll schrieb:
habe ich gerade erst - es ist zwar 'nur' 30 m lang, läuft aber durch diverse Schächte und Leerrohre

Je nachdem, was "gerade erst" ist, hast Du da eine weitere Änderung (zusätzlich zum Tausch der 7490 gg. die 6490)?

Ist denn wirklich sicher, daß das 30m-Kabel nach dem Neuverlegen absolut in Ordnung ist und danach auch mit GbE/FD funktioniert hat? Jedes automatische "Heruntertakten" durch eines der Geräte an einem Ende des Kabels hätte ja bisher auch Paketverluste vermieden ... wenn man solche Ergebnisse nicht wirklich 100% prüft (was man sicherlich nur dann macht, wenn es Grund zum Mißtrauen gibt), kommen da vielleicht auch falsche Annahmen zum Tragen. Selbst ein Speedtest zum NAS der FRITZ!Box an einem Ende würde sich von "Fast-Ethernet" nur geringfügig ausbremsen lassen, da ist ohnehin bei Geschwindigkeiten Schluß, die sich auf 100 MBit/s-Niveau bewegen.

Sind die Stecker selbst gecrimpt? Hast Du es mal mit einem Kabeltester durchgemessen? Läuft es irgendwo parallel zu einem anderen Kabel (und stimmt die Schirmung nicht), wo es Übersprechen (auf halbwegs passenden Frequenzen oder einer Harmonischen) geben könnte (also ein normales Stromkabel kann da vernachlässigt werden)?

Solange sich der Switch (oder die FRITZ!Box) aufeinander zu bewegen lassen, würde ich mit einem fertig konfektionierten Kabel die Tests noch einmal wiederholen. Oder habe ich das falsch verstanden und die Tests aus #8 waren schon mit einem anderen Kabel?

odoll · 1 Sep 2016

PeterPawn schrieb:
Je nachdem, was "gerade erst" ist, hast Du da eine weitere Änderung (zusätzlich zum Tausch der 7490 gg. die 6490)?

Nein, das 'neue' Kabel (fertig konfektioniert - nichts selbst gecrimpt) liegt schon ein paar Wochen / Monate. Natürlich wurde es während der Arbeiten in der Wohnung meiner Tochter bewegt. (Erinnerung: zurückgetausche 7490 zeigt auch danach nicht diese Paketverluste.) Die aktuelle Änderung betrifft nur in die Installation des UM Kabel-Anschlusses (aber mit dem neuen DS-Lite

habe ich mich noch gar nicht beschäftigt - bzw. habe das DF-GW wieder in den alten Zustand aufgrund der Probleme wieder hergestellt.)

Ist denn wirklich sicher, daß das 30m-Kabel nach dem Neuverlegen absolut in Ordnung ist und danach auch mit GbE/FD funktioniert hat? Jedes automatische "Heruntertakten" durch eines der Geräte an einem Ende des Kabels hätte ja bisher auch Paketverluste vermieden ... wenn man solche Ergebnisse nicht wirklich 100% prüft (was man sicherlich nur dann macht, wenn es Grund zum Mißtrauen gibt), kommen da vielleicht auch falsche Annahmen zum Tragen. Selbst ein Speedtest zum NAS der FRITZ!Box an einem Ende würde sich von "Fast-Ethernet" nur geringfügig ausbremsen lassen, da ist ohnehin bei Geschwindigkeiten Schluß, die sich auf 100 MBit/s-Niveau bewegen.

Sind die Stecker selbst gecrimpt? Hast Du es mal mit einem Kabeltester durchgemessen? Läuft es irgendwo parallel zu einem anderen Kabel (und stimmt die Schirmung nicht), wo es Übersprechen (auf halbwegs passenden Frequenzen oder einer Harmonischen) geben könnte (also ein normales Stromkabel kann da vernachlässigt werden)?

Nein, wie Du schon schreibst, bin hier Privat-Person und verfüge nicht über entsprechendes Equipment um eine 100% Aussage treffen zu können (gibts die Überhaupt).

Solange sich der Switch (oder die FRITZ!Box) aufeinander zu bewegen lassen, würde ich mit einem fertig konfektionierten Kabel die Tests noch einmal wiederholen. Oder habe ich das falsch verstanden und die Tests aus #8 waren schon mit einem anderen Kabel?

Nein, waren sie noch nicht, aber der Test vom PC im Keller direkt über das Kabel bis zur 6490 zeigt ja keine Paket-Verluste, was das Kabel natürlich trotzdem immer noch nicht zu 100% entlastet. Blieben auch noch die Tests die 6490 auch in den Keller zu holen und mit (1) einem ebenso langen Kabel (was ich noch eingeschweißt als Ring in Folie haben sollte) über den Switch zu probieren, bzw. wenn das auch Probleme macht (2) mit einem kurzen über den Switch.

PS: habe mir mal von den Kollegen der "physischen Fraktion" die Kanonen für den Spatzen ausgeliehen

- - - Aktualisiert - - -

OK, die Kanonen haben den Spatz getroffen - heißt wohl mal wieder neues Kabel verlegen ... :-(

PeterPawn · 1 Sep 2016

Ich würde ja eher zur Crimp-Zange greifen ... wo dieses Prüfequipment vorhanden ist, sollte sich so etwas ja auch noch auftreiben lassen.

odoll · 3 Sep 2016

Crimp-Zange ist vorhanden, fragt sich nur auf welchem der 30m Meter wohl der Fehler ist!? (Mag der Analyzer wohl auch beantworten können, habe ihn aber z.Z. nicht im Zugriff.) Ich glaube, da verlege ich leiber neu.
Jemand ne Empfehlung wo man preiswert aber qualitativ OK >= Cat5e Kabel beschaffen kauft?

MuP · 3 Sep 2016

Spitze Winkel beim Verlegen sind vermieden worden (Rundungen sind nicht nur für's Auge wohltuender

) ?

Ansonsten VOR dem Verlegen erst einmal das neue noch zusammengerollte Kabel mit dem Equipment bzgl Losses testen.

odoll · 3 Sep 2016

Genau Letzteres hatte ich vor

djlex1983 · 10 Okt 2016

Halloo

ich hab das gleiche problem mit meiner Fritz 6490. der Fehler besteht unter 6.5 und 6.62 hab beide getestet.
Ich hab statt switch ---> 2x fritz.repeater 1750e über LAN angeschlossen.
Sobald ich die Repeater über LAN and der Fritz.box anschließen und auf 1 Gbit eingestellt ist hab ich Packet Loss.
Wenn die Repeater mit LAN angeschlossen ist und auf 100 Mbit umgestellt ist hab ich keine Packet Loss.
AVM Sagt, es liegt nicht am Ds-Lite.
Das Phänomen verschwindet sobald ich ein Download anschalte und es gedownloadet wird, sind keine Packet Loss da.
Dazu noch, wenn an der Fritz.box per LAN oder WLAN direkt verbunden ist sind keine Packet Loss. Keine Repeater dazwischen.

Ich hab noch dazu das die Repeater die LAN Verbindung zu der Fritz.box sporadisch verlieren.

ich hab auch gedacht das es an meine netzwerkkabel liegt hab aber 2 verschieden Kabel in unterschiedlichen Wohnungen und 2 repeater 1750e getestet und Kabel sind OK.

Avm wertet gerade meine Support Dateien aus wird vielleicht bei der nächsten Update behoben werden.

djlex · 14 Okt 2016

Hallo

Hab jetzt ein LevelOne GSW-0807 dazwischen geschaltet und die Probleme sind weg mit den Ping Aussetzer.

Mit freundlichen Grüssen

djlex · 29 Okt 2016

Hallo

Die neue Firmware ist draussen 6.63 und soll anscheinend die Probleme mit dem Packet Loss behoben worden.

Behoben - Sporadische Linkverluste bei Verwendung bestimmter LAN-Switches

Hat jemand eine Retail Fritzbox um zu testen.

Mit freundlichen Grüssen djlex

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...utsch/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

jojo-schmitz · 2 Nov 2016

Siehe http://www.ip-phone-forum.de/showthread.php?t=286994&page=3&p=2188221&viewfull=1#post2188221, dort mit direktem Link zur Firmware

[Problem] FRITZ!Box 6490 Cable (lgi) 141.06.50 mit Packet-Loss

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

Neuer User

Neuer User

Neuer User

Aktives Mitglied

Statistik des Forums