Fritzbox 7490 Firmware Version 6.20 (vom 12.08.2014)

wir kommen hier OFF-T.
... aber dann habt ihr bisher richtiges was verpasst ;-)

Online-Telefonbücher AVM Wissensdatenbank
gerade in Verbindung mit Smartphones - Top, denn sämtliche Änderung im Smartphone oder bspw. über WebGUI Google sind (spätestens nach 24h) synchron - oder sofortiger Abgleich über Aktualisierung-Button in der F!B.
auch Labels/Kontaktgruppe können geschaffen werden bspw. um privat/geschäft - Telefondaten aus dem Smartphone zu trennen.
ein weiteres Gadget ist, dass jedem Endgerät bspw. ein separates Telefonbuch zugeordnet werden kann

der syn. ist somit auf allen Endgeräten (wenn gewünscht gleich) dh. vom Firmen-Handy, über privates Smartphone oder Tablett bis zu den DECT-Geräte zuhause.

//edit: - Kontakte mit Apple-Geräten synchronisieren
auf iOS-Geräten kann man bspw. google als exchange oder CardDAV anlegen und die Kontakte normal "befüllen". dh. bei mir aktuell iOS, Android, Tab., Desktop/Mail und DECT
keine separate app* sondern lediglich die Basis Kontakt/Mail-Verwaltung von iOS bzw. über WebGUI -
*=als keine Google-Mail-App o.ä. im Einsatz

//edit2:
man sollte icloud deaktivieren und das Telefonbuch sodann auf google "umziehen", sonst kommt ein durcheinander zu Stande.
nach dem Umzug merkt man (meines Erachtens) keinerlei Unterschied wo die Daten geführt/abgeglichen werden.
 
Zuletzt bearbeitet:
gefunden, danke. :D Nur mein Anbieter iCloud fehlt. Dann wäre das perfekt ;)
 
Hat hier schon jemand das marging entschlüsselt bei ADSL?
Ich bekomme einfach keinen snr von 2 oder 3 hin.
Habe schon -1 -2 -3 -4 -5 -6 -7 -8 -12 -30 ausprobiert, es kommt entweder ein 0er snr ein 1er snr oder 6 raus.....
 
WLAN-Durchsatz asymetrisch?

Ich betreibe eine 7490 als IP-Client und AP sowie eine 7390 als Repeater, um eine LAN-Insel (Wohnzimmer, TV, BR, ...) per WLAN ans restliche LAN anzubinden (s. Signatur). Mir ist heute aufgefallen, dass die Transferraten im WLAN total asymetrisch sind. Gemessen hab ich mit "netio" vom Notebook zu einem PC im LAN (GBit-LAN, netio-Server).

Wenn ich mein Notebook per LAN an den Repeater hänge (WLAN aus) oder per WLAN an dem AP anmelde (LAN aus), erreiche ich Transferraten von 8000-11000 kByte/s in Schreibrichtung aber nur 100-150 kBytes/s in Leserichtung. Das reicht natürlich nicht mehr aus, um z.B. "Amazon Instant Video" auf den TV zu streamen. Ich weiss aber, dass das schonmal ging.

Im LAN schafft das Notebook mit seiner 100MBit-Schnittstelle symetrisch 11300-11500 kByte/s.

Ist sonst noch jemand diese Asymetrie bei WLAN aufgefallen? Bisher hatte ich wenig darauf geachtet und weiss daher nicht, seit welcher Firmware das so ist.
 
Dann findet man schnell die "Adresse" der Datei /etc/default/<branding>/ipsec.cfg (ist aber in allen Brandings identisch), in der die möglichen Einträge für phase1ss und phase2ss in "IPSec" übersetzt werden. Das ist auch die richtige Stelle zum Nachschlagen, wenn man schon seitens der Box bestimmte Proposals "erzwingen" will (ich will keine Varianten ohne PFS, das ist aber - wenn ich mich recht entsinne - bei dieser "all/all/all"-Einstellung für phase2ss der Fall).

