[Gelöst] Fritbox 7270 kein TrafficShaping? Download bricht bei Upload extrem ein

Hi,

sehr gut. Das war es. Habe nun mal "Surfen" in die Echtzeitanwendung geworfen und nun sieht man, dass die ACK-Pakete vom Download als Echtzeit durchgehen. Ich frage mich, warum dies nicht mit priorisierten Anwedungen klappt. Man lernt nie aus :-D. Kann ich auch nur bestimmte Ports priorisieren? Habe dort nur eine definierte Vorauswahl von Surfen, HTTP/FTP-Server und noch ein paar weitere.

Kommst du von der Gegend hier, dass du die 2 Dörfer gleich erkannt hast? ;-) ... ich habe das falsch als 16.000 benannt, sollte 16.000+ heißen. Eine Verfügbarkeitsprüfung bei der Lehrhalde oben ergbit bei mir zwar auch 16.000, aber kein Entertain. Unten Richtung Schillerstrasse habe ich jetzt nicht mehr geschaut. Scheinbar sind die Karten nicht aktuell, da ich bereits noch 2 Dörfer mit VDSL gefunden habe, die aber laut der Karte ein weißer Fleck in der Landschaft sind.

Gruß Coffeemaker
 
Seltsam, dass es bei Echtzeitanwendungen geht.

Such mal bei dir nach
Code:
{
                enabled = yes;
                with_sfq = yes;
                type = qos_cfg_system;
                name = "important";
                iface = qos_wan;
                queue_type = queue_llq;
                precedence = 100;
                weight = 90;
                shapingrate = 0;
                shapingburst = 0;
                allow_more = yes;
                ceilrate = 0;
        }
Steht da eventuell bei enabled no oder sowas in der Art?
Du kannst auch einzelne Ports priorisieren, schau mal hier http://www.avm.de/de/Service/FAQs/FAQ_Sammlung/15208.php3
Poste hier auf jedenfall das Ergebnis (bzw. eine Zusammenfassung dessen) was AVM dir zu dem Problem schreibt.

Die Lehrhalde 2 ergibt bei mir Entertain. Die VDSL Verfügbarkeit auf der Karte hinkt sehr hinterher, da hat die Telekom größere Probleme. Ich komme nicht aus der Gegend. Ein ausgiebiger Blick auf den Karten-Ausschnitt hat mir die nötigen Suchbegriffe verraten. Die Telekom baut schrittweise Annex-J aus, mit etwas Glück erhälst du dann 12 MBit.

Falls du die Box nochmal auf Werkseinstellungen zurücksetzt, wäre es nett, wenn du mir eine Config schickst, dann sind auf jedenfall keine persönlichen Daten drinnen und ich kann mir das mal ansehen, vielleicht finde ich ja dann den Fehler und du kannst es an AVM weitergeben.
 
Zuletzt bearbeitet:
Hi, hat geklappt mit den Ports zuweisen.

Die Priorisierung sieht bei mir gleich aus wie bei dir. Ich werde mal noch bei verschiedenen Anwendungen mit der Priorisierung spielen und schauen was sich machen lässt. Wenn man das Prinzip verstanden hat, ist es durchaus mächtiger als das normale TrafficShaping.

Annex-J muss ich mir mal anschauen. Momentan surfe ich über ADSL 2+, Annex B mit nem Bandbreitenkorridor zwischen 2 und 6 MBit.
 
Hallo zusammen,

die Priorisierung spinnt total. Gestern hatte das wunderbar funktioniert. 700 kb down, 70 kb up. Heute musste ich wieder 200 MB hochladen und merkte sofort, dass die Priorisierung nicht meht anspringt. Ein Blick in den Taskmanager und Online-Traffic der Box ergab, dass die Priorisierte Anwendung "Surfen" für Echtzeit nicht mehr in der Grafik zu finden war (alles hellblau, kein dunkelblau).

Ich lade nachher mal die Konfigurationsdatei hoch. Irgendwas stimmt hier nicht.

