Firmware: FRITZ!OS 05.22 6360

[spooky]

Probiert mal folgendes, so habe ich es vorhin bei meiner Schwester gemacht:

Netzstecker ziehen, kurz warten, Netzstecker wieder einstecken.
Sollte die Info Lampe jetzt nicht anfangen zu blinken über die Weboberfläche auf System --> Zurücksetzen und dann den Button "Neu starten" anklicken.

Dann hat sich die Box die 5.22 gezogen

[norbert.s]

Habe nur über die Weboberfläche auf System/Zurücksetzen/Neu starten ausgeführt und schon kam die 5.22 (in München) angeflattert.

Servus

[4xxxx]

Im Raum Saarland tut sich auch nach Stecker ziehen, manuellem Reboot noch nix

[redskin]

moin,
hier ändert sich auch nichts... Interessieren würde mich mal, wie die das machen, würfeln die bei KD morgens, wer dran ist?
Fühle mich ein wenig von diesem Verein veralbert, selbst Beschwerdemanagement hat hier nicht geholfen...
Naja, die 2 Jahre sind ja auch mal rum, man lernt ja dazu...
Dachte eigentlich , das man o2 nicht toppen kann...

[njxhyrmq2]

Hallo,

ich bin auf der Suche nach einer Lösung für die Problematik ein IP-Telefon (Anwendung auf Rechner sowie Android) mit der FritzBox6360 zu koppeln auf die Firmware 85.05.22 und somit dieses Forum gestoßen.
Nachdem hier einige Fehlerbilder beschrieben wurden, möchte ich auch meine Erfahrungen schildern.

Topologie:
Ein iMac (Snow Leopard) greift über WLAN (5GHz, 802.11n) durch die FB6360 (Firmware 85.05.09) auf Internet zu. Ein iPad nutzt das selbe 5GHz-WLAN und über einen weiteren WLAN-AP (2,4Hz) greifen andere Endgeräte auf das Internet zu. Provider ist Unitymedia (32Mbps Downstrem, 1Mbps Upstream). Es gibt kein zweites WLAN im 5GHz-Band (Störquelle) in meiner Umgebung.

Nachdem ich gelesen habe, dass z.B. beim starten mehrerer Downloads die Übertragungsrate einbricht, habe ich das geprüft (bevor ich meinen Provider um die neue Firmware bitte, wollte ich den aktuellen Status dokumentieren).

Der Test sah wie folgt aus:
1. Starten von zwei gleichzeitigen Downloads (Win8 von MS-Server in 64- und 32-Bit-Version)
2. nebenher beobachten des "Mäusekinos" (Durchsatzdiagramm in FB-Oberfläche)
3. ansurfen verschiedener Website (Web-Mail, Heise, Google-Suchen)
4. meine Frau hat nebenher ein Telefongespräch geführt (fast über die gesamte Download-Dauer)
5. Starten eines dritten Downloads (Ubuntu) nachdem die anderen beiden halb durch waren

Ergebnisse:
- die beiden Win8-Downloads haben eine Übertragungsrate von 1,9MB/s und 1,8MB/s (= 3,7MB/s = 29,6 Mbps)
- meine Frau hat keine Probleme bei der Sprachqualität feststellen können (RTP-Stream in UDP eingepackt, QoS wahrscheinlich EF)
- das parallele surfen war sehr flüssig
- der Graph der Durchsatzanzeige war relativ gleichmäßig (minimale Schwankungen zwischen 31 und 32 Mbps)
- der dritte Download (Ubuntu) lief ebenfalls recht gleichmäßig

Der Durchsatz für die Downloads ist sehr gut, da der Overhead (TCP-, IP- und Anwendungs-Header) im Downloadmanager nicht eingerechnet wird. Da die beiden Win8-Downloads von der gleichen Quelle (MS-Serverfarm) stammen, könnten beide TCP-Sessions aufeinander "abgestimmt" sein, statt miteinander um Bandbreite zu konkurrieren (je nachdem wie MS seine Netzkomponenten optimiert hat.)
Die angesurften Web-Seiten und der dritte Download kommen jedoch nicht aus der MS-Serverfarm - somit sollten sie Einfluss auf die ersten beiden TCP-Sessions (Win8-Downloads) haben.

