Alte Version über die Version nachvollziehbar, Posting soll im „Erklärbär“ nicht als Vorlage für Technikdiskussionen dienen.
Das geht auch fuer das ganze gastnetz!
Gesetz dem Fall, man zieht sich etwas Größeres: Ist dann Freifunk am Anschluss der Fritzbox quasi abgeschaltet oder tröpfelt noch etwas durch?
Es kommen noch Daten durch. Wie genau die Verbindungen priorisiert werden, weiß ich nicht. Hier konnte ich in einem ersten Test bei ausgelasteter Leitung (DSL 16000) noch 2 MBit über Freifunk als Hintergrunddienst abwickeln. Das ist in meinem Augen ein sehr gutes Ergebnis: Meine Daten haben Priorität und 10 % bis 15 % der Leitung können immer noch für Freifunk genutzt werden, selbst wenn ein größerer Download läuft.
4 „Gefällt mir“
Das klingt akzeptabel, danke für den Test.
Habe gehört, dass das nur für IPv4 funktioniert, nicht allerdings für IPv6. Ist das korrekt?
hab bei mir auch Priorisierung auf der Fritzbox für GAST (Port 4) => FF, dort kommen mindestens 10% noch auf GAST durch, auch wenn ich voll sauge. Also regular VDLS 50 = 54Mbis/s down + 5 Mjit/s up, wenn auf Port 1
FF erhält - wenn ich Port 1 inaktiv - ca. 15.5 - 17.5 Mbit/s down
Wenn ich voll sauge, erhalte ich noch 48- 50Mbit/s und FF erhält ca. 2-3 Mit/s down, schwankend
Getestet mit hochkomprimiertem 500 MB File 7z download
2 „Gefällt mir“
WIe stelle ich das ein? Unter Priorisierung kann ich nur „Alle Geräte“ auswählen und Geräte am Gastzugang haben auch keinen Bearbeitungsbutton.
ich habe gerade mal bei jemanden mit einer Fritzbox geschau es geht nur noch der Router. Das ganze Gastnetz 179 ist nicht mehr in der Auswahl.
Wir haben 4 Router in der Gemeinde aufgestellt. Nun ist der Upload nur durch das Grundrauschen fast dicht. Das kann natürlich keine Lösung sein. Das Eintragen der Router als Hintergrund-Anwendung hat nichts gebracht. Der Traffic lief laut FritzBox als Normal-Anwendung.
Nun habe ich eine Regel eingeführt, dass jegliche einstellbare Protokolle (TCP, UDP, ESP, GRE, ICMP) runterpriorisiert werden. Darauf hin ist auch das „Grundrauschen“ eine Hintergrund-Anwendung.
Hat jemand Erfahrungen, ob Freifunk derart priorisiert noch stabil funktioniert?
Ich habe 5 Beiträge in ein neues Thema verschoben: MeshVPN an schmalbandigem/unperformantem Uplink betreiben
Nachdem es zeitweise nicht mehr möglich war, sich mit dem Netz zu verbinden, sind wir wieder mit unveränderten Prioritäten unterwegs.
Meine Hoffnung mit dieser Anfrage war, dass jemand mit Ahnung von Netzwerken hier schreibt: „Protokoll XYZ sollte nicht gedrosselt werden, da es dann die Probleme ABC gibt, aber … kann ruhig gedrosselt werden.“
Verschiedene Ports oder Protokolle unterschiedlich zu priorisieren bringt nicht viel, da über den Tunnel eh das ganze Netz kommt. Darauf hat die Fritz!Box keinen Einfluss.
Am sinnvollsten ist es also tatsächlich den gesamten Traffic, den das Gerät produziert, zu priorisieren.
Deine bisherigen Regeln haben wahrscheinlich nicht gegriffen, da der Port des fastd nicht unter den Voreinstellungen (Protokollen) der Fritz!Box aufgeführt ist.
Du kannst aber eine Registerkarte weiter rechts einen neuen Dienst anlegen und dort den fastd-Port einstellen. Dabei den Zielport immer beliebig lassen, nur den Startport auf 10000 oder was auch immer deine Community verwendet, setzen.
Einfacher ist es aber die IP des VPN-Routers zu depriorisieren, da hast du schon recht. Funktioniert bei mir super.
Naja grundlegend muss man erstmal festhalten, dass die Priorisierung nur für ausgehenden Verkehr (Upload) greift. Beim eingehenden Verkehr (Download) kann man nix priorisieren.
Vllt. bekomme ich es an meiner VDSL25-Leitung auch nicht richtig mit, aber der Graph im Webinterface zeigt eindeutig, dass der Verkehr als Hintergrund eingestuft wird. Der Filter greift also. Und wenn ich per SSH was hochlade (ist bei mir priorisiert, orange), macht das den Hintergrundtraffic (Torrent, Tor und Freifunk) auch ziemlich platt bei mir. Also würde ich schon sagen, dass es greift.
In wie weit es den Downstream beeinflusst kann ich nicht messen, da ich die 25 Mbit/s selten ausnutze und meist über Nacht größere Downloads mache. Da ist mir das ziemlich egal, ob es 30 min mehr oder weniger dauert.
Wenn man nicht nach IP sondern Anwendung filtert, muss man wie gesagt den inneren Port einstellen und den äußeren beliebig lassen. So wie es bei den Standardanwendungen auch ist, sonst greifen die Filter nicht.
Allerdings muss auch folgendes beachtet werden: Wenn der Upload voll ist, kann ich trotz maximaler Priorisierung auf Echtzeitanwendung nicht online zocken. Denn obwohl die Pakete bevorzugt werden, steigt trotzdem der Ping. Das merke ich dann schon.
Es lief ja ein paar Tage gut im Hintergrund. Aber dann wurde für mehrere Personen der Zugang gebraucht und ich hatte keine Zeit/Möglichkeit eine Fehlersuche zu betreiben (Zeitdruck). Nach dem Löschen der Prio-Regeln für die FF-Router ging es dann wieder. Vielleicht hat auch ein Bittorrent den Hintergrundtraffic dicht gemacht. (Den konnte ich aus organisatorischen Gründen nicht kurzfristig abklemmen.)
Ich würde also die Idee, den Traffic über Prioritäten zu dämpfen, nicht grundsätzlich verwerfen. Eigentlich müsste es funktionieren.
Wir werden bald VDSL bekommen, dann sollte genügend Bandbreite da sein, dass Freifunk problemlos mitlaufen kann.
2 „Gefällt mir“
ich habe das Gefühl, dass die Fritzbox auf den entsprechenden Seiten nur ipv4 als hintergrundtraffic priorisiert. Wenn der tunnel via ipv6 gemacht wird, dass hat die Einstellung möglicherweise keine Auswirkung.
1 „Gefällt mir“
nicht „möglicherweise“, sondern testen!
ping hat nichts mit priorisierung zu tun, sondern mit Gesamtlast der Hops
Hast du keine Fritzbox, oder kein IPv6, oder warum testet du nicht selbst?!
ping ist ein Programm, das kleine (unter Linux in der Regel 56 Byte Payload) ICMP (IP Protocol 1) Pakete vom Typ 8 (Echo Request) zu einer einer Gegenstelle schickt. Erreicht das Paket die Gegenstelle antwortet diese mit einem ICMP Paket vom Typ 0 (Echo Reply). Im Output erscheint dann u.a. die Zeit, die das Paket hin und zurück gebraucht hat. Man spricht auch von Latenz oder richtiger Paketumlaufzeit.
Die Laufzeit hat absolut nichts mit der „Gesamtlast der Hops“ zu tun, sondern mit der Auslastung aller Leitungen auf dem Weg von der Quelle, über die beteiligten Router, zum Ziel und auf dem Weg vom Ziel zurück zur Quelle.
Hin- und Rückweg müssen weder im Hinblick auf zwischenliegende Router, noch auf zur Verfügung stehende Bandbreite identisch sein. Da die Leitungen unterwegs in der Regel Daten mit unterschiedlicher Bandbreite transportieren können, müssen Pakete unterwegs im Zweifel kurz gepuffert werden. Unter Überlast, werden Pakete verworfen und müssen gegebenenfalls von der Quelle des Pakets nochmal verschickt werden.
Mit einem Mechanismus, den man verallgemeinert QoS (Quality of Service) nennt, und mit dem demnächst die Neutralität des Netzes abgeschafft wird, kann man in das Puffern eingreifen. Naturgemäß. kann man das immer nur auf der sendenden Seite. Eine Variante ist, Verkehr nach Anwendungen zu klassifizieren und durch jeweils eigene Puffer zu schieben, die verschieden häufig bedient und geleert (d.h. der Inhalt über die Leitung geschickt) werden.
Onlinespiele basieren in der Regel auf dem Transport von sehr vielen, sehr kleinen Paketen in denen z.B. nur Positionsdaten von Objekten übertragen werden. Mit steigender Latenz bekommt man als Spieler diese Information später als andere Spieler und kann deswegen nur später reagieren. Das macht dann keinen Spaß, bzw. das Spielen unmöglich.
Selbst bei optimaler Priorisierung im Upstream, d.h. stricktem Transport vor allem anderen, was die Fritzbox so nicht macht, wird man immer erhöhte Latenz bemerken: mogelt sich ab und an ein großes Paket einer anderen Anwendung dazwischen. zeigt eine kleine Rechnung, dass die Pakete des Onlinespiels ca. 10ms warten müssen, bis sie dran sind. In die kleine Rechnung ging eine 1Mbit/s Leitung ohne zusätzliche Latenz durch Fehlerkorrekturmechanismen und ein 1500 Byte Paket ein. Eben die übliche Größe eines PPPoE-Pakets.
Das die Fritzbox nicht vollständig strikt priorisiert überprüft man wie folgt: man priorisiere ftp als Echtzeitanwendung und icmp als Hintergrundanwendung. Man über trage eine große Datei und lasse einen Ping laufen. Ergebnis: obwohl immer Pakete in der Warteschlange der Echtzeitanwendung sein sollten, da sie deutlich schneller als der zur Verfügung stehende Upstrem verkraften kann, kommt ab und an doch noch ein vom Ping. Es ist aber schon ziemlich strikt.
Die Priorisierung im Downstream hat man in der Regel nicht unter Kontrolle. Mechanismen im TCP kann man aber ausnutzen, um Quitierungspakete von Hintergrundanwendungen im Upstream zu verzögern und so den Sender zu überzeugen, er möge doch insgesamt langsamer senden. während man Quitierungspakete von Echtzeitanwendung immer ganz vorn in den Puffer hängt,
Latenz hat eine steigende Bedeutung. Damit auch und vor allem die Geschwindigkeit, mit der man Quittierungen senden kann. Leider erfolgt erfolgreiche Vermarktung offenbar nur, wenn man einen fetten, fetten, fetten Download hat. Die 5Mbit/s im Upstream im Kabel reichen übrigens gerade mal um die ACKs bei einem 150Mbit/s Download durchzubringen. Kann man nichts machen. Die Menschen sind halt nicht ausreichend informiert und kaufen große Zahlen.
1 „Gefällt mir“
Die Art der Daten ist für den Test unerheblich, denn auf der VDSL-Leitung wird nicht komprimiert.