Grüße Coffeemaker

PS: Siehe ZIP
 

Anhänge

  • 7270_export.zip
    7.2 KB · Aufrufe: 4
Zuletzt bearbeitet:
Nachdem ich nun die Priorisierung erneut eingerichtet habe und für jeden PC einzeln! angelegt, geht es wieder. Mal schauen wie lange :-D

priorisierung-geht-2.png
 
Nachdem ich nun die Priorisierung erneut eingerichtet habe und für jeden PC einzeln! angelegt, geht es wieder.

Vielen Dank für die Konfiguration. Ich konnte keine gravierenden Abweichungen feststellen.
Auch vielen Dank, dafür, dass du dein Problem hier gepostet hast, denn dadurch bin ich jetzt auf ein sehr gravierendes Problem gestoßen.
Ich muss zugeben, ich hatte die neue TCP-ACK Priorisierungsregel von AVM nie getestet. Ich hatte bei meinen Tests meinen PC individuell priorisiert, damit die funktionierenden Screenshots erstellt und damit lief es. Für die Anleitung dachte ich mir, dass ich einfach "Alle Geräte" als Priorisierungsziel auswähle, aber genau dann, wenn man aber die Regel Surfen für alle PCs im Netzwerk einstellt, wird NICHTS priorisiert. Nur wenn man jeden PC (den man priorisieren möchte) einzeln mit "Surfen" priorisiert, wird diese tatsächlich angewendet.
Das ist ein schwerer Bug in der Firmware.
Zum Test hatte ich mal eine Regel Namens "Test" angelegt, die alle TCP-Zielports priorisiert und dann diese auf "Alle PCs" angewendet. Diese Regel hat funktioniert, es wurden alle Pakete priorisiert.
Herauskam in der Konfiguration
Code:
{
                enabled = yes;
                name = "test:PC-all";
                type = qos_cfg_other;
                iface = qos_lan;
                rule = "";
                result {
                        tos = -1;
                        vlan_prio = -1;
                        queueref = "important";
                }

Wie man sich jetzt vorstellen kann, muss in die obige Regel nur noch "ip.proto == tcp ip.len <= 64" ein und dann funktioniert TrafficShaping endlich auf allen PCs.
Übrigens, wenn man bei dieser vorhandenen Regel, also
Code:
{
                enabled = yes;
                name = "tcpack";
                type = qos_cfg_hidden;
                iface = qos_lan;
                rule = "ip.proto == tcp ip.len <= 64";
                result {
                        tos = -1;
                        vlan_prio = -1;
                        queueref = "important";
                }
den Namen in name = "tcpack:pC-all"; ändert funktioniert es trotzdem nicht. Es ist erforderlich eine eigene Regel anzulegen.
Interessant ist, dass solche Sachen wie "Internettelefonie" auch priorisiert werden, obwohl deren Konfiguration auch versteckt ist. Vielleicht liegt es daran, dass die anderen vom Typ qos_cfg_internal sind, die Werksregel mit tcpack jedoch vom Typ qos_cfg_hidden. Wer mag kann ja da mal testen, ob es schon ausreicht den Typ zu ändern. (EDIT: Es reicht nicht. Es steht dann zwar unter "Priorisierte Anwendungen" bei Netzwerkgerät "automatisch" (so wie oben in den Echtzeitanwendungen bei Internettelefonie) und als Name der Netzwerkanwendung "tcpack". Priorisiert wir dann aber trotzdem nichts. Man muss wirklich diese relativ aufwändige Anleitung durchlaufen).

Im Anhang habe ich eine Anleitung. Zum Bearbeiten der Konfiguration benötigt man Notepad++ http://notepad-plus-plus.org/download/

Kurzer Kommentar zu den Schritten/Bildern:
1. Neue Netzwerkanwendung hinzufügen
2. Dieser einen Namen wie "TCPACK" geben
3. Bei den Protokollen TCP wählen, Quellport und Zielport auf beliebig setzen
4. Hat man die neue Netzwerkanwendung erstellt man eine neue Regel unter "Priorisierte Anwendungen"
5. Man wählt "Alle Geräte" und dann die Namen den man in Schritt 2 vergeben hat, hier "TCPACK"
6. Man exportiert die Konfiguration
7. Die exportierte Konfiguration öffnet man in Notepad++ und fügt NoChecks=yes unter Language=de hinzu. Das sorgt dafür, dass man die geänderte Konfiguration wieder in die Box spielen kann
8. Man sucht nun in der Konfigurationsdatei nach dem in Schritt 2 vergebenen Namen bis man die im Bild gezeigte Stelle findet und bei rule setzt man ein
Code:
rule = "ip.proto == tcp ip.len <= 64";
9. Nun importiert man wieder die geänderte Konfiguration. Die Box startet mit den geänderten Einstellungen neu.
10. Sich über das Ergebnis freuen

Wer die Regel "Surfen" nachbilden will, dass dies auf alle PCs angewendet wird, der möge bitte eine weitere Netzwerkanwendung hinzufügen und genauso verfahren, nur bei Schritt 8 dann noch zusätzlich bei der weiteren Regel
Code:
rule = "tcp.dest 80,3128,8080 ip.len <= 800";
ändern. Das sorgt dafür, dass HTTP-Anfragen priorisiert werden und damit der Webseitenaufbau auch etwas schneller wird. Leider hat AVM den HTTPs Port (443) vergessen. Wenn man schonmal dabei ist am besten auch noch SMTP (25), SSL-SMTP 587, POP3 110, POP3s 995, IMAP 143, IMAPs 993 so einstellen, also
Code:
rule = "tcp.dest 25,80,110,143,587,993,995,3128,8080 ip.len <= 800";
Die Regel ip.len <=800 sorgt dafür, dass der Verbindungsaufbau priorisiert wird, aber das verschicken von Anhängen und Webuploads jedoch nicht, da deren Pakete im Regelfall die Maximalgröße von ca. 1500 Byte (ca. weil ein bisschen was wegen Ethernet und PPPoE Overhead abgezogen werden muss, stark vereinfacht)

Ich empfehle bei der Priorisierung natürlich was die obige angelegte Regel betrifft nichts mehr zu ändern, da sonst die Konfiguration rausfliegen könnte.

So langsam könnte AVM mal eine Fritzbox für mich springen lassen. Die bewerben ihre Box mit TrafficShaping und ich darf deren Box ständig analysieren und bearbeiten damit TrafficShaping endlich so wie beworben funktionert.
 

Anhänge

  • 1.jpg
    1.jpg
    167.9 KB · Aufrufe: 36
  • 2.jpg
    2.jpg
    113.5 KB · Aufrufe: 33
  • 3.jpg
    3.jpg
    107.5 KB · Aufrufe: 33
  • 4.jpg
    4.jpg
    215 KB · Aufrufe: 34
  • 5.jpg
    5.jpg
    98.9 KB · Aufrufe: 32
  • 6.jpg
    6.jpg
    147.2 KB · Aufrufe: 33
  • 7.jpg
    7.jpg
    87.9 KB · Aufrufe: 33
  • 8.jpg
    8.jpg
    113.9 KB · Aufrufe: 35
  • 9.jpg
    9.jpg
    136.3 KB · Aufrufe: 31
  • ergebnis.jpg
    ergebnis.jpg
    64.9 KB · Aufrufe: 34
Zuletzt bearbeitet:
Hi Schnappi,

super Anleitung, die wohl auch im Normalfall super funktioniert. Ich habe das Problem nun weiter analysiert und folgende Szenarien getestet:

Normaler Download bei gleichzeitigem Upload (z.B. 1 GB Testfile und Upload über Browser oder FTP). Das funktioniert nun wunderbar. In der Grafik sieht man nun auch richtig schön die priorisierten <= 64 - Pakete im Upload.

Nun kommt etwas merkwürdiges: Schaue ich Videos über YouTube greift die Regel "ip.len <= 64" nicht mehr. Die Acks für den YouTube-Download werden als normaler Traffic dargestellt. So unter anderem auch bei MyVideo.de.

Auf Grund dessen habe ich mal wieder Wireshark mitlaufen lassen und bemerkt, dass extrem viele TCP Retransmissions und TCP DUP-Pakete zurückgeschickt werden. Diese sind minimal 66 Bytes groß und dürften theoretisch nicht priorisiert behandelt werden und erzeugen deshalb vielleicht den extra Traffic. Also habe ich die Regel mal auf "<= 100" umgeschrieben. Nun wird aber der GESAMTE Upload priorisiert. Das kann doch nicht wahr sein?

Gibt es eine Möglichkeit die Regel irgendwie nur auf "ausgehende Pakete TCP mit ACK = 1" zu priorisieren? Eventuell irgendwie tcp.flag = 0x10 oder so? Wo kann ich mehr über die Syntax der rules erfahren?

Zweites Problem ist: tracert liefert nun ab dem 3. Hop nur noch * * * Zeitüberschreitung. Ping geht auf den ersten Test ohne Verluste.

Grüße coffeemaker
 
Wo kann ich mehr über die Syntax der rules erfahren?
Wahrscheinlich nur bei AVM. Ich habe deren Syntax einfach kopiert. Ich denke nach dem ACK-Flag zu schauen ist zu rechenintensiv, deswegen bedient man sich dieses Tricks mit der Packetlänge.

Ein paar DUP-Acks habe ich auch, aber die meisten Pakete sind normale ACKs mit 54 Byte Länge. DUP-Acks treten auf, wenn Pakete verloren gehen. Irgendwie scheint es bei dir einen hohen Paketverlust zu geben bzw. meine Vermutung ist, nachdem die Telekom ja dafür bekannt ist eine schlechte Youtube Anbindung zu haben, dass aufgrund dessen bei manchen Videos soviele Pakete verlorengehen. Die Regel sollte das aber nicht sein.

Tracerts gehen bei mir einwandfrei.
 
Für die Anleitung dachte ich mir, dass ich einfach "Alle Geräte" als Priorisierungsziel auswähle, aber genau dann, wenn man aber die Regel Surfen für alle PCs im Netzwerk einstellt, wird NICHTS priorisiert. Nur wenn man einen einzelnen PC mit der Regel "Surfen" priorisiert, wird diese tatsächlich angewendet.
Das ist ein schwerer Bug in der Firmware.

Hallo
Das sehe ich nicht so.
Ich habe zwei Endgeräte für Video on Demand.
Diese beiden IP-Nummern habe ich unter "Echtzeit" mit "Surfen" priorisiert.
Schaut meine bessere Hälfte über eines der beiden Endgeräte einen Film und ich mache mit einem dritten PC einen großen Upload, bleibt der Videostream (Download) konstant.
Der Videogenuss wird nicht unterbrochen (Ladekreis bei Maxdome).
Ohne Prio-Regel würde der dritte PC den Stream unterbrechen.

VG
Domarc
 
Zuletzt bearbeitet:
Auszug aus Tracert:

Code:
Routenverfolgung zu www.telekom.de [217.150.151.99] über maximal 30 Abschnitte:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.0.1]
  2    20 ms    20 ms    20 ms  87.186.224.47
  3    22 ms    22 ms    23 ms  87.186.254.58
  4    26 ms    26 ms    25 ms  f-eb7-i.F.DE.NET.DTAG.DE [62.154.16.178]
  5    26 ms    26 ms    27 ms  193.159.227.18
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9     *        *        *     Zeitüberschreitung der Anforderung.
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12     *        *        *     Zeitüberschreitung der Anforderung.
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14     *        *        *     Zeitüberschreitung der Anforderung.
 15     *        *        *     Zeitüberschreitung der Anforderung.
 16     *        *        *     Zeitüberschreitung der Anforderung.
 17     *        *        *     Zeitüberschreitung der Anforderung.
 18     *        *        *     Zeitüberschreitung der Anforderung.
 19     *        *        *     Zeitüberschreitung der Anforderung.
 20     *        *        *     Zeitüberschreitung der Anforderung.
 21     *        *        *     Zeitüberschreitung der Anforderung.
 22     *        *        *     Zeitüberschreitung der Anforderung.
 23     *        *        *     Zeitüberschreitung der Anforderung.
 24     *        *        *     Zeitüberschreitung der Anforderung.
 25     *        *        *     Zeitüberschreitung der Anforderung.
 26     *        *        *     Zeitüberschreitung der Anforderung.
 27     *        *        *     Zeitüberschreitung der Anforderung.
 28     *        *        *     Zeitüberschreitung der Anforderung.
 29     *        *        *     Zeitüberschreitung der Anforderung.
 30     *        *        *     Zeitüberschreitung der Anforderung.

Ablaufverfolgung beendet.

Das seltsame: Die ersten 3 Hops klappen Problemlos, ab dem 4. immmer die Zeitüberschreitungen. An der Telekom kann es nicht liegen, da mit der alten Box keine Fehler auftauchen.

Habe heute die Firmware per Recovery neu eingelesen. "Echtes" Videostreaming kann ich so nicht genau testen. Zattoo, myvideo.de und youtube.com leiden aber weiterhin unter Einbruch des Streams, auch bei priorisierten Regeln.

Ich werde bei AVM nun direkt anrufen, da auf meine Service-Anfragen keine Antwort kommt.

Hat noch jemand eine Idee, was ich testen könnte? So langsam vermute ich eine defekte Box in diesem Zusammenhang.

Grüße Coffeemaker
 
Hast du den Effekt auch mit tracert t-online.de?

Denn tracert telekom.de ist mehrdeutig. Möchtest du die Antwort aus dem Internet oder dem Hitnet (Intranet der Telekom)?

VG
Domarc
 
Jap. Auf alles was nach den 2 ersten Routern der FritzBox liegt. Also quasi ab dem 4. treten dann massive ICMP-Paketverluste auf. Manchmal bekomme ich auch zurück, dass der Host nicht aufgelöst werden konnte.

Mit der 7050 und 2170 treten diese Erscheinungen nicht auf. So langsam wird sich die T-Com sorgen machen ;-) alle 15 minuten neue DSL-Sync ;-)

