MTU-Wert für WLAN-Verbindungen?

Hallo,

wo kann findet man den MTU-Wert für WLAN-Verbindungen und wie kann/muß man ihn einstellen?

Schau mal hier https://www.supernature-forum.de/tu...htigen-mtu-wert-ermitteln-und-einstellen.html und hier https://www.supernature-forum.de/alles-rund-um-windows/62160-mtu-einstellen-mit-anleitung.html

Eventuell hilft dir das weiter.

Hey hexxxlein vielen dank :kiss

hast du selbst WLAN bzw. einige Erfahrungen damit?

Nein ich habe kein WLAN. Alles noch mit dem guten alten Kabel.
Ich nutze einen Router, dort habe ich den MTU Wert auf 1492 eingestellt. (T-Online)
Ich habe damit keinerlei Probleme, alles läuft super.

Du Glückliche, hier gibts das gute "neue" Kabel frühestens erst 6. Kalenderwoche 2008 :wand derweil muß ich mich hier mit WLAN rumärgern. Da dieses WLAN allerdings am Inbound (Zentrale) an mehreren T-DSL-Verbindungen hängt kann es sein, daß ich die ganze Zeit den falschen MTU-Wert von 1500 verwendet habe, aber sicher bin ich mir da nich. Außerdem kann ich nicht einsehen wie die Router über die dieses WLAN-Netz funktioniert diesbezüglich eingerichtet sind.

Jetzt hast du mich falsch verstanden. Ich beziehe DSL nicht vom unserem Kabelanbieter, obwohl sie auch schon Angebote haben. ot:
Aber ich bleib bei der guten alten T-Com zumal die Preise ab 4.6.07 noch einmal gesenkt werden. Für mein Paket "Call & Surf Plus" bezahl ich dann nur noch 49.95€ statt 64,95€. Zurück zum Thema. Mit Kabel meine ich, dass ich den Router per Kabel mit dem Rechner verbunden habe.

MTU von 1500 halte ich ebenfalls für zu hoch. Versuch es mal mit 1492.

Whoops, ich meinte wirklich das von der Telekom verlegte DSL-(Kupfer)-Kabel, welches hier erst 2008 gelegt wird

Beim Kabel-Anbieter wie Du es verstanden hast, müßten wir den Hausanschluß selbst bezahlen (2 Teilnehmer auf dem Grundstück), und uns die 500m Meter zum nächsten Anschlußknoten selber graben, ergo ist KabelTV+Inet in dem Falle erst recht keine Option.

Was den MTU-Wert angeht, wurde mir empfohlen den Wert statt auf WLAN direkt auf DSL (also ohne PPPOE-Bits anzupassen?), allerdings weiß ich nun nicht ob diese 8Bits von 1500 (=1492) oder von 1492 (=1484) abzuziehen sind, letzteres habe ich getestet, scheint zu laufen, trotzdem bekomme ich, wie bei Default-MTU-Werten, bei ping -t zum WLAN-Router des Bürgernetzes aller ca. 1 Minute 2 Pingaussetzer von 128ms meist gefolgt von einem verlorenenen Packet

BTW Soweit ich das jetzt nachvollziehen kann, tritt der Packetloss meist nicht beim Senden von Daten (von meinem WLAN-USB-Stick) sondern beim Empfangen von Daten auf (und das obwohl der Empfang durchschnittlich als "Sehr gut" sprich ca. 80% gemeldet wird)

Was mir da noch einfällt. Nicht jeder Provider unterstützt einen MTU Wert von 1492. Bei Arcor wird meist 1488 empfohlen. Welchen Provider hast du? Auch für WLAN kann 1492 zu hoch sein, muss aber nicht.

MTU & Berechnung

Ich hatte beim Download ähnliche Probleme. Geholfen hat mir eine Änderung in der Netzwerkkarteneinstellung.

HW-Prüfsummenberechnung - aus
(Checksum)

zum Provider. Kein Provider in dem Sinne, es ist ein Bürgernetz wie es sie vielerorts gibt, Basis sind meist handelsübliche WLAN-Router mit Spezialantennen, diversen Accesspoints und ner Zentrale die dann mit mehreren DSL-Anschlüssen ins DSL-Netz angebunden ist, es ist auch ein Limitter aktiv (der bei Überlast den Durchsatz regelt und auf alle Netzteilnehmer gleichmäßig aufteilt? *böhmisches Dorf*)