Ich vermute, dass das Problem in der Hardware-Architektur der FB6360 liegt und deshalb bei Kabelanschlüssen mit höheren Bandbreiten stärkere Auswirkungen hat:
Der Paketstrom aus verschieden TCP-Sessions kommt an der WAN-Schnittstelle (Kabelanschluss der FB) an muss entpackt und für das WLAN neu in 802.11-Frames eingepackt werden. Die Fritzbox schafft das bis zu einer gewissen Bandbreite recht gut, danach füllt sich der Eingangspuffer und die Pakete die nicht mehr in den Puffer passen werden verworfen. Somit gehen einige TCP-Segment verloren und müssen erneut übertragen werden, der Effekt der TCP-Synchronisation (Sägezahnmuster) kommt dazu und alle TCP-Sessions (Downloads etc.) übertragen nur noch mit einem Bruchteil der möglichen Bandbreite… (Das Verhalten kann bei verschiedenen Betriebssystemen bzw. TCP/IP-Stacks auf den Endgeräten unterschiedlich sein!)

Eventuell haben auch Störquellen in den WLAN-Frequenzbändern einen ähnlichen Effekt, da auch hier einzelne Frames wiederholt werden müssen. (Zeigt euch die Fritzbox ja an…) Deshalb könnte der Anschluss der PCs etc. per (Twisted-Pair-)LAN weniger Performance-Probleme verursachen. Vielleicht fällt es der Fritzbox auch einfach nur "leichter" Ethernet-Frames zu bauen (weniger CPU-intensiv?)...

!! Das sind meine Feststellungen und Vermutungen. Ich arbeitet weder für einen Kabelnetzbetreiber noch für AVM. !!

Mein Vorschlag:

Erstellt doch mal eine Übersicht, in der die Bandbreite am Kabelanschluss, die Firmware, die (W)LAN-Schnittstelle (TP; 2,4GHz; 5GHz) und eventuell genutzte FB-Dienste (Dateifreigabe, AB …) und die aufgetretenen Probleme dargestellt sind. Vielleicht lässt sich hieraus ein Muster ableiten und somit ist für jeden einfach zu bestimmen, ob die FB6360 für seine Wünsche geeignet ist oder nicht.

Hat jemand auch einen 32Mbps-Anschluss und kann meine Erfahrungen bestätigen?

[Siegel]

• Anschlussvertrag: KD Business 100
• mitgeliefertes Gerät: FRITZ!Box 6360 Cable (kdg)
• Geräteversionsnummer: ???
• Firmware: FRITZ!OS 05.22

• Internet: IPv4
• Telefonie: 3 Rufnummern aktiv
• VPN: 1 aktive Verbindung
• Anschlüsse
• Kabel: bereit, 106,0 Mbit/s 6,4 Mbit/s
• LAN: verbunden (LAN 1, LAN 2)
• WLAN: aus
• DECT: aus
• USB: 1 Speicher

• Komfortfunktionen
• Anrufbeantworter: aktiv
• Speicher (NAS): 44 MB genutzt, 3.7 GB Frei (NTFS USB Stick)
• Faxempfang: Integrierter Empfang aktiv
• Portfreigabe: aktiv, 2 Portfreigaben eingerichtet / Exposed Host: 192.168.253.10
• Info-Anzeige: leuchtet bei Internetverbindung
• Fernwartung: https://subdomain.meinedomain.tld:Port,Benutzer:...
• Dynamic DNS: angemeldet, subdomain.meinedomain.tld
• Push Service: tägliche Informationen per E-Mail

• Netzwerk
• airport2ipv6 LAN
• airport2ipv4-vpn-sun-sc LAN
• Filter - Kindersicherung - alle uneingeschränkt
• Priorisierung - Echtzeitanwendungen
• automatisch: Internettelefonie
• automatisch: FRITZ!Media Videostreaming
• Priorisierung - Priorisierte Anwendungen
• keine
• Priorisierung - Hintergrundanwendungen
• keine

• Freigaben - Portfreigaben
• aktiv XBox-Live TCP 3074 XBox360 3074
• aktiv XBox-Live UDP 3074 XBox360 3074
• aktiv Exposed Host alle anderen Ports airport2ipv6

Probleme: derzeit keine

[kolossboss]

Hallo njxhyrmq2