Gruß Coffeemaker

PS: Ich ziehe das nun vollends durch, um den Fehler zu finden. Eventuell ist es ja eine Serie mit Hardwareseitigem Defekt. Mal sehen ob noch mehr User diese Probleme haben. Jedenfall habe ich schon in weiteren Foren von "Priorisierung funktioniert nicht" usw gelesen.
 
Zuletzt bearbeitet:
Diese beiden IP-Nummern habe ich unter "Echtzeit" mit "Surfen" priorisiert.
Schaut meine bessere Hälfte über eines der beiden Endgeräte einen Film und ich mache mit einem dritten PC einen großen Upload, bleibt der Videostream (Download) konstant.
Sorry das war von mir zweideutig ausgedrückt, werde das gleich editieren. Ich habe gemeint man muss die PC einzeln priorisieren, nur "Alle Geräte" geht nicht.

Das seltsame: Die ersten 3 Hops klappen Problemlos, ab dem 4. immmer die Zeitüberschreitungen. An der Telekom kann es nicht liegen, da mit der alten Box keine Fehler auftauchen.
Mach mal einen Ping auf die Adresse, auf die du auch tracert machst. Der Server antwortet einfach nicht auf ICMP Echo Requests und deswegen geht Tracert immer weiter.
Mach mal tracert heise.de, das klappt bei mir immer. Tracert telekom.de bricht bei mir auch beim 6. Hop ab.
 