Oh, vielen Dank! Die Datei kannte ich noch gar nicht. Da gibt es ja wirklich interessante Sachen - wusste z.B. auch nicht, dass es vordefinierte Varianten gibt mit einer Lifetime von 8h. Also jedenfalls läuft das bei mir aktuell sauber mit dh5/aes/sha und strongSwan...
 
Ich betreibe eine 7490 als IP-Client und AP sowie eine 7390 als Repeater, um eine LAN-Insel (Wohnzimmer, TV, BR, ...) per WLAN ans restliche LAN anzubinden (s. Signatur). Mir ist heute aufgefallen, dass die Transferraten im WLAN total asymetrisch sind. Gemessen hab ich mit "netio" vom Notebook zu einem PC im LAN (GBit-LAN, netio-Server).

Wenn ich mein Notebook per LAN an den Repeater hänge (WLAN aus) oder per WLAN an dem AP anmelde (LAN aus), erreiche ich Transferraten von 8000-11000 kByte/s in Schreibrichtung aber nur 100-150 kBytes/s in Leserichtung. Das reicht natürlich nicht mehr aus, um z.B. "Amazon Instant Video" auf den TV zu streamen. Ich weiss aber, dass das schonmal ging.

Im LAN schafft das Notebook mit seiner 100MBit-Schnittstelle symetrisch 11300-11500 kByte/s.

Ist sonst noch jemand diese Asymetrie bei WLAN aufgefallen? Bisher hatte ich wenig darauf geachtet und weiss daher nicht, seit welcher Firmware das so ist.

Fällt auch in diesen Bereich: http://www.ip-phone-forum.de/showthread.php?t=271895&p=2025954&viewfull=1#post2025954
 
@ ta99: Bitte keine Monstervollzitate und dann eine Mini-Information...
Statt des Zitats hätte die Überschrift WLAN-Durchsatz asymetrisch? gereicht...
 
Ich habe hier ein SEHR seltsames Verhalten mit IPv6 und der Firmware version 6.20 auf der FB7490

Die FB7490 ist an einem IP basierten, Splitterlosen IPv4 Anschluss der Telekom.
Um IPv6 Konnektivität zu bekommen benutze ich einen SiXXs Tunnel in der FB7490, den man dort in der Oberfläche einstellen kann.
Ich benutze ssh über IPv6 um von einer lokalen Maschine auf einen Server bei Hetzner zu kommen. Der Server bei Hetzner hat natives IPv6.

Nun habe ich das Problem dass meine SSH Verbindung immer mal wieder 'hängt', sich nach 'gefühlten' 2-10 Sekunden aber wieder fängt.

Daraufhin habe ich versucht herauszufinden woran es liegen könnte:
- Eine zweite SSH Verbindung zum gleichen Server hängt nicht während der Zeit in der die erste Verbindung hängt.
- Eine SSH Verbindung die ich mit "ssh -o ServerAliveInterval=1 server" starte, bricht nach 10-200 Sekunden ab.
- Wenn ich einen 6-4 Tunnel auf der Fritzbox auswähle, statt dem SiXXs Tunnel, habe ich weiterhin das gleiche Problemverhalten.
- Wenn ich mir mit tcpdump die Pakete ansehe, sehe ich dass die auf dem lokalen Host rausgehen, aber nicht auf dem Remote Server ankommen.
- Zwischen Hosts im lokalen Netzwerk (ich habe nur Zwei mit IPv6) funktioniert SSH
- Vom zweiten Host im lokalen Netzwerk oder von einer Linux VM im lokalen Netzwerk zum Remote Server habe ich das gleiche Problemverhalten.
- Von einem dritten Host von einem Freund mit einem anderen VDSL Anschluss funktioniert die Verbindung Server problemlos.
- Wenn ich in einer lokalen VM die via NAT eingebunden ist einen AICCU Tunnel aufbaue, funktioniert die Verbindung.

Für mich sieht es so aus, als wenn die Fritzbox irgendwas seltsam beim IPv6 Tunneln macht, da ich das Problemverhalten ja sowohl beim SiXXs Tunnel als auch beim 6-4 Tunnel der Fritzbox habe.


Hat irgendjemand eine Idee ?
Ich überlege auf der Fritzbox mal Freetz zu installieren um AICCU auf der Fritzbox auszuprobieren.
 
Ich dachte an nem IP basierten Telekom Anschluss bekommt man nativ IPv6?
 
@Tuffi Leider ist der Vertrag so alt, dass ich noch kein IPv6 nativ bekomme. Allerdings gibt es in 'nem Monat eine Vertagsumstellung, dann sollte ich IPv6 nativ bekommen.
 
Hat irgendjemand eine Idee ?
IPv4 geht es ohne ähnliche Probleme ? Deiner Schilderung kann ich nicht klar entnehmen, ob es mit IPv6 nur bei SSH auftritt oder auch bei anderen Protokollen.

Ich hatte mal für SSH einen QoS-Classifier eingerichtet (unter Priorisierung, ich hasse es bei Last "blind" zu tippen), der bewirkte manchmal das glatte Gegenteil, wenn da den ausgehenden Paketen QoS/ToS-Tags hinzugefügt wurden, die unterwegs für Verwirrung sorgten. Und die 2-10 Sekunden wären für mich plausibel bei einem "resend", entweder weil da ein "reject" irgendwo unterwegs erfolgte oder schlicht ein TO beim Warten auf das ACK.

[EDIT]Und daß es im Tunnel, wenn die Box die Daten selbst nicht "sieht", ohne Probleme läuft, spricht in meinen Augen auch für meine These ... das hatte ich glatt vergessen zu bemerken.[/EDIT]

Eine "Netzwerkanwendung" (also ein Filter) für "SSH" müßte eigentlich ooB schon in der Firmware sein, vielleicht greift ja inzwischen noch irgendein anderer "Standard" beim tc. Die ganze Klassifizierung an sich läuft ja wohl im kdsld und ist eher etwas undurchsichtig für mich.

Heißt Deine Angabe beim tcpdump eigentlich, daß die Pakete aus dem SSH-Client-Host rausgehen oder aus der FRITZ!Box ? Haben die seitens der FRITZ!Box irgendwelche ToS/QoS-Tags, wenn sie auf die Reise geschickt werden ?

Bei mir (6to4 bei fester IPv4) habe ich das Problem beim SSH-Zugriff mit IPv6 auf STRATO jedenfalls wohl nicht, getestet mit OpenSSH und häufigen Alive-Paketen wie in Deiner Schilderung, ansonsten etwas schlecht zu testen/beurteilen. Beim normalen Tippen im vi oder so fällt mir ansonsten aber so ein delay schon unangenehm auf, wenn vielleicht gerade mal wieder im WLAN "kein Platz" ist für 1-3 Sekunden oder irgendwas mit "eco" greift.
 
Zuletzt bearbeitet:
Also mein Server ist via IPv4 nicht erreichbar. Ich habe aber gerade Zugriff zu einem anderen Server via IPv4 (der hat leider kein IPv6) und da steht die Verbindung problemlos über 10 Minuten. Wie gesagt mit einem "ssh -o ServerAliveInterval=1 server" ist sonst schon schnell Schluss. Sonst habe ich mit IPv6 Webseiten bisher keine Probleme gehabt. Was sonst so mein Rechner noch IPv6 mässig macht ist mir nicht wirklich bewusst.

Ich habe bei der Priorisierung der Protokolle ein paar hinzugefügt ( FaceTime und Skype realtime, btsync niedrige Priorität ), aber das nur in der Fritz Oberfläche. Keine Ahnung ob dann QoS gemacht wird o.ä.
Ich denke auch nicht, dass es ein Priorisierungsproblem ist, da auf der Leitung sonst nichts los ist. Also GAR nichts sonst. Ausser das QoS der Fritzbox ist total f***ked-up.