die Probleme mit Verbindungsabbrüchen im WLAN, sind bei mir erst mit 85.05.21/22 aufgetreten.
Außerdem lastest du die WLAN-Verbindung mit 32Mbit nicht aus. Wenn ich meine Downloadgeschwindigkeit drossel(z.B. Downloadmanager), habe ich auch keine Probleme.
Da aber meine 100Mbit Leitung nahezu gleichzusetzen ist mit dem maximalen Durchsatz eines 300Mbit WLAN, laste ich, bei einem Download die WLAN Verbindung komplett aus und dann gibs Probleme. Aber NUR mit dem WLAN der 6360.

Hast du die Win8 von MS-Server in 64- und 32-Bit-Version mit deinem iMac runtergeladen, oder mit irgendeinem Rechner der an einem AP hängt? APs machen bei mir auch keine Probleme.

[crazydog76]

Habe jetzt mal das LAN Kabel angeschlossen, damit bricht kein download mehr ab.

Also scheint es wohl am W-lan zu liegen.

Software ist mittlerweile auch 05.22


Jetzt mal was anderes:

Wann ist die Schmerzgrenze beim download bei KD erreicht?
Habe gestern knappe 100GB geladen. Ich denke mal das man sich das nicht täglich erlauben kann!!!
Hat da jemand Erfahrung mit?

[njxhyrmq2]

Hallo kolossboss,

die Downloads und sämtliche anderen Aktivitäten (außer das Telefonat, dass lief über ein am S0-Bus angeschlossenes ISDN-Telefon) wurden vom Mac (also über 5GHz-WLAN) durchgeführt.

Da die Gigabit-LAN-Schnittstellen der FB6360 den Traffic schneller loswerden und wahrscheinlich auch einen, für ihren Durchsatz passenden, Interface-Puffer haben, scheint sich die Vermutung, dass die FB bei hohen Kabel-Bandbreiten in Kombination mit WLAN die Probleme bekommt weil sie die Pakete aus dem Internet nicht schnell genug weiterleiten kann, zu bestätigen.

Wie sind denn die Access-Points / zusätzlichen FBs bei euch an die FB6360 angeschlossen (100M- oder Gigabit-LAN?).

[Siegel]

@njxhyrmq2

Wenn ich mir das so durchlese wird es wohl mal Zeit etwas ausgiebigere Don't Fragment-Bit im IP-Header / Größe des Pakets etc. Tests zu fahren ...

auf nem Mac:

Code: Alles auswählen

MacWorkstation2:~ Root$ ping -D -s 1458 heise.de
PING heise.de (193.99.144.80): 1458 data bytes
1466 bytes from 193.99.144.80: icmp_seq=0 ttl=249 time=24.824 ms
1466 bytes from 193.99.144.80: icmp_seq=1 ttl=249 time=25.161 ms
1466 bytes from 193.99.144.80: icmp_seq=2 ttl=249 time=26.460 ms
1466 bytes from 193.99.144.80: icmp_seq=3 ttl=249 time=25.168 ms
1466 bytes from 193.99.144.80: icmp_seq=4 ttl=249 time=24.121 ms
1466 bytes from 193.99.144.80: icmp_seq=5 ttl=249 time=24.948 ms
1466 bytes from 193.99.144.80: icmp_seq=6 ttl=249 time=25.789 ms
1466 bytes from 193.99.144.80: icmp_seq=7 ttl=249 time=24.628 ms
^C
--- heise.de ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 24.121/25.137/26.460/0.671 ms
MacWorkstation2:~ Root$

PS: Das maximale was wohl sauber durchgehen sind: MTU 1500 minus 20 Bytes IP-Header (=1480 Bytes) minus 8 Bytes ICMP-Header = 25152 Bytes da Inital-Paket mit 16 Fragmenten (17 × 1480 = 25160 Byte)

Also ein ping -D -s 1472 heise.de geht gut durch ...

Interessant wird an dieser Stelle:

net.inet.ip.maxfragsperpacket

Code: Alles auswählen