FritzBox 2170:

Code:
Routenverfolgung zu www.heise.de [193.99.144.85] über maximal 30 Abschnitte:

  1     1 ms    <1 ms    <1 ms  fritz.box [192.168.0.1]
  2    23 ms    22 ms    23 ms  87.186.224.47
  3    25 ms    24 ms    24 ms  87.186.254.62
  4    27 ms    26 ms    48 ms  f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.214]
  5    28 ms    52 ms    26 ms  217.243.218.38
  6    27 ms    27 ms    26 ms  heise1.f.de.plusline.net [82.98.98.98]
  7    28 ms    27 ms    27 ms  www.heise.de [193.99.144.85]

Ablaufverfolgung beendet.

FritzBox 7270v3:

Code:
Routenverfolgung zu www.heise.de [193.99.144.85] über maximal 30 Abschnitte:

  1     1 ms    <1 ms    <1 ms  fritz.box [192.168.0.1]
  2    21 ms    20 ms    24 ms  87.186.224.47
  3    22 ms    21 ms    23 ms  87.186.254.62
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9     *        *        *     Zeitüberschreitung der Anforderung.
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12     *        *        *     Zeitüberschreitung der Anforderung.
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14     *        *        *     Zeitüberschreitung der Anforderung.
 15     *        *        *     Zeitüberschreitung der Anforderung.
 16     *        *        *     Zeitüberschreitung der Anforderung.
 17     *        *        *     Zeitüberschreitung der Anforderung.
 18     *        *        *     Zeitüberschreitung der Anforderung.
 19     *        *        *     Zeitüberschreitung der Anforderung.
 20     *        *        *     Zeitüberschreitung der Anforderung.
 21     *        *        *     Zeitüberschreitung der Anforderung.
 22     *        *        *     Zeitüberschreitung der Anforderung.
 23     *        *        *     Zeitüberschreitung der Anforderung.
 24     *        *        *     Zeitüberschreitung der Anforderung.
 25     *        *        *     Zeitüberschreitung der Anforderung.
 26     *        *        *     Zeitüberschreitung der Anforderung.
 27     *        *        *     Zeitüberschreitung der Anforderung.
 28     *        *        *     Zeitüberschreitung der Anforderung.
 29     *        *        *     Zeitüberschreitung der Anforderung.
 30     *        *        *     Zeitüberschreitung der Anforderung.

Ablaufverfolgung beendet.

Ping funktioniert bei beiden Boxen ohne Verluste. Sollte ich die Box mal zu AVM einschicken? Die Priorisierung funktioniert fehlerhaft und ICMP zusammen mit UDP Port 53 wird ebenfalls fehlerhaft verarbeitet (merke ich an den langen DNS-Anfragen beim normalen Surfen und an Ping bei fehlerhafter Auflösung des Hosts). An der T-Com kann es nicht liegen, da die beiden anderen Boxen die Daten zuverlässig verarbeiten.

Grüße Cm

PS: Ich arbeit immer immer mit dem Netz 192.168.0.0, nicht wundern. Ich werd jetzt mal die 7270 als Router einbinden und Zugang über das vorhanden LAN nehmen, da ich testen möchte, ob es am DSL-Modem oder der Verarbeitung des LAN-Traffic liegt.
 
Zuletzt bearbeitet:
Ich arbeit immer immer mit dem Netz 192.168.0.0, nicht wundern.
Irgendwie habe ich noch im Hinterkopf, dass sich eine Fritzbox in diesem Netz abnormal verhalten haben soll. Ich kann mich aber auch irren. Dummerweise kann man im Forum nicht nach 192.168.0.0 suchen. :(
 
Nachdem ich die Box als NAT-Router (Netz 192.168.1.0) eingerichtet habe kommt nun etwas sehr erstaunliches zu Tage:

Ping funktioniert einwandfrei

Tracert hat keine verlorenen Pakete mehr

Bis auf den zusätzlichen Hop der Box die ins Internet geht sieht es nun sehr gut aus.

TrafficShaping / Priorisierung zeigt das Verhalten, was es soll

Was soll ich sagen. Nun werden auch Videostreams als "Surfen" erkannt und laden fleißig bei vollem Upload. Die Priorisierung meiner Anwendungen zieht nun endlich und so klappt neben Upload auch SSH in nahezu Echtzeit.


@KunterBunter: Ich nutze 192.168.0.0 schon sehr lange und hatte noch nie Probleme damit. :)