Ich bin quasi wiefolgt angebunden: Rechner+WLAN-USB-Stick ->wireless-> Hausnetz-WLAN-Router ->LAN-> Bürgernetz-WLAN-Router ->wireless-> mehrere Access-Points ->wireless-> Inbound(Server) ->LAN-> DSL-Netz.

Die meisten Downloads schlagen bei mir fehl ich muß geradezu zwangsläufig nen Download-Manager (in meinem Falle ist's FDM) verwenden um die DL's sauber zu bekommen.

Hab mal die in der MTU-Anleitung erwähnten Befehle ausgeführt bis max 1464 (+28) erst ab 1465 bekomme ich die Meldung, aber derweil bekomme ich wenigstens bei einem der 4 Pakete (auch bei 1464) "Zeitüberschreitung der Anforderung"

Checksum, tja mal schauen ob's da Optionen beim WLAN-Treiber gibt. Danke für den Hinweis.

Ich habe jetzt ehrlich gesagt den Thread nur kurz Überflogen.

Evtl kann Dir der TCP Optimizer weiterhelfen.

:homepage::download:

Das Dingen hab ich schon mal getestet, hat mir einiges verhauen und trägt viel in die Registrierung ein. Klar bequem ist das allemal. Ich ziehe die Einstellungen per Hand allerdings vor. Dazu reicht auch Dr.TCP

Hab nun beides auf HD, danke für die Tips

Und falls die Links von hexxxlein doch nicht fruchten - hier ganz viel Lesestoff
http://www.google.com/search?q=mtu+wlan

PS wenn du über 3* WLAN hoppst, kann die Verbindung nur scheisse sein - egal was du einstellst.

Maximum Transmission Unit (MTU) ist die maximale Paketgröße die ein Ethernetframe nach RFC haben darf, ohne fragmentiert werden zu müssen.

Die Größe der MTU bestimmt sich durch die Daten plus IP-Header. Also ist bei der Angabe der MTU sowohl der Ethernetheader als auch der PPPoE-Header schon mit einbezogen. Weitere Header durch Providerspezifische Protokolle können die MTU weiter verkleinern. Anbei eine kleine Liste der Werte, welche bei den gängisten Providern einzustellen sind.


Für weitere ist dann google ein guter Partner -> search Providername + MTU

Der entsprechende Registrierungsschlüssel zum Einstellen dürfte ungefair so aussehen:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Adapternummer\Parameters\Tcpip\MTU

Wenn es am Speed bei WLAN hapern sollte, muss das nicht unbedingt an der MTU liegen.

Es kann auch sein, dass das TCPRcvWin falsch eingestellt ist. Das TCP Receive Window ist etwas höher im ISO-OSI-Model (in Schich 3 um genau zu sein) angesiedelt als die MTU. Hier liegt meist eher das Problem, wenn WLAN zwar auf 54MBit/s läuft auber von den beispielsweise 6MBit/s DSL weniger als die hälfte ankommt. Bedanken darf man sich da bei Microsoft für den zu geringen Default-Wert. Den Wert kann man ausrechnen und Einstellen, auch wieder in der Registry.

Aggi hat schon n guten Tip gegeben (woher er den nur wieder hat ^^) und zwar den TCP-Optimizer. Mit ihm kann man die MTU angeben und Einfluss auf das TCPRcWin nehmen, indem man die entsprechende Bandbreite Regler einstellt.

Zur MTU sei noch erwähnt, dass sie natürlich auch auf dem Router korrekt eingestellt werden sollte.

Soviel allgemein zur Technik... Wenn ich mir ansehe wie du angebunden bist, liegt die Vermutung nahe, das der Übeltäter auf dem Übertragungsweg liegt und nicht bei dir. Schön und gut Accespoints arbeiten zwar wie Repeater und somit ist die Anzahl der Hops eher untergeordnet (wenn nicht grade ein Routingprotokoll verwendet wird das HOPs beschränkt). Nur was schon scheiße ankommt kann nicht unbedingt richtig regeneriert werden. Weiteres Problem ist die Anzahl der User, Ethernet ist nicht kollisionsfrei. Bei steigender Länge des Übertragungsweges steigt auch die Zahl der potentiellen Störer im Frequenzband (2,4GHz).

OK, dann versuche ich hier mal den von Gorkon gestern anempfohlenen tracert als txt anzuhängen, soweit ich sehen kann geht der über weit mehr (als nur 3 WLAN-Points) bevor der überhaupt mit DSL in Berührung kommt.

Momentan liegt der Verdacht Nahe das der Inbound maßgeblich an den Aussetzern beteiligt ist, entweder der Limitter ist aktiv, dann hagelt es Disconnects oder es wurden explicit alle nicht HTML-Ports limittiert, oder halt beides. Sicher bietet WLAN nen besseren Ping als die Easybox mit seinem UMTS aber das WLAN läuft bei weitem unzuverlässiger als die Easybox, zumal Filesharing in dem WLAN ein absolutes DONT ist!

Die höhren sehen im Allgemeinen nicht sonderlich toll aus mit den Antwortzeiten. 12, 14, 15 sind doch etwas, ich sag mal grenzgängig. Muss zwar nicht unbedingt sein aber würd mich nicht wundern, wenn der Paketverlust an diesen Stellen auftritt.

Naja lieber ne stabile Verbindung die etwas langsamer ist als ne schnelle die hohen Paketverlust aufweist. Ist in dem Fall halt ne Kostenfrage.

tja 14 und 15 sind wenn ich das recht herauslese 1&1 Server, die nix mehr mit dem WLAN-Netz zu tun haben, wäre natürlich fatal wenn hier die Leistung beim eigentlichen ISP einbricht (möglich das die Leitung zum Meßzeitpunkt gnadenlos überlastet war?), die 12 ist IMHO die einzige Schwachstelle im WLAN-zu-DSL möglich das hier der Inbound+Limitter liegt.

Nebenbei sei noch erwähnt das die derzeitigen Wetterbedingungen nicht gerade ein Garant für das fehlerfreie Funktionieren eines WLAN-Netzes sind (s. Gewitter, Starkregen).

Naja ATM habe ich hier nur die Wahl zwischen UMTS-Netz (Ping min 140 durchschnitt 200) oder WLAN (Ping min 36, durchschnitt 50, dafür aber hoher Packetloss), was anderes mit hohen Übertragungsraten ist hier partout nicht zu bekommen :geheule

Punkt 10 ist der erste öffentliche Server alle anderen haben eine private Adresse und werden nicht im Internet vergeben.

Private Adressbereiche:

Klasse A 10.0.0.0 - 10.255.255.255
Klasse B 172.16.0.0 - 172.31.255.255
Klasse C 192.168.0.0 - 192.168.255.255

Habe auch mal n tracert gemacht 14 - 17 sind bei mir die gleichen Kisten jedoch mit deutlich besseren Latenzen. Würde daher vermuten, dass du mit deinem Tracert nur einen ungünsitgen Zeitpunkt erwischt hast.

Gibts keine Möglichkeit sich mit anderen Nutzern des gleichen Bürgernetzes in Verbindung zu setzen um das ganze zu Erörtern? Ich nehme mal an, dass du nicht der Einzige mit diesem Problem bist.

Vielleicht wäre es auch ne Maßnahme dir von 1 - 9 die Kisten zu nehmen und sie zu Pingen.

Ping Optionen:

-t - Sendet fortlaufend Ping-Signale zum angegebenen Host.
-a - Löst Adressen in Hostnamen auf.
-n - n Anzahl - Anzahl zu sendender Echoanforderungen
-l - Länge - Pufferlänge senden
-f - Setzt Flag für "Don't Fragment".
-i - TTL - Gültigkeitsdauer (Time To Live)
-v - TOS -Diensttyp (Type Of Service)
-r - Anzahl - Route für Anzahl der Abschnitte aufzeichnen
-s - Anzahl - Zeiteintrag für Anzahl Abschnitte
-j - Hostliste - "Loose Source Route" gemäß Hostliste
-k - Hostliste - "Strict Source Route" gemäß Hostliste
-w - Zeitlimit - Zeitlimit in Millisekunden für eine Rückmeldung

Am besten mit der Option -n um mehr Testpings zu senden.

ping -n 50 192.168.62.1

OSI-L8 schrieb:

Habe auch mal n tracert gemacht 14 - 17 sind bei mir die gleichen Kisten jedoch mit deutlich besseren Latenzen. Würde daher vermuten, dass du mit deinem Tracert nur einen ungünsitgen Zeitpunkt erwischt hast.

Zum Vergrößern anklicken....

Das Problem ist, das sich diesen ungünstigen Zeitpunkte zu häufen scheinen, und meist dann auftreten wenn ich auf eurem Server spiele *Mutmaßung*

OSI-L8 schrieb:

Gibts keine Möglichkeit sich mit anderen Nutzern des gleichen Bürgernetzes in Verbindung zu setzen um das ganze zu Erörtern? Ich nehme mal an, dass du nicht der Einzige mit diesem Problem bist.

Zum Vergrößern anklicken....

Habe ich schon mal gemacht, entweder die Jungs mauern oder meine Anbindung ist schlechter als ihre, da sie meine Probleme (bis auf die Funktionen und Auswirkungen des Limitters) nicht nachvollziehen können. Wiegesagt es gibt auch Zeiten wo ich ohne irgendwelche Probleme und Packetloss spielen kann, wochentags am Vormittag ca. 4:00 - 8:00 oder Wochenende nachmittag (ca. 14:00 - 17:00), wo das Aufkommen im Internet generell gering zu sein scheint *Annahme*. Die Öffis sind meist zu den Zeiten mit hohem bis maximalen Aufkommen, und entweder greift der Limitter, oder einzelne AP's haben max. Auslastung, oder was auch immer, bei all den vielen wenns und abers, ists dann doch besser das Spielen sein zu lassen.

OSI-L8 schrieb:

Vielleicht wäre es auch ne Maßnahme dir von 1 - 9 die Kisten zu nehmen und sie zu Pingen.

Ping Optionen:

-t - Sendet fortlaufend Ping-Signale zum angegebenen Host.
-a - Löst Adressen in Hostnamen auf.
-n - n Anzahl - Anzahl zu sendender Echoanforderungen
-l - Länge - Pufferlänge senden
-f - Setzt Flag für "Don't Fragment".
-i - TTL - Gültigkeitsdauer (Time To Live)
-v - TOS -Diensttyp (Type Of Service)
-r - Anzahl - Route für Anzahl der Abschnitte aufzeichnen
-s - Anzahl - Zeiteintrag für Anzahl Abschnitte
-j - Hostliste - "Loose Source Route" gemäß Hostliste
-k - Hostliste - "Strict Source Route" gemäß Hostliste
-w - Zeitlimit - Zeitlimit in Millisekunden für eine Rückmeldung

Am besten mit der Option -n um mehr Testpings zu senden.

ping -n 50 192.168.62.1

Zum Vergrößern anklicken....

Ich habe leider nur auf 1 und 2 Einfluss, und dort hatte ich schonmal angedeutet das der erste schon aller 1 Minute (ca.) eine Art Schluckauf hat und zwei hohe Pings meist gefolgt von einem Packetloss gemeldet werden. Deswegen kam ich auf den Trichter das hier evtl. auch die MTU-Werte ne Ursache sein könnte, wie bereits erwähnt, ich bekomme keine Fragmentation-Meldungen, sondern Zeitüberschreitungen??

Der Erste (Hausnetz) überstrahlt leider den Zweiten (dessen WLAN-Settings wir nicht ändern können, sonst legen wir das Ortsnetz lahm).

? Du müsstest eigentlich alle Kisten in der Reihe Pingen können, er traced sie ja auch. Ausnahme hier wäre wenn die Kisten ICMP deaktiviert haben.

Geschildertes Zeitverhalten klingt mir nach Kollisionen, was aber wiederum bedeutet das andere das selbe Problem haben. Wen meinst du mit Jungs? Das Service-Team oder andere Kunden? Wenn Kunden bei diesem Thema mauern haben sie entweder keine Ahnung und wollen ihre Unwissenheit verbergen oder Sie wissen genau was los ist und haben Vorteile, welche deine Problem verursachen. Letzteres halte ich aber für eher unwahrscheinlich, es sei den sie schlafen mit nem Techniker der ihnen ein günstiges Trafficshaping verpasst. Was dann aber auch wieder für geringeren Speed und nicht für Paketloss sprechen würde.

RaoulBogers schrieb:

Der Erste (Hausnetz) überstrahlt leider den Zweiten (dessen WLAN-Settings wir nicht ändern können, sonst legen wir das Ortsnetz lahm).

Zum Vergrößern anklicken....

Ihr sollt ja auch nichts ändern, sondern die Ursache suchen um dann gemeinsam mit dem Anbieter an aprobate Lösung zu finden.