MacWorkstation2:~ Root$ sysctl net.inet
net.inet.ip.portrange.lowfirst: 1023
net.inet.ip.portrange.lowlast: 600
net.inet.ip.portrange.first: 49152
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.hifirst: 49152
net.inet.ip.portrange.hilast: 65535
net.inet.ip.forwarding: 0
net.inet.ip.redirect: 1
net.inet.ip.ttl: 64
net.inet.ip.rtexpire: 2400
net.inet.ip.rtminexpire: 10
net.inet.ip.rtmaxcache: 128
net.inet.ip.sourceroute: 0
net.inet.ip.intr_queue_maxlen: 50
net.inet.ip.intr_queue_drops: 0
net.inet.ip.accept_sourceroute: 0
net.inet.ip.keepfaith: 0
net.inet.ip.gifttl: 30
net.inet.ip.subnets_are_local: 0
net.inet.ip.mcast.maxgrpsrc: 512
net.inet.ip.mcast.maxsocksrc: 128
net.inet.ip.mcast.loop: 1
net.inet.ip.check_route_selfref: 1
net.inet.ip.use_route_genid: 1
net.inet.ip.dummynet.hash_size: 64
net.inet.ip.dummynet.curr_time: 0
net.inet.ip.dummynet.ready_heap: 0
net.inet.ip.dummynet.extract_heap: 0
net.inet.ip.dummynet.searches: 0
net.inet.ip.dummynet.search_steps: 0
net.inet.ip.dummynet.expire: 1
net.inet.ip.dummynet.max_chain_len: 16
net.inet.ip.dummynet.red_lookup_depth: 256
net.inet.ip.dummynet.red_avg_pkt_size: 512
net.inet.ip.dummynet.red_max_pkt_size: 1500
net.inet.ip.dummynet.debug: 0
net.inet.ip.fw.enable: 1
net.inet.ip.fw.autoinc_step: 100
net.inet.ip.fw.one_pass: 0
net.inet.ip.fw.debug: 0
net.inet.ip.fw.verbose: 0
net.inet.ip.fw.verbose_limit: 0
net.inet.ip.fw.dyn_buckets: 256
net.inet.ip.fw.curr_dyn_buckets: 256
net.inet.ip.fw.dyn_count: 0
net.inet.ip.fw.dyn_max: 4096
net.inet.ip.fw.static_count: 1
net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_keepalive: 1
net.inet.ip.maxfragpackets: 1024
net.inet.ip.maxfragsperpacket: 128
net.inet.ip.maxfrags: 2048
net.inet.ip.scopedroute: 1
net.inet.ip.check_interface: 0
net.inet.ip.linklocal.in.allowbadttl: 1
net.inet.ip.random_id: 1
net.inet.ip.maxchainsent: 0
net.inet.ip.select_srcif_debug: 0
net.inet.icmp.maskrepl: 0
net.inet.icmp.icmplim: 250
net.inet.icmp.timestamp: 0
net.inet.icmp.drop_redirect: 0
net.inet.icmp.log_redirect: 0
net.inet.icmp.bmcastecho: 1
net.inet.igmp.recvifkludge: 1
net.inet.igmp.sendra: 1
net.inet.igmp.sendlocal: 1
net.inet.igmp.v1enable: 1
net.inet.igmp.v2enable: 1
net.inet.igmp.legacysupp: 0
net.inet.igmp.default_version: 3
net.inet.igmp.gsrdelay: 10
net.inet.igmp.debug: 0
net.inet.tcp.rfc1323: 1
net.inet.tcp.rfc1644: 0
net.inet.tcp.mssdflt: 512
net.inet.tcp.keepidle: 7200000
net.inet.tcp.keepintvl: 75000
net.inet.tcp.sendspace: 65536
net.inet.tcp.recvspace: 65536
net.inet.tcp.keepinit: 75000
net.inet.tcp.v6mssdflt: 1024
net.inet.tcp.log_in_vain: 0
net.inet.tcp.blackhole: 0
net.inet.tcp.delayed_ack: 3
net.inet.tcp.tcp_lq_overflow: 1
net.inet.tcp.recvbg: 0
net.inet.tcp.drop_synfin: 1
net.inet.tcp.reass.maxsegments: 2048
net.inet.tcp.reass.cursegments: 0
net.inet.tcp.reass.overflows: 0
net.inet.tcp.slowlink_wsize: 8192
net.inet.tcp.maxseg_unacked: 8
net.inet.tcp.rfc3465: 1
net.inet.tcp.rfc3465_lim2: 1
net.inet.tcp.rtt_samples_per_slot: 20
net.inet.tcp.recv_allowed_iaj: 5
net.inet.tcp.acc_iaj_high_thresh: 100
net.inet.tcp.rexmt_thresh: 2
net.inet.tcp.path_mtu_discovery: 1
net.inet.tcp.slowstart_flightsize: 1
net.inet.tcp.local_slowstart_flightsize: 8
net.inet.tcp.tso: 1
net.inet.tcp.ecn_initiate_out: 0
net.inet.tcp.ecn_negotiate_in: 0
net.inet.tcp.packetchain: 50
net.inet.tcp.socket_unlocked_on_output: 1
net.inet.tcp.rfc3390: 1
net.inet.tcp.min_iaj_win: 4
net.inet.tcp.acc_iaj_react_limit: 200
net.inet.tcp.sack: 1
net.inet.tcp.sack_maxholes: 128
net.inet.tcp.sack_globalmaxholes: 65536
net.inet.tcp.sack_globalholes: 0
net.inet.tcp.minmss: 216
net.inet.tcp.minmssoverload: 0
net.inet.tcp.do_tcpdrain: 0
net.inet.tcp.pcbcount: 58
net.inet.tcp.icmp_may_rst: 1
net.inet.tcp.strict_rfc1948: 0
net.inet.tcp.isn_reseed_interval: 0
net.inet.tcp.background_io_enabled: 1
net.inet.tcp.rtt_min: 100
net.inet.tcp.rexmt_slop: 200
net.inet.tcp.randomize_ports: 0
net.inet.tcp.newreno_sockets: 46
net.inet.tcp.background_sockets: 0
net.inet.tcp.tcbhashsize: 4096
net.inet.tcp.background_io_trigger: 5
net.inet.tcp.msl: 15000
net.inet.tcp.max_persist_timeout: 0
net.inet.tcp.always_keepalive: 0
net.inet.tcp.timer_fastmode_idlemax: 20
net.inet.tcp.broken_peer_syn_rxmit_thres: 7
net.inet.tcp.tcp_timer_advanced: 0
net.inet.tcp.tcp_resched_timerlist: 2024
net.inet.tcp.pmtud_blackhole_detection: 1
net.inet.tcp.pmtud_blackhole_mss: 1200
net.inet.tcp.timer_fastquantum: 100
net.inet.tcp.timer_slowquantum: 500
net.inet.tcp.win_scale_factor: 3
net.inet.tcp.in_sw_cksum: 2939
net.inet.tcp.in_sw_cksum_bytes: 118637
net.inet.tcp.out_sw_cksum: 0
net.inet.tcp.out_sw_cksum_bytes: 0
net.inet.tcp.sockthreshold: 64
net.inet.tcp.bg_target_qdelay: 100
net.inet.tcp.bg_allowed_increase: 2
net.inet.tcp.bg_tether_shift: 1
net.inet.tcp.bg_ss_fltsz: 2
net.inet.udp.checksum: 1
net.inet.udp.maxdgram: 9216
net.inet.udp.recvspace: 42080
net.inet.udp.in_sw_cksum: 85
net.inet.udp.in_sw_cksum_bytes: 1936
net.inet.udp.out_sw_cksum: 0
net.inet.udp.out_sw_cksum_bytes: 0
net.inet.udp.log_in_vain: 0
net.inet.udp.blackhole: 0
net.inet.udp.pcbcount: 72
net.inet.udp.randomize_ports: 1
net.inet.ipsec.def_policy: 1
net.inet.ipsec.esp_trans_deflev: 1
net.inet.ipsec.esp_net_deflev: 1
net.inet.ipsec.ah_trans_deflev: 1
net.inet.ipsec.ah_net_deflev: 1
net.inet.ipsec.ah_cleartos: 1
net.inet.ipsec.ah_offsetmask: 0
net.inet.ipsec.dfbit: 0
net.inet.ipsec.ecn: 0
net.inet.ipsec.debug: 0
net.inet.ipsec.esp_randpad: -1
net.inet.ipsec.bypass: 0
net.inet.ipsec.esp_port: 4500
net.inet.raw.maxdgram: 8192
net.inet.raw.recvspace: 8192
MacWorkstation2:~ Root$

ping -D -s 1472 heise.de geht auch sauber beim MacBook mit WLAN ...

(vielleicht probiere ich später mal das WLAN der FritzBox)

Egal ...