AVM schreiben oder Box umtauschen?

Grüße Coffeemaker
 
Habe nun mal "Surfen" in die Echtzeitanwendung geworfen und nun sieht man, dass die ACK-Pakete vom Download als Echtzeit durchgehen. Ich frage mich, warum dies nicht mit priorisierten Anwedungen klappt.
Die Firmware scheint also ein Problem mit den internen Priorisierungsregeln zu haben, wenn diese nicht unter "Echtzeitanwendungen" stehen.

Ich habe testweise mal bei der vorhandenen tcpack-Regel den Typ von qos_cfg_hidden auf qos_cfg_internal gesetzt, aber das Trafficshaping hatte nicht funktioniert. Einziger Weg bleibt also die weiter oben gepostete etwas komplizierte Anleitung.

Im Anhang ein Bild, wo man sieht, wenn es umgesetzt ist (wie gesagt, funktioniert aber nicht).
 

Anhänge

  • nichtfunktionierend.jpg
    nichtfunktionierend.jpg
    180.9 KB · Aufrufe: 25
Hi schnappi,

ich kann den Fehler geziehlt nachproduzieren, und zwar über den Einsatz verschiedener Zugangsmethoden: Internes Modem, externes Modem (7050) und vorhandene LAN über 2170. Über das interne Modem bricht der Datenverkehr komplett zusammen, über die 7050 als Modem nur 20-30% und über die 2170 als NAT-Router funktioniert die ganzen Priorisierung wie sie soll.