Ich hatte die Box nicht gefreetzed, daher konnte ich auch keinen tcpdump auf der Box laufen lassen. Ich habe den tcpdump bisher nur auf dem lokalen Rechner und dem remote Server laufen lassen. Man hat genau gesehen, dass er die Pakte retransmittet hat, nicht nur einmal sondern gleich mehre Male, jedoch ist erst nach ein paar Sekunden ( bit zu 10s !! ) dann erst mal wieder ein ACK gekommen.

Ich bin jedoch gerade dabei die box zu freetzen und werde mir das dann auf der Box nochmals ansehen.

Ja das mit der Verzögerung im vi auf der Shell ist genau das was mich hier nachprüfen lässt - deswegen verwende ich auch kein WLAN - alles nur wired. Ach ja, ich habe einen managed Switch (sg300-10 [wegen igmp sniffing]), weshalb ich auch ausschliessen kann das Pakete auf dem Ethernet liegen bleiben. Die Fritz DSL Verbindung hat auch keinerlei Fehler.
 
Zuletzt bearbeitet:
Ich denke auch nicht, dass es ein Priorisierungsproblem ist, da auf der Leitung sonst nichts los ist. Also GAR nichts sonst.
Ich meinte auch nicht, daß das Paket wegen Überlastung der Leitung nicht durchgeht. Ich dachte mehr an einen Router im Weg zum Server, der mit den QoS/ToS-Flags nichts anfangen kann oder die als "schmeiß weg, wenn Du zuviel zu tun hast, aber sag mir Bescheid" interpretiert und dann wirklich mal was wegwerfen muß.

Ich hatte die Box nicht gefreetzed, daher konnte ich auch keinen tcpdump auf der Box laufen lassen.
Die Box kann selbst einen Wireshark-kompatiblen Dump produzieren, sogar auf dem externen Interface. Guckst Du unter "Inhalt/FRITZ!Box-Support/Paketmitschnitt" ...

Wenn Du den Tunnel nicht unbedingt brauchst, kannst Du Dir das Freetzen auch schenken. Das Reaktivieren der debug.cfg (so Dein Wunsch im anderen Thread) benötigt nur das Entpacken, Modifizieren der rc.tail.sh (ich glaube, er13 hat dazu irgendwo einen Patch eingebaut, den kann man natürlich auch direkt auf die entpackten Dateien anwenden) und anschließendes Einpacken. Alles andere, was einen Freetz-Mod sonst noch ausmacht, braucht man nur, wenn man auch das entsprechende GUI von Freetz für irgendetwas verwenden will (oder bestimmte Pakete auf die Konfigurationsschnittstelle von Freetz zugreifen, wobei die dann i.d.R. auch das GUI wollen).

Du könntest also mit 3 Kommandos (fwmod -u, patch, fwmod -p) ein eigenes Image vollkommen ohne Freetz bauen. Das meint "ohne Freetz im Image", nicht "ohne den Freetz-Trunk" mit den ganzen Goodies.
 
Zuletzt bearbeitet:
Habe mal die Box ge-Freetzt. Aiccu habe ich leider nicht zum laufen bekommen, irgendwie ist das Freetz wohl momentan kaputt. Aber zumindest habe ich nun tcpdump und das ausprobiert.
Allerdings ist der output auf der Fritzbox irgendwie total wenig im Verhältnis zu meinem Rechner interface. Ich habe beide Dumps mal mitgelogged.

Werde das mit dem mitschneiden auf der fritzbox mal ausprobieren. Danke für den tip @PeterPawn.


Anhang anzeigen localcomputer.tcpdumpout.txt
Anhang anzeigen fritzbox.tcpdumpoutput.txt

update:
Hmm ich habe jetzt 'ne halbe Stunde das Internet mitschneiden lassen von der Fritzbox ( http://fritz.box/capture.lua ) und NICHTs ist abgebrochen.
Dann habe ich den Packetmitschnitt auf der Box beendet und keine Minute später ist die Verbindung abgebrochen. Scheint ein Heisenbug zu sein. Werde es trotzdem nochmal ausprobieren.

