Hi, ich hab seit ewigen Zeiten immer das selbe Problem daheim... UPC hat mir netterweise schon 2x das Modem getauscht aber ich denke mal es liegt nicht daran... (zumindest nicht am WAN Teil): Fast jeden Abend so ab 20 Uhr wird mein Internet daheim ur langsam. Alle HTTP Anfragen brauchen auf einmal viele Sekunden bis manchmal zum Timeout. Die Download Geschwindigkeit nimmt drastisch von über 3MB/s auf einige hundert KB/s ab. Ich hab mitlerweile den Verdacht das vllt ein Nachbar oder so dann auch sein WLAN aufdreht und mir in die Quere kommt... Kanal Wechseln (derzeit 8) hab ich schon auf alle möglichen weit entfernten Alternativen versucht, das bringt eher wenig. 5Ghz wäre eine Option, sprechen aber nicht alle Endgeräte und einen Mixed Mode kann das Modem/Router leider nicht. Könnte also sein das es eine Breitbandige IP Cam oder Babyfon oder so ist... ich kenn Leute bei denen sowas echt zur qual geworden ist und ein Kanalwechsel erfolgreich war, bei mir leider nicht :/ Ich hab jetzt gerade ein 30m Kabel quer durch die Wohnung gelegt und es ist auf Anhieb besser - somit wäre die nächste Anlaufstelle zum testen eben das WLAN. Jetzt wäre es ja durchaus interessant das mal zu debuggen... Da ich jetzt nicht umbedingt Lust habe am Laptop 24h Wireshark laufen zu lassen und mir nachher manuell anzusehen wann in welchem Netzwerk der meiste traffic los war, wollte ich fragen ob jemand eine bessere Alternative kennt - oder alternativ vllt doch eine Möglichkeit den Traffic gesniffed durch Wireshark oder ein anderes pcap fähiges tool pro Netzwerk pro Zeiteinheit (in meinem fall pro Stunde) zu plotten / auszugeben. LG
wenns ein Babyphone oder dergleichen ist hilft dir Wireshark ohnehin nichts. Fï¿œrs sniffen benï¿œtigst du auch einen passenden Apdater/treiber, sonst spielts keinen promiscious mode. Ganz einfaches troubleshooten geht schon mit nem Handy und ner App (WifiAnalyzer), die schlï¿œgt einem schon die passenden Kanï¿œle vor wenn man mit dem eigenen Netz assoziiert ist. Leider sind solche Probleme ohne richtiges Analysewerkzeug (zB einem CleanAir AP ;) ) schwer rauszufinden, die Funkfeuerjungs sind ja auch im metalab heimisch, wï¿œrd die mal fragen ob die vielleicht n Analyzer haben bzw mal vorbeikommen denn ohne die Fachkenntnisse hilft einem so ein Teil nï¿œmlich garnichts Am 04.03.2013 21:15, schrieb Sebastian Bachmann:
wï¿œre die nï¿œchste Anlaufstelle zum testen eben das WLAN. Jetzt wï¿œre es ja durchaus interessant das mal zu debuggen... Da ich jetzt nicht umbedingt Lust habe am Laptop 24h Wireshark laufen zu lassen und mir nachher manuell anzusehen wann in welchem Netzwerk der meiste traffic los war, wollte ich fragen ob jemand eine bessere Alternative kennt - oder alternativ vllt doch eine Mï¿œglichkeit den Traffic gesniffed durch Wireshark oder ein anderes pcap fï¿œhiges tool pro Netzwerk pro Zeiteinheit (in meinem fall pro Stunde) zu plotten / auszugeben
Im 2.4 Ghz Band tummelt sich leider ganz schön viel - von Videoübertragungssets (SAT-Rcv in anderem Zimmer als TV), über Babyphones, Kopfhörer, Mikrowellenherde, etc... bis zu Bluetooth. Diese Geräte können so breitbandig stören, dass Kanaländerungen kaum Verbesserung bringen werden. Ich habe billige chinesische Videolinks gesehen, die haben 2/3 des 2.4 ghz spektrums vollgemüllt, obwohl sie doch nur 8 Mhz für ein PAL Signal brauchen sollten/könnten. Ein Wireshark-Dump wird dir zur Untersuchung nicht viel bringen - weil du auf diesem Netzwerklayer die Schwierigkeiten die evt ein Layer darunter hat kaum sehen wirst. (ausser evt Verzögerungen und etwas Packetloss) Desweiteren kann TCP nicht sehr gut mit Packet-Loss in Funknetzen umgehen. Bei packetloss nimmt TCP an, dass eine Leitung/Router verstopft ist, und drosselt die Geschwindigkeit und sendet nochmal. Bei Funkverbindungen bringt das drosseln allerdings nichts, denn auch nur seltener gesendete Pakete haben die selbe Wahrscheinlichkeit wieder durch eine Störung verloren zu gehen. (dh. das TCP-Modell geht davon aus, dass Packetloss etwas mit der Häufigkeit der Pakete zu tun hat, was bei Funk nicht der Fall ist.) Eine gute Analyse deiner Funkumgebung könnte zb ein Tool wie Wi-Spy (oder jeder andere Spectrum Analyzer) liefern: http://www.metageek.net/products/wi-spy/ - aber leider nicht ganz billig. (Vielleicht finde ich ja meinen wieder) Lg, Adrian
mh also meine Intel im Laptop kann Monitor Mode, also die anderen Wlans seh ich schon im RAW Format und kann halt daraus schätzen wieviel traffic da drauf ist. mit airmon-ng kann die wunderbar sniffen *hrhr* klar mitm spectrum analyzer wäre alles besser... aber hab ich leider nicht. mehr als andere wlans ausschließen kann ich eh nicht, also wenn ich da nix finde dann muss ich wohl das kabel liegen lassen... lg Am 04.03.2013 21:49, schrieb Adrian Dabrowski:
Im 2.4 Ghz Band tummelt sich leider ganz schön viel - von Videoübertragungssets (SAT-Rcv in anderem Zimmer als TV), über Babyphones, Kopfhörer, Mikrowellenherde, etc... bis zu Bluetooth. Diese Geräte können so breitbandig stören, dass Kanaländerungen kaum Verbesserung bringen werden. Ich habe billige chinesische Videolinks gesehen, die haben 2/3 des 2.4 ghz spektrums vollgemüllt, obwohl sie doch nur 8 Mhz für ein PAL Signal brauchen sollten/könnten.
Ein Wireshark-Dump wird dir zur Untersuchung nicht viel bringen - weil du auf diesem Netzwerklayer die Schwierigkeiten die evt ein Layer darunter hat kaum sehen wirst. (ausser evt Verzögerungen und etwas Packetloss)
Desweiteren kann TCP nicht sehr gut mit Packet-Loss in Funknetzen umgehen. Bei packetloss nimmt TCP an, dass eine Leitung/Router verstopft ist, und drosselt die Geschwindigkeit und sendet nochmal. Bei Funkverbindungen bringt das drosseln allerdings nichts, denn auch nur seltener gesendete Pakete haben die selbe Wahrscheinlichkeit wieder durch eine Störung verloren zu gehen. (dh. das TCP-Modell geht davon aus, dass Packetloss etwas mit der Häufigkeit der Pakete zu tun hat, was bei Funk nicht der Fall ist.)
Eine gute Analyse deiner Funkumgebung könnte zb ein Tool wie Wi-Spy (oder jeder andere Spectrum Analyzer) liefern: http://www.metageek.net/products/wi-spy/ - aber leider nicht ganz billig. (Vielleicht finde ich ja meinen wieder)
Lg, Adrian
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
auch ï¿œd wenn man Tablets und phones benutzen will :) daher mal drauf hoffen das jemand zufï¿œlligerweiser einen Analyzer hat udn das Spielzeug mal ausprobieren will ;)...oder falls es mit dem LAN Kabel baulich kompliziert wird ->PowerLAN nutzen. Wï¿œr schon sehr groï¿œes Pech wenn du auch da Stï¿œrungen drauf hast. Am 04.03.2013 21:55, schrieb Sebastian Bachmann:
mh also meine Intel im Laptop kann Monitor Mode, also die anderen Wlans seh ich schon im RAW Format und kann halt daraus schï¿œtzen wieviel traffic da drauf ist. mit airmon-ng kann die wunderbar sniffen *hrhr*
klar mitm spectrum analyzer wï¿œre alles besser... aber hab ich leider nicht.
mehr als andere wlans ausschlieï¿œen kann ich eh nicht, also wenn ich da nix finde dann muss ich wohl das kabel liegen lassen...
lg
Am 04.03.2013 21:49, schrieb Adrian Dabrowski:
Im 2.4 Ghz Band tummelt sich leider ganz schï¿œn viel - von Videoï¿œbertragungssets (SAT-Rcv in anderem Zimmer als TV), ï¿œber Babyphones, Kopfhï¿œrer, Mikrowellenherde, etc... bis zu Bluetooth. Diese Gerï¿œte kï¿œnnen so breitbandig stï¿œren, dass Kanalï¿œnderungen kaum Verbesserung bringen werden. Ich habe billige chinesische Videolinks gesehen, die haben 2/3 des 2.4 ghz spektrums vollgemï¿œllt, obwohl sie doch nur 8 Mhz fï¿œr ein PAL Signal brauchen sollten/kï¿œnnten.
Ein Wireshark-Dump wird dir zur Untersuchung nicht viel bringen - weil du auf diesem Netzwerklayer die Schwierigkeiten die evt ein Layer darunter hat kaum sehen wirst. (ausser evt Verzï¿œgerungen und etwas Packetloss)
Desweiteren kann TCP nicht sehr gut mit Packet-Loss in Funknetzen umgehen. Bei packetloss nimmt TCP an, dass eine Leitung/Router verstopft ist, und drosselt die Geschwindigkeit und sendet nochmal. Bei Funkverbindungen bringt das drosseln allerdings nichts, denn auch nur seltener gesendete Pakete haben die selbe Wahrscheinlichkeit wieder durch eine Stï¿œrung verloren zu gehen. (dh. das TCP-Modell geht davon aus, dass Packetloss etwas mit der Hï¿œufigkeit der Pakete zu tun hat, was bei Funk nicht der Fall ist.)
Eine gute Analyse deiner Funkumgebung kï¿œnnte zb ein Tool wie Wi-Spy (oder jeder andere Spectrum Analyzer) liefern: http://www.metageek.net/products/wi-spy/ - aber leider nicht ganz billig. (Vielleicht finde ich ja meinen wieder)
Lg, Adrian
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wohl eher sehr großes Glück, falls es funktionieren sollte. Falls ja, dann darf man Kurzwellenfunk vergessen. Der läuft dann afaik nicht mehr (soooo gut). On 03/04/2013 10:06 PM, Robert Maier wrote:
auch öd wenn man Tablets und phones benutzen will :)
daher mal drauf hoffen das jemand zufälligerweiser einen Analyzer hat udn das Spielzeug mal ausprobieren will ;)...oder falls es mit dem LAN Kabel baulich kompliziert wird ->PowerLAN nutzen. Wär schon sehr großes Pech wenn du auch da Störungen drauf hast.
Am 04.03.2013 21:55, schrieb Sebastian Bachmann:
mh also meine Intel im Laptop kann Monitor Mode, also die anderen Wlans seh ich schon im RAW Format und kann halt daraus schätzen wieviel traffic da drauf ist. mit airmon-ng kann die wunderbar sniffen *hrhr*
klar mitm spectrum analyzer wäre alles besser... aber hab ich leider nicht.
mehr als andere wlans ausschließen kann ich eh nicht, also wenn ich da nix finde dann muss ich wohl das kabel liegen lassen...
lg
Am 04.03.2013 21:49, schrieb Adrian Dabrowski:
Im 2.4 Ghz Band tummelt sich leider ganz schön viel - von Videoübertragungssets (SAT-Rcv in anderem Zimmer als TV), über Babyphones, Kopfhörer, Mikrowellenherde, etc... bis zu Bluetooth. Diese Geräte können so breitbandig stören, dass Kanaländerungen kaum Verbesserung bringen werden. Ich habe billige chinesische Videolinks gesehen, die haben 2/3 des 2.4 ghz spektrums vollgemüllt, obwohl sie doch nur 8 Mhz für ein PAL Signal brauchen sollten/könnten.
Ein Wireshark-Dump wird dir zur Untersuchung nicht viel bringen - weil du auf diesem Netzwerklayer die Schwierigkeiten die evt ein Layer darunter hat kaum sehen wirst. (ausser evt Verzögerungen und etwas Packetloss)
Desweiteren kann TCP nicht sehr gut mit Packet-Loss in Funknetzen umgehen. Bei packetloss nimmt TCP an, dass eine Leitung/Router verstopft ist, und drosselt die Geschwindigkeit und sendet nochmal. Bei Funkverbindungen bringt das drosseln allerdings nichts, denn auch nur seltener gesendete Pakete haben die selbe Wahrscheinlichkeit wieder durch eine Störung verloren zu gehen. (dh. das TCP-Modell geht davon aus, dass Packetloss etwas mit der Häufigkeit der Pakete zu tun hat, was bei Funk nicht der Fall ist.)
Eine gute Analyse deiner Funkumgebung könnte zb ein Tool wie Wi-Spy (oder jeder andere Spectrum Analyzer) liefern: http://www.metageek.net/products/wi-spy/ - aber leider nicht ganz billig. (Vielleicht finde ich ja meinen wieder)
Lg, Adrian
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNQ41AAoJEDfL/pqB6n6NiiwQAMD5UEItpJUO1k3rebpI7F7a 1BBnl2DaEvo03AZVTYT5nF994OyouewMZbkPuo26Qvq3Qja74jUJ4QGKG+RzhWH8 iLGUbDfivb/p3gj3IOlY5D4t0nKKawNDkwR0GM8pOeRJv1/FnUJHniAvw4c3OML1 OKgTAwiLxgVHC/161q0uEY1gHQIRiyySVUB6fQfwP3594QFuECoKvnSc6BLEFgDT bIUvy5THZRRVSlk7qden00yva65e8QHltuLp8gDFfc0MZLNbgkjfu0SLvGgvV55A k6l8CB4Ja2HJoSRwtUX0Qcs8/DQND8Z7so8lnrm5YBWC21M2da6JP2P7h25fIlzN 1EUU8gg1AEbShENj57AyFR3E7BPgm/KrydaV4hpP25udwlKOO4IVvXsSV87YU5WH PKAbQvl/A3fe2SUTbhyTpyvY/iHtzGIOizyDkqORgHcP4SjW+ldCGBduZ0ugkkKa r6iQhfZmLSnlsbApgW5xmtD+5pWc/Bl0PiJH11Wps47uPMF4Zd+M/PhMSkaw711o yQDm17CVlMYcaIXShmSA+dQXS4UKVuQ6INa1WmX/QQ0vh8muIurEavPNpckfnqk7 gdUIGhoiL7DqtzV31eVvYtjSI1Wxku+ZTB86IbYe8Sandn93m0vdQ0Mw11ArL1pO ivhCj5FT1vn0/Wk2gQGd =dOWi -----END PGP SIGNATURE-----
On 04.03.13 21:55, Sebastian Bachmann wrote:
mh also meine Intel im Laptop kann Monitor Mode, also die anderen Wlans seh ich schon im RAW Format und kann halt daraus schätzen wieviel traffic da drauf ist. mit airmon-ng kann die wunderbar sniffen *hrhr*
klar mitm spectrum analyzer wäre alles besser... aber hab ich leider nicht.
wenn du Monitor Mode schon hast: http://br1.einfach.org/tech/horst/ kann die "Gesamte Kanal-Last" die von 802.11 Quellen in einem Kanal stammt aufsummieren: http://br1.einfach.org/blog/wp-content/gallery/horst-screenshots/horst-spec1... Achte auf die orangefarbenen Balken. Ist ein optimistischer Wert (also Real-Last ist immer höher als angezeigte Last) aber vielleicht trotzdem hilfreich. Ich nehm an Kismet kann das mittlerweile auch schon, hab's aber schon länger nicht mehr verwendet. Wenn Du keine 802.11 Quellen als Ursache festmachen kannst: Ich hab so ein wi-spy (2.4GHz only, external antenna) vor zwei Jahren gekauft, kann ich Dir borgen. Ich konnte damit aber nur relativ starke (non-802.11) Störer gut als solche erkennen. -paul
On 2013-03-04 21:15, Sebastian Bachmann wrote:
Hi, ich hab seit ewigen Zeiten immer das selbe Problem daheim... UPC hat mir netterweise schon 2x das Modem getauscht aber ich denke mal es liegt nicht daran... (zumindest nicht am WAN Teil):
Da ja DOCSIS auch eine shared medium ist, wuerd ich mal auzuschliessen versuchen, ob's am WiFi oder am Uplink liegt. Wenn z.B. ping mit unterschiedlichen packetgroesse an die IP addresse des WiFi routers komische RTTs haben, liegts am WiFi. Wenn das zwischen 18:00 und 20:20 sich nicht aendert, ist's das Cable. ich wuerd die RTT zeiten von einem a) ping -s 10 <STA IP ADDR> als basiswert nehmen und dann b) ping -s 300 <STA IP ADDR> und c) ping -s 600 <STA IP ADDR> machen. wenn rtt(a) vor 20 uhr << rtt(a) nach 20 uhr, dann isses das WiFi, sonst das kabel wenn rtt(c) != 2*rtt(b) (so ungefähr halt) dann ists das WiFi sonst das cable. ps: Es gab mal eine utility, die hat ein traceroute gemacht und dann mit hilfe von unterschiedlichen packetgroessen und deren RTTs die bandbreite zwischen den einzelnen routern ausgerechnet. Weis leider nimmer wie das geheisen hat. War einigermassen genau, ausser wenn asymetrisches routing beteiligt war. dann hat's versagt.
Am 05.03.2013 17:13, schrieb Michael Lausch:
On 2013-03-04 21:15, Sebastian Bachmann wrote:
Hi, ich hab seit ewigen Zeiten immer das selbe Problem daheim... UPC hat mir netterweise schon 2x das Modem getauscht aber ich denke mal es liegt nicht daran... (zumindest nicht am WAN Teil):
Da ja DOCSIS auch eine shared medium ist, wuerd ich mal auzuschliessen versuchen, ob's am WiFi oder am Uplink liegt. ja nur ich bin jetzt seit gestern nur mit dem kabel drin und hab wieder eine stabile verbindung und 92Mbit Download...
ich wert mal den horst probieren :)
ps: Es gab mal eine utility, die hat ein traceroute gemacht und dann mit hilfe von unterschiedlichen packetgroessen und deren RTTs die bandbreite zwischen den einzelnen routern ausgerechnet. Weis leider nimmer wie das geheisen hat. War einigermassen genau, ausser wenn asymetrisches routing beteiligt war. dann hat's versagt. ja... kommt mir bekannt vor, weiß ich aber gerade auch nicht...
lg
need for 13 netzwerkkarten :D naja also ein kurzer test zeigt das hier alles ziemlich "verseucht" ist... channel 4 scheint der einzige zu sein auf dem wenig los ist... das problem ist ja mehr oder weniger das ich auf jedem channel mal ein paar minuten bleiben sollte und nicht die ganze zeit hoppen, das bringt zwar ein halbwegs gutes ergebnis aber aufspüren tut man damit eben eher nix... ich bleib mal dran und werd an einem freien abend das sicher mal genau unter die lupe nehmen! der horst ist da ziemlich cool finde ich. danke und lg! Am 05.03.2013 22:44, schrieb Sebastian Bachmann:
Am 05.03.2013 17:13, schrieb Michael Lausch:
On 2013-03-04 21:15, Sebastian Bachmann wrote:
Hi, ich hab seit ewigen Zeiten immer das selbe Problem daheim... UPC hat mir netterweise schon 2x das Modem getauscht aber ich denke mal es liegt nicht daran... (zumindest nicht am WAN Teil):
Da ja DOCSIS auch eine shared medium ist, wuerd ich mal auzuschliessen versuchen, ob's am WiFi oder am Uplink liegt. ja nur ich bin jetzt seit gestern nur mit dem kabel drin und hab wieder eine stabile verbindung und 92Mbit Download...
ich wert mal den horst probieren :)
ps: Es gab mal eine utility, die hat ein traceroute gemacht und dann mit hilfe von unterschiedlichen packetgroessen und deren RTTs die bandbreite zwischen den einzelnen routern ausgerechnet. Weis leider nimmer wie das geheisen hat. War einigermassen genau, ausser wenn asymetrisches routing beteiligt war. dann hat's versagt. ja... kommt mir bekannt vor, weiß ich aber gerade auch nicht...
lg
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
On 05.03.13 23:10, Sebastian Bachmann wrote:
naja also ein kurzer test zeigt das hier alles ziemlich "verseucht" ist... channel 4 scheint der einzige zu sein auf dem wenig los ist... das problem ist ja mehr oder weniger das ich auf jedem channel mal ein paar minuten bleiben sollte und nicht die ganze zeit hoppen, das bringt zwar ein halbwegs gutes ergebnis aber aufspüren tut man damit eben eher nix...
Übersprechen zwischen den Kanälen kann die Horst Methode nicht erfassen. Ein nicht belegter Kanal ist nur dann tatsächlich "leer" wenn der nächste (laut Horst) stark benützte Kanal 25MHz (5 Kanalrasterschritte) davon entfernt ist.
ich bleib mal dran und werd an einem freien abend das sicher mal genau unter die lupe nehmen! der horst ist da ziemlich cool finde ich.
Das Phänomen dass Du im ersten Post beschrieben hast "Alle HTTP Anfragen brauchen auf einmal viele Sekunden" deutet für mich eigentlich nicht direkt auf 802.11-like Interferenz hin. Die hat doch meist "zufälligeren" Charakter... -paul
On Wed, 6 Mar 2013 11:18:05 +0100, Paul Fuxjaeger <fuxjaeger@ftw.at> wrote:
Übersprechen zwischen den Kanälen kann die Horst Methode nicht erfassen.
Ein nicht belegter Kanal ist nur dann tatsächlich "leer" wenn der nächste (laut Horst) stark benützte Kanal 25MHz (5 Kanalrasterschritte) davon entfernt ist.
frei ist bei mir sowieso nix... also ich hab überall was drauf nur Kanal 4 ist eben rel. leer im Gegensatz zu anderen...
Das Phänomen dass Du im ersten Post beschrieben hast "Alle HTTP Anfragen
brauchen auf einmal viele Sekunden" deutet für mich eigentlich nicht direkt auf 802.11-like Interferenz hin. Die hat doch meist "zufälligeren" Charakter...
Auffällig ist halt das es bei der verwendung vom Kabel schlagartig besser ist... Entweder ist der Unterschied Kabel/WLAN so groß, dass mein Grundproblem in den Hintergrund gerrückt wird und ich quasi nur mehr einen Flaschenhals habe, oder es legt eben am wireless... lg
Teilnehmer (6)
-
Adrian Dabrowski -
Christian Inci -
Michael Lausch -
Paul Fuxjaeger -
Robert Maier -
Sebastian Bachmann