Die Priorisierungsregeln haben allgemeine ein Problem, da sie bei mir unter der Verwendung des internes Modems nicht korrekt funktionieren und falschen Traffic filtern. Nun habe ich endlich das Ticket von AVM. Werde euch berichten, was AVM zu der ganzen Geschichte sagt. Wir haben nun ja einen Pool von Testszenarien ausgearbeitet. ;-)

Gruß Cm
 
Wir brauchen schnellstmöglich eine Lösung von AVM. Meine eigene Prioriserungsregel hat die Box nach einem Neustart (oder im Laufe der Zeit, so genau kann ich das nicht sagen) verstümmelt. Übrig blieb von beiden Regeln (TCPACK und MeinSurfen)
Code:
rule = " ip.proto == tcp";
, d.h. die Längenbegrenzung ist weggefallen, sodass jetzt alle TCP-Pakete priorisiert werden und ich wieder wie am Anfang dastehe. Ich müsste also die Konfiguration nochmal editieren (um in der Zwischenzeit erfolgte Konfigurationsänderungen und Anrufe nicht zu verlieren) und neu einspielen. Da habe ich keine Lust drauf. Bis AVM das endlich behebt werde ich jeden PC einzeln mit "Surfen" priorisieren.
 
Hi Schnappi,

meine Box priorisiert momentan, fragt sich aber wie lange. Mir kommt es ebenfalls so vor, als ob die Box ihre eigene Regeln zur Priorisierung aushandelt. Manche Änderungen zeigen ab und zu gar keine Wirkung, momentan funktionieren die Priorisierungen aber so wie sie sollen. Fragt sich nur wie lange?

Wenn ich das Fehlerprotokoll und die ausgiebige Fehlerbeschreibung zu AVM sende, schicke ich den Link dieses Threads mit. Leider kann ich die Fehler nicht geziehlt reproduzieren.

Grüße coffeemaker
 

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,691
Mitglieder
371,315
Neuestes Mitglied
jack-mack
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.