update2:
Weitere 100 Minuten später ist eine neue Verbindung immer noch nicht abgebrochen während ich den Packetmitschnitt laufen lasse. Ich gehe immer noch von einem Heisenbug aus. Anschauen lässt den Fehler verschwinden. Aber zumindest ist nun klar das es ein Fehler in der Box ist, der mit dem Tunnel zu tun hat.

update3: habe den zweiten Mitschnitt nach 100Minuten abgebrochen und keine 3 Minuten später ist die Verbindung zusammengebrochen.

Schade nur, dass ich jetzt den Bug AVM nicht melden kann, weil ich ja die Box 'modifiziert' habe.
 
Zuletzt bearbeitet:
Schade nur, dass ich jetzt den Bug AVM nicht melden kann, weil ich ja die Box 'modifiziert' habe.
Welchen Teil der Modifikation (debug.cfg mal außen vor) brauchst Du denn eigentlich ? Wenn ich es richtig verstanden habe, hast Du nur aiccu versucht, es läuft aber nicht, ansonsten hast Du keine Pakete installiert. Was hält Dich denn jetzt davon ab, die Box per Recovery wieder auf den Originalstand zu setzen und dann - sollte er sich reproduzieren lassen - den Fehler doch an AVM zu melden ?

Anschließend kannst Du ja immer noch ein Image mit der debug.cfg-Modifikation (und nur dieser) wieder einspielen, freetz-mod brauchst Du doch wohl nicht wirklich im Image.
 
Hallo Peter Pawn,
wo gibts die debug.cfg-Modifikation (mit der diese wieder abgespielt werden kann?
Ich dachte das gibts nur bei freetz??
Ich wollte gerne die debug wieder abspielen, aber ohne Freetz.

Gruß

Seme
 
Je mehr ich mich mit dem WLAN der 7490 unter 6.20 beschäftige, umso furchtbarer wird es.

Durch die asymmetrischen Übertragungungsraten bleiben von meinem 16MBit/1MBit-DSL-Anschluss für die WLAN-Clients nach extern gerade mal 1MBit/1MBit übrig, selbst wenn ich meinen PC mit einem AVM 430 AC Stick bestücke und angeblich mit 433MBit verbunden bin. WLAN ist so höchstens zum Surfen zu gebrauchen.

Ok, ich benutze eine 7490 im IP-Client-Mode als AP. Die Router-7490 im Keller ist auf Grund ihrer Lage nicht als AP zu gebrauchen. Das mag anders sein, als bei vielen anderen, hat aber bislang immer prima funktioniert.

Bin ich hier wirklich der einzige mit diesem Problem?
 
@Seme: Sieh mal hier nach.

Könnt ihr das bestätigen?
Ich bin etwas verwirrt. Meinst Du nun, das Anstoßen des Wählvorgangs über ctlmgr_ctl geht auch nicht mehr oder willst Du auf das fehlende nc in der busybox hinaus ?

Das fehlt meines Wissens schon seit geraumer Zeit in der Busybox von AVM, bei der 7390 mindestens seit der 06.03.

Mit der Wählhilfe über den ctlmgr scheint es ja noch zu gehen, der andere Thread ist ja von gestern.

EDIT: Gerade habe ich noch einmal in der 06.05 für die 7490 nachgesehen, da war auch kein 'nc'-Applet in der AVM-Busybox.
 
Zuletzt bearbeitet:
Ich hab keine 7490, in der FW 6.03 meiner 7360SL ist nc/netcat noch drinne.
In der FW 6.05 meiner 7270v2 auch.

Naja, sorry, dann ists eine Ente.

Code:
ctlmgr_ctl w telcfg command/Dial **9
...funktioniert prächtig.
 
Zuletzt bearbeitet:

Neueste Beiträge

Statistik des Forums

Themen
246,067
Beiträge
2,245,478
Mitglieder
373,504
Neuestes Mitglied
andkel
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.