Nur Tomato Firmware bringt VoIP+Surfen+FileSharing unter einen Hut bzw QOS ;o)

Mein Router:
Linksys WRT54GL

Meine Vorstellungen von QOS:
1. Wenn ich meinen Internetanschluss nicht aktiv brauche soll 100% der Bandbreite für das FileSharing genutzt werden.
2. Wenn ich surfe sollen die Websites schnell aufgebaut werden - als ob die Leitung sonst leer wär ...obwohl das FileSharing mit 2ter Priorität den Rest der Leitung ausnutzt.
3. Wenn ich mein VoIP-Telefon (SIP) benutze möchte ich perfekte Sprachqualität, bei mir und beim Gesprächspartner. Websites sollten weiterhin zügig gehen und der Rest der Bandbreite für FileSharing genutzt werden.

Dies sollte eigentlich kein Problem sein bei 3000/300. Und logisch ist das ja auch - ich mein wer will dieses QOS nicht?

Also erste Priorität hat VoIP, zweite WWW und 3te alles andere. Und zwar logischerweise nicht nur Bandbreitepriorität sondern auch Antwortzeit (vor allem für VoIP).



...lange Rede kurzer Sinn:
Ich habe mit meinem Router lange probiert mit verschiedenen Firmwares (auch dd-wrt.v23SP2 final_voip) aber kein befriedigendes Ergebnis bekommen. Das surfen ging langsamer als bei einer 56k-Modem und VoIP war gar nicht zu gebrauchen. Mit HFSC hab ich es auch versucht mit besserem Erfolg aber ich hatte immernoch schlechtes VoIP.

Jetzt habe ich die Tomato-Firmware auf meinen Router gebraten und es geht super! Mein FileSharing läuft praktisch Tag und Nacht und wenn ich ab und zu surfe flutschen die Websites als ob nichts wäre und beim Telefonieren habe ich keine Qualitätsverluste.

Ich habe dieses Forum nach Tomato durchsucht aber nichts gefunden, deshalb dachte ich das muss hier noch rein ;o)


Vor allem die grafischen Diagramme über die Bandbreitenausnutzung und QOS-Zuteilung find ich cool :wow:

http://de.wikipedia.org/wiki/Tomato_(Firmware)

wiki

Wiki für Tomato (besser als bei wikipedia.org):
http://de.wikibooks.org/wiki/Tomato_(Firmware)

...Die QOS-Einstellungen werden gut erläutert. Sogar die Problematik mit den Filter-Methoden ist verständlich erklärt... :idea:

QOS => Basic Settings => "Strict Rule Ordering" aktivieren und unter QOS => Classification deine FritzBox-IP-Zuweisung ganz nach oben schieben. Dann sollte es funktionieren.

Hier sind die Konfigurationsmöglichkeiten gut beschrieben:
http://de.wikibooks.org/wiki/Tomato_(Firmware)#Classification

...viel Erfolg ;o

BenB schrieb:

Wozu vergebe ich erst die Class Highest für die FB wenn ich sie dann doch manuell erst mal in die richtige Reihenfolge mit der höchsten Priorität nach oben ordnen muss?

Zum Vergrößern anklicken....

Die Rangfolge hat nichts mit der Priorität zu tun. Bei der Rangfolge geht es nur darum in welcher Reihenfolge die Filterregeln abgearbeitet werden.

Ich kenne deine Regeln nicht (kannst ja mal ein PrintScreen posten ) aber es kann sein dass eine Regel oberhalb der IP-Zuweisung das VoIP-Paket bereits vorher gefiltert hat bevor die IP-Regel greifen konnte. Deshalb gibt es auch dieses "Strict Rule Ordering" was die Rangfolge der Filter strikt einhält oder nicht. Dazu ein Auszug aus dem Wiki:
>>>"Rangfolge: Die Regeln werden wie in der GUI abgebildet, strikt von oben nach unten geprüft. Die erste Regel die zutrifft markiert die Klasse. Wenn "strict ordering" ausgeschaltet ist werden die PP2P-, L7- und KB-Filter einer Gruppe zugewiesen und zuerst geprüft, alle anderen Regeln kommen danach."<<<

Ein Beispiel:
Man macht 2 Filter.
Filter 1: Alle Pakete mit Port 80 Class Highest
Filter 2: Alle Pakete mit IP 192.168.1.5 Class Low
Jetzt geht ein Paket über Port 80 an den Rechner 192.168.1.5. Wenn der Filter 1 vor dem Filter 2 ist dann bekommt dieses Paket die Klasse Highest ...und wenn das Paket zuerst über den Filter 2 geht dann kommt es in die Low Klasse. (sofern "Strict Rule Ordering" aktiviert ist)

BenB schrieb:

Wenn die FB Regel unten ist wird sie als Low behandelt. So wie sie jetzt ist als Highest. Ich habe auch nur die IP-Adresse der FB als Filter gesetzt, was ja am Besten sein soll. Aber wenn ich mir das richtig anschaue, könnte die Regel TCP/UDP mit Port 1024-65535 daran schuld sein?

Zum Vergrößern anklicken....

Genau ...Allerdings müssten dann die Pakete als Lowest behandelt werden und nicht als Low. Könnte es sein dass deine VoIP-Pakete über Port 80/443 flutschen? => das ist ja die einzige Regel mit einer Low-Zuweisung. Ansonsten wärs dann ev. doch ein (fast unbedeutender ) Bug. Ausserdem sind ja VoIP-Pakete i.d.R UDP und nicht TCP :gruebel: