From (spam-protected) Tue Nov 25 16:50:30 2008 From: (spam-protected) (Markus Kittenberger) Date: Tue, 25 Nov 2008 16:50:30 +0100 Subject: [Dump] Welcome - Happy Dumping Message-ID: <4095b6c00811250750m1896ba3bu66ee9fcc1cab92d7@mail.gmail.com> After an idea of Harald this new ml was created,.. The mailinglist archive is here http://lists.funkfeuer.at/pipermail/dump/ and some reasons for this mailinglist are there http://lists.funkfeuer.at/mailman/listinfo/dump if you like the reasons or find some more reasons, subscribe yourself (also with the above link) and dump your ideas,.. Happy Dumping! Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Tue Nov 25 16:57:08 2008 From: (spam-protected) (Markus Kittenberger) Date: Tue, 25 Nov 2008 16:57:08 +0100 Subject: [Dump] TCP Payload im SYN packet Message-ID: <4095b6c00811250757i3969d767p583fbc60c355df53@mail.gmail.com> sind eigentlich laut standard erlaubt,.. (also steht fast nix derartig assymetrisch grossen tcp pings im wege) d.h. es ist erlaubt (laut rfc) mit dem syn packet bereits daten mitzuschicken,. diese sollten dann (laut rfc) am ziel gebuffered werden , und sobald das ack zum syn-ack auch eintrifft müssten diese daten (dem listening server) zugestellt werden, jedoch keinsfalls vorher,.. lediglich bsd macht das so, linux (2.4 und 2.6) haben angst vor dos (das buffern) und dropped somit die daten silently, solaris verwirft so ein syn packet jedoch ganz, und zu windows hab ich nix gefunden,. d.h. um auf diese weise auch nutzdaten zu schicken, müsste man den linux kernel patchen, aber um grosse testpakete klein geackt zu kriegen ist es genau das richtige,.. werd jedenfalls mal mit raw_sockets rumspielen, mal schaun obs mir spass macht ip und tcp checksums selber zu generieren,.. (-; lg Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Wed Nov 26 22:48:34 2008 From: (spam-protected) (Harald Geyer) Date: Wed, 26 Nov 2008 22:48:34 +0100 Subject: Neue Mailingliste für 0xff Message-ID: Hi! Es gibt jetzt eine neue Mailingliste für Funkfeuer, die helfen soll das technische Wissen, das leider allzu oft in privaten Mailboxen vermodert, zu befreien über das Internet zugänglich zu machen: http://lists.funkfeuer.at/mailman/listinfo/dump Gedacht ist das so, dass ansich persönliche Diskussionen per cc an die Dump-Liste geschickt werden können, damit sie dort archiviert werden. Vielen Dank an Markus für das Einrichten der Liste! Details: * Jeder kann sich anmelden. * Alle subscriber können posten. * Das Archiv ist öffentlich. * Die Dump-Liste soll kein Ersatz für Discuss, Wien, etc. sein: Themen, die öffentlich diskutiert gehören, gehören nicht auf die Dump-Liste, sondern auf die dafür vorgesehene ML. - Es wäre allerdings nett, wenn Diskussionen nicht willkürlich zwischen den Listen hinundher verschoben werden, damit Threads halbwegs nachvollziehbar bleiben. Im Zweifelsfall Dump im Cc: lassen. * Es wird von niemandem erwartet, dump regelmäßig zu lesen. Leute, von denen man sich eine Reaktion erwartet, mit denen man diskutieren will, gehören ins To: - die Dump-Liste ins Cc: * Antworten an die Autoren von dump Mails sind ok, aber es gibt keine Garantie dafür, dass diese darauf eingehen. Ist ja schließlich schon nett, dass sie ihr Wissen überhaupt veröffentlichen. * Es gibt keine Einschränkung in welcher Sprache Mails auf der Dump-Liste geschrieben werden. * Die Dump-Liste ist potentiell high traffic. Es wird empfohlen, die Mails automatisch in einen eigenen Folder zu sortieren oder überhaupt nur das Listenarchiv zu verwenden. Es kann sich jeder, der an die Dump-Liste schreiben will, anmelden und dann aber die Mailzustellung deaktivieren. * Die Dump-Liste ist ein Experiment. Liebe Grüße, Harald From (spam-protected) Wed Nov 26 23:22:59 2008 From: (spam-protected) (Markus Gschwendt) Date: Wed, 26 Nov 2008 23:22:59 +0100 Subject: [Dump] =?iso-8859-1?q?Neue_Mailingliste_f=FCr_0xff?= In-Reply-To: References: Message-ID: <1227738179.6970.180.camel@nexi.runout.at> On Wed, 2008-11-26 at 22:48 +0100, Harald Geyer wrote: > Hi! > > Es gibt jetzt eine neue Mailingliste für Funkfeuer, die helfen soll > das technische Wissen, das leider allzu oft in privaten Mailboxen > vermodert, zu befreien über das Internet zugänglich zu machen: > > http://lists.funkfeuer.at/mailman/listinfo/dump > > Gedacht ist das so, dass ansich persönliche Diskussionen per cc an die > Dump-Liste geschickt werden können, damit sie dort archiviert werden. ... na gut, dann wär ich aber dafür die discuss-liste aufzulösen. stehen eh die gleichen leute drin wie auf der wien-liste. markus -- Markus Gschwendt, +436506550055 www.runout.at www.gschwendt.at www.nangaparbat.at From (spam-protected) Thu Nov 27 16:27:59 2008 From: (spam-protected) (Harald Geyer) Date: Thu, 27 Nov 2008 16:27:59 +0100 Subject: [Dump] wph // devserver Message-ID: Hi! Ich bin gerade dabei mir noch einmal das wph anzuschauen, wobei's nicht ganz einfach ist, hinzukommen. Das scheint mir aber ein Problem mit dem roofnode-devserver setup zu sein. Verstehe allerdings selber nicht, was das Problem ist: roofnode und devserver haben beide Routen (mit ca. gleichen geringen Pfadkosten) über das selbe gateway. Trotzdem gehen alle paar Sekunden pings durch und dann doch wieder nicht. Insgesamt schaut es für mich so aus, dass immer, wenn die Route über den roofnode geht, dann ist es ok aber wenn die Route über den devserver geht, dann krieg ich: >From devbridge.tunnel.wien.funkfeuer.at (193.238.157.147) icmp_seq=264 Destination Host Unreachable Ich kann's mir nicht anders erklären, als dass der devserver versucht, das wph über eine Interfaceroute statt über die Hostroute zu erreichen; kann das denn mit unglücklich gewählten Metrikwerten passieren? Möglicherweise ist das auch der Grund, warum ich k10 in ein blackhole verwandelt habe... Nachdem der olsrd teilweise irrsinnig hohe Metriken auf Hostrouten einträgt, bin ich bisher davon ausgegangen, dass die Netzmaske immer gewinnt - muss mich da einmal schlau machen, wie Metriken und Netzmasken wirklich zusammenspielen ... Liebe Grüße, Harald From (spam-protected) Thu Nov 27 20:02:00 2008 From: (spam-protected) (Markus Kittenberger) Date: Thu, 27 Nov 2008 20:02:00 +0100 Subject: [Dump] wph // devserver In-Reply-To: References: Message-ID: <4095b6c00811271102j6fa58356j725c9d4ca8312900@mail.gmail.com> der devserver hat ne unreachable route für die freenet ipranges der roofnode hatte früher diese unreachable rules jatzt aber nimma und hat nun stattdessen alle freenet ip zum devserver wenn er keine more specific route (d.h. hostroute) hat d.h. wenn beide keine route zum ziel haben kriegst das unreachable nun nimma vo roofnode sondern vom devVserver, so wie du es beobachtet hast,.. würde aber nur der roofndoe kein route haben, der devserver aber schon, würde es tadellos funktioneren (das ist der sinn dieses setups, der olsr am roofnode kann komplett ausfallen und bis auf den einen hop mehr im traceroute würde es nichtmal auffallen,..) lg Markus 2008/11/27 Harald Geyer > Hi! > > Ich bin gerade dabei mir noch einmal das wph anzuschauen, wobei's nicht > ganz einfach ist, hinzukommen. Das scheint mir aber ein Problem > mit dem roofnode-devserver setup zu sein. Verstehe allerdings selber > nicht, was das Problem ist: > > roofnode und devserver haben beide Routen (mit ca. gleichen geringen > Pfadkosten) über das selbe gateway. Trotzdem gehen alle paar Sekunden > pings durch und dann doch wieder nicht. Insgesamt schaut es für mich > so aus, dass immer, wenn die Route über den roofnode geht, dann > ist es ok aber wenn die Route über den devserver geht, dann krieg > ich: > From devbridge.tunnel.wien.funkfeuer.at (193.238.157.147) icmp_seq=264 > Destination Host Unreachable > > Ich kann's mir nicht anders erklären, als dass der devserver versucht, > das wph über eine Interfaceroute statt über die Hostroute zu erreichen; > kann das denn mit unglücklich gewählten Metrikwerten passieren? > > Möglicherweise ist das auch der Grund, warum ich k10 in ein blackhole > verwandelt habe... > > Nachdem der olsrd teilweise irrsinnig hohe Metriken auf Hostrouten > einträgt, bin ich bisher davon ausgegangen, dass die Netzmaske immer > gewinnt - muss mich da einmal schlau machen, wie Metriken > und Netzmasken wirklich zusammenspielen ... > > Liebe Grüße, > Harald > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Fri Nov 28 16:09:47 2008 From: (spam-protected) (Harald Geyer) Date: Fri, 28 Nov 2008 16:09:47 +0100 Subject: [Dump] Layer-2 debugging am Heuberg Message-ID: Hi! Ich hab' jetzt einmal (ohne was an deinen Einstellungen zu ändern, also immer noch alles auf 11Mbit) am heusued_v4 den garten94 gesniffed mit: tcpdump -n -i prism0 -s 300 -e | grep funkfeuer (das sollte mir alle beacons von Funkfeuer-Routern anzeigen) Interessting fact: Vom garten94 kommt kein einziges Beacon an! Dafür seh' ich: 14:06:42.000438 BSSID:4e:fe:52:36:2e:65 DA:ff:ff:ff:ff:ff:ff SA:00:18:84:81:d3:2d Beacon (v1.freiesnetz.www.funkfeuer.at) [1.0* 2.0* 5.5* 6.0 9.0 11.0* 12.0 18.0 Mbit] IBSS CH: 1 14:06:41.787440 BSSID:26:a4:05:7b:2b:d8 DA:ff:ff:ff:ff:ff:ff SA:00:12:17:d4:72:2f Beacon (v4.freiesnetz.www.funkfeuer.at) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] IBSS CH: 4 goz19omni.io.wien.funkfeuer.at 14:18:09.925602 BSSID:26:a4:05:7b:2b:d8 DA:ff:ff:ff:ff:ff:ff SA:00:1e:e5:5b:ba:c5 Beacon (v4.freiesnetz.www.funkfeuer.at) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] IBSS CH: 4 v1.gast5.wien.funkfeuer.at Interessant ist auch, welche wifi raten von den Nodes unterstützt werden ... Hab' jetzt dann noch versucht, die andere Richtung zu sniffen (also am garten94 auf der Fonera tcpdump installiert und mit # wlanconfig ath1 create wlandev wifi0 wlanmode monitor # ifconfig ath1 up ein device im monitor mode angelegt. Allerdings zeigt mir dort # tcpdump -n -i ath1 -s 300 -e überhaupt keine 802.11 Header und somit auch keine Management Frames an! Auf meiner eigenen FoneraBridge geht es tadellos. Weiß nicht, was da los ist ... hast du da beim Kompilieren irgendwas deaktiviert? iwconfig behauptet jedenfalls, dass das interface sehr wohl im monitor mode sei ... So, das ist alles was ich heute herausgefunden hab'. Ansonsten sind die Foneras zum Timing-Sniffen super, weil madwifi die HW-Timestamps mitschickt - und die haben wirklich Mikrosekundenauflösung. Liebe Grüße, Harald From (spam-protected) Fri Nov 28 17:09:28 2008 From: (spam-protected) (Harald Geyer) Date: Fri, 28 Nov 2008 17:09:28 +0100 Subject: [Dump] Layer-2 debugging am Heuberg In-Reply-To: <4095b6c00811280724n5573e9cbq47e0dd09923c9c9d@mail.gmail.com> References: <4095b6c00811280724n5573e9cbq47e0dd09923c9c9d@mail.gmail.com> Message-ID: > sorry (-; > > hab SSID hide auf beiden seiten eingeschalten, [...] Na, dann wundert's mich aber nicht, dass der Link irgendwelche komischen Probleme macht... ich glaub' es gibt keine korrekt konfigurierten Knoten, die das Problem haben. BTW, wo hast du das bei der Fonera eingestellt? - Ich hab' vorsichtshalber noch extra in /etc/config/wireless nachgeschaut und *dort* steht es aber nicht drinnen! Hab' versucht, das jetzt einmal manuell zu ändern (und auch gleich positives feedback gekriegt) aber sniffen kann ich die Beacons noch immer nicht... (Dafür aber sonst Blödsinn gefunden, wie einen v4....funkfeuer.at Probe Response der behauptet, der ist auf Kanal 23) Was aber auch immer noch unklar ist, ist warum ich auf der Fonera auf ath1 keine 802.11 Header bekomm! Immerhin findest sich folgendes im log ... Jan 1 00:12:09 OpenWrt user.warn kernel: ath_rate_minstrel: no rates for 06:18:84:83:08:c1? Die MAC-Adresse ist die von ath1. Liebe Grüße, Harald From (spam-protected) Sat Nov 29 00:51:42 2008 From: (spam-protected) (Harald Geyer) Date: Sat, 29 Nov 2008 00:51:42 +0100 Subject: [Dump] Timingprobleme In-Reply-To: <4095b6c00811281501l2577504bi46ed984cc3376ee6@mail.gmail.com> References: <4095b6c00811280510w105c621bqd77d9a8a9e7248dc@mail.gmail.com> <4095b6c00811280703m6fe8d977g8c1359f1ee1649d3@mail.gmail.com> <4095b6c00811281215uad7af06qf8737a010f956fa9@mail.gmail.com> <4095b6c00811281421m1c7b026eu60d31b30cf38cf44@mail.gmail.com> <4095b6c00811281501l2577504bi46ed984cc3376ee6@mail.gmail.com> Message-ID: > > Aber bis vor einer Stunde oder so hat der heusued trotz mehrfachem > > > wifi down; wifi up keine Beacons gesendet. > > hast du auch vorhin mal den router ganz restartet? Natürlich nicht. > mitunter bocken die "alten" recht lang rum, wenn man nur wifi up down > macht,.. Scheint so. - Wobei ich nicht so recht verstehe warum. Naja, dafür hat inzwischen die Fonera beschlossen vorerst keine weiteren Beacons zu senden... *seufz* oder eher: WTF? > > Gerade hab' ich gesehen, das er es jetzt doch tut, also werd' > > > ich jetzt vielleicht noch etwas machen ... > > evt. wars aber bis jetzt auch unerfindlichen gründen auch nicht möglich > sie > zu empfangen!?, denn wie gesagt der link hat irgendein problem, und das > kannauch schlichtweg fieser noise sein,.. Naja, er hat ja genug andere empfangen, noch dazu auf allen möglichen Kanälen ... mit Antenne 1 (Kanal 4) und Antenne 2 (Kanal 10) - ganz reife Leistung für eine Fonera... ;) Aber hab' jetzt doch ein bissi was gefunden: 23:53:01.976462 BSSID:26:a4:05:7b:2b:d8 DA:ff:ff:ff:ff:ff:ff SA:00:18:84:83:08:c1 Beacon (v4.heuberg.funkfeuer.at) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] IBSS CH: 4 (Ein Beacon, das die Fonera geschickt hat) 08:36:06.087663 18437732704132695038us tsft short preamble 1.0 Mb/s 2427 MHz (0x0480) -78dB signal -96dB noise antenna 1 18dB signal BSSID:26:a4:05:7b:2b:d8 DA:ff:ff:ff:ff:ff:ff SA:00:18:f8:48:ef:7b Beacon (v4.heuberg.funkfeuer.at) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] IBSS CH: 4 (Ein Beacon, das der heusued geschickt hat) Wie du siehst, haben sie nur die Raten 1.0* 2.0* 5.5* 11.0* 18.0 gemeinsam. Insofern vorstellbar, dass der g-modus Probleme macht. Now the really funky stuff: Wenn ich auf dem heusued 18Mbit einstell (macht er sofort und anstandslos) und 'ping heusued -s 200' mach, dann seh ich RTS frames die mit 12Mbit gesendet werden! - Und es kommt nie ein CTS zurück! Was ich dabei allerdings gerade nicht verstehe: Das RTS kommt vom heusued, aber der ist ja laut seiner Beacons der Meinung, dass er nicht mit 12 Mbit senden will (warum auch immer - wl status zeigt es als supported an) und es dann doch tut. Anscheinend ist die Fonera davon dann so verwirrt, dass sie es nicht schafft, darauf zu antworten oder so ... Naja, das ist noch ein sehr grobes Modell, was da passiert. Da sind noch mehr tests notwendig, aber das eigentlich überraschende dabei ist, dass die FFF mit 12 Mbit RTS sendet, obwohl sie auf 18 Mbit eingestellt ist (was sie sonst auch befolgt). Das ist zumindest einmal ein Symptom, das man relativ leicht auf anderen Problemlinks überprüfen kann. Insofern könnte diese Erkenntnis das künftige Debuggen erleichtern ... Harald From (spam-protected) Sat Nov 29 01:32:33 2008 From: (spam-protected) (Harald Geyer) Date: Sat, 29 Nov 2008 01:32:33 +0100 Subject: [Dump] Timingprobleme In-Reply-To: <4095b6c00811281615r470459deucee00e1094a317f8@mail.gmail.com> References: <4095b6c00811280703m6fe8d977g8c1359f1ee1649d3@mail.gmail.com> <4095b6c00811281215uad7af06qf8737a010f956fa9@mail.gmail.com> <4095b6c00811281421m1c7b026eu60d31b30cf38cf44@mail.gmail.com> <4095b6c00811281501l2577504bi46ed984cc3376ee6@mail.gmail.com> <4095b6c00811281615r470459deucee00e1094a317f8@mail.gmail.com> Message-ID: > > Aber hab' jetzt doch ein bissi was gefunden: > > 23:53:01.976462 BSSID:26:a4:05:7b:2b:d8 DA:ff:ff:ff:ff:ff:ff > > SA:00:18:84:83:08:c1 Beacon (v4.heuberg.funkfeuer.at) [1.0* 2.0* 5.5* > > 11.0* 6.0 9.0 12.0 18.0 Mbit] IBSS CH: 4 > > (Ein Beacon, das die Fonera geschickt hat) > > was für beacons schickt denn die fonera wenn du ihr 24mbit einstellst? > vmtl die gleichen ... Vermutlich wieder einmal gar keine ... SCRN > was wird im beacan onnounct was sie empfangen kann und oder was sie senden > wird/kann, oder beides? Naja, eigentlich sollten die Beacons ja das Netz announcen, also vermutlich berücksichtigt sie fremde Beacons und sonst halt was sie selber empfangen kann. Announcen was sie senden kann, macht wohl nicht viel Sinn ... > > Now the really funky stuff: > > Wenn ich auf dem heusued 18Mbit einstell (macht er sofort und anstandslos > ) > > und 'ping heusued -s 200' mach, dann seh ich RTS frames die mit > > 12Mbit gesendet werden! - Und es kommt nie ein CTS zurück! > > wenn du kleine pings machst dann gehen die alle auf 18mbit,oder? Ja. > was für eine bitrate haben denn die beacons in dem netz dann? Beacons haben immer 1Mbit/s egal was du machst. > hmm, aber eigentlich hat die fonera ja behauptet das sie 12mbit mag, also > warum soll ihr der linksys nicht die freude machen,.. (-; > btw. was stellt eigentlich die wlanbasis rate ein in der fff? > die bitrate der beacons,.. Ist das nicht eh nur die Ãœbertragungsrate? Ich verwend' immer das nvram ... > > Was ich dabei allerdings gerade nicht verstehe: Das RTS kommt vom > > heusued, aber der ist ja laut seiner Beacons der Meinung, dass er > > nicht mit 12 Mbit senden will (warum auch immer - wl status zeigt > > es als supported an) und es dann doch tut. > > hmm vmtl falsche beacons, paber wl status zeigt afaik immer alles als > supportet an auch wenn ich nur b oder nur g modus einstell, also vmtl > falsches wl-status,.. Möglich... > ändern sich die beacons eigentlich wenn du z.B.: nur g-modus in der ff > einstellst? Hm, müsste man probieren. Das Problem ist halt, dass die meiste Zeit gar keine Beacons geschickt werden bei deinen Links. Aber ich werd' das einmal bei mir ausprobieren ... Liebe Grüße, Harald From (spam-protected) Sat Nov 29 14:49:46 2008 From: (spam-protected) (Markus Kittenberger) Date: Sat, 29 Nov 2008 14:49:46 +0100 Subject: [Dump] gestern,.. Message-ID: <4095b6c00811290549i6cf36770t86d4d57860f11734@mail.gmail.com> gestern nacht sind mir scheinbar 2 dinge aufgefallen,.. als heusued wiedermal keine beacons sendete als er auf richitger/gleicher bssid eingestellt ist, und sehr viele sendete anchdem ich heusued und garten94 auf ne andere bssid geändert hab, wodurch er plötzlich kommnunikativ wurde,.. heute beim zrueckaendern der bssid, ergab sich jedoch nicht der gegenteilige effekt, heusued bleib weiter kommunikativ werd das wohl heut abend nochmal überprüfen,.. weiters schien mir die beacon size begrenzt, da bei längeren ssids die wlan-rates fehlten,.. das lag aber nur am tcpdump auf der fonera, welches mit 96 byte capture size lief, und das war zuwenig für lange ssids, da das beacon da dann über 150 byte hat, bei 40byte langer bssid wärens dann maximal 170byte beacons!, allerdings 110 byte capture size reichen um die wlan-rates drin zu haben (mit ssid v4.heu.www.funkf.. ) p.s. wie änderst du eigentlich den monitor type aufm linksys? oder verwendest du externer tools und nicht tcpdump (-; lg MArkus -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Sat Nov 29 16:40:29 2008 From: (spam-protected) (Markus Kittenberger) Date: Sat, 29 Nov 2008 16:40:29 +0100 Subject: [Dump] Timingprobleme In-Reply-To: References: <4095b6c00811281501l2577504bi46ed984cc3376ee6@mail.gmail.com> <4095b6c00811281615r470459deucee00e1094a317f8@mail.gmail.com> <4095b6c00811281656g5525ea85j30a48cd0d5dd2ce5@mail.gmail.com> <4095b6c00811290702o3a5619f9mea81173afca48cd5@mail.gmail.com> Message-ID: <4095b6c00811290740m36bf8aedrc20fc1eecbe6b3cf@mail.gmail.com> hab grad noch was SEHR spannendes entdeckt heusued sit auf 11mbit rate und mrate gartenfon ist auf 11mrate und auto rate hab ich auf beiden die gleiche bssid und essid kann ich am garten94linksys per wget via fonerabridge von heusued mit 590KB/sek runterladen hab ich jedoch unterschiedliche essids!!! (dank wiedermal an emien tippfehler (-;) dann nur 300KB/sek war inschiwsch schon zweimal vice versa reproduzierbar!! lg MArkus On Sat, Nov 29, 2008 at 4:27 PM, Harald Geyer wrote: > > > hmm ist dir schon aufgefallen das die anzahl der wl rates gleich ist > > > > [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] > > > > [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] > > > > evt. amcht das auslassen auf den linksys sinn,.. k.a. > > Ja, ist mir ansich aufgefallen. Und hab' mir auch gedacht, dass es > sinnvoller ist 6.0 und 9.0 wegzulassen (wenn man eh 5.5 und 11.0 hat) > als die Hohen. > > Aber weiß nicht, was ich mit diesem Wissen machen soll - außer in der > 802.11 spec nachzulesen ... > > Was ich viel spannender finde ist, dass der Linksys mit 12.0 RTS sendet, > obwohl er 18.0 eingestellt hat ... > > Liebe Grüße, > Harald > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Sat Nov 29 16:50:05 2008 From: (spam-protected) (Markus Kittenberger) Date: Sat, 29 Nov 2008 16:50:05 +0100 Subject: [Dump] Timingprobleme In-Reply-To: <4095b6c00811290740m36bf8aedrc20fc1eecbe6b3cf@mail.gmail.com> References: <4095b6c00811281501l2577504bi46ed984cc3376ee6@mail.gmail.com> <4095b6c00811281615r470459deucee00e1094a317f8@mail.gmail.com> <4095b6c00811281656g5525ea85j30a48cd0d5dd2ce5@mail.gmail.com> <4095b6c00811290702o3a5619f9mea81173afca48cd5@mail.gmail.com> <4095b6c00811290740m36bf8aedrc20fc1eecbe6b3cf@mail.gmail.com> Message-ID: <4095b6c00811290750m772f73fblb785b1c04e50a341@mail.gmail.com> aber leider keine 3mal repoduzierbar )-; trotzdem komisch warum der durchsatz um das so genau doppelte schwankte das der heusued ja eigentlich auf fixed rate ist,.. lg Markus On Sat, Nov 29, 2008 at 4:40 PM, Markus Kittenberger < Markus.Kittenberger at gmx.at> wrote: > hab grad noch was SEHR spannendes entdeckt > > heusued sit auf 11mbit rate und mrate > > gartenfon ist auf 11mrate und auto rate > > hab ich auf beiden die gleiche bssid und essid > > kann ich am garten94linksys per wget via fonerabridge von heusued mit > 590KB/sek runterladen > > hab ich jedoch unterschiedliche essids!!! (dank wiedermal an emien > tippfehler (-;) dann nur 300KB/sek > > war inschiwsch schon zweimal vice versa reproduzierbar!! > > lg MArkus > > On Sat, Nov 29, 2008 at 4:27 PM, Harald Geyer wrote: > >> >> > hmm ist dir schon aufgefallen das die anzahl der wl rates gleich ist >> > >> > [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] >> > >> > [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] >> > >> > evt. amcht das auslassen auf den linksys sinn,.. k.a. >> >> Ja, ist mir ansich aufgefallen. Und hab' mir auch gedacht, dass es >> sinnvoller ist 6.0 und 9.0 wegzulassen (wenn man eh 5.5 und 11.0 hat) >> als die Hohen. >> >> Aber weiß nicht, was ich mit diesem Wissen machen soll - außer in der >> 802.11 spec nachzulesen ... >> >> Was ich viel spannender finde ist, dass der Linksys mit 12.0 RTS sendet, >> obwohl er 18.0 eingestellt hat ... >> >> Liebe Grüße, >> Harald >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Sun Nov 30 13:53:25 2008 From: (spam-protected) (Harald Geyer) Date: Sun, 30 Nov 2008 13:53:25 +0100 Subject: [Dump] policy routing ohne policy? Message-ID: Hi! Hab' vor auf den Foneras den olsrd in einen eigenen routing table schreiben zu lassen und frag' mich jetzt welche rules ich denn am besten als default konfigurieren soll. - Eigentlich will ich nicht verbieten, dass jemand private IPs announced. Denk' mir jetzt, am sinnvollsten ist es zuerst alles im main table nachzusehen und wenn sich dort keine route findet, dann alles im olsr table. - Klar, wenn jemand selber eine default route im main table hat, dann wird dadurch alles kaputt - aber das passiert bei nicht-olsr default routen sowieso. Damit das funktioniert müssen allerdings auf allen vom olsrd verwalteten Interfaces /32 Netzmasken sein - aber /32 ist ohnehin der einzig wahre Prefix für ein Mesh. Vorteile wären halt: * So lang niemand Blödsinn in seinen main table schreibt, verhält es sich (fast) so wie bisher * Die routen zu lokalen IPs können vom olsrd nicht mehr durch hostrouten gestohlen werden - was ein altes Sicherheitsproblem in unserem Netz löst * Auf Nodes mit lokalen Clients gibt's möglicherweise einen kleinen Performance Gewinn. * Der olsrd ist vom Rest des Systems getrennt Fällt dir ein Grund ein, warum das eine schlechte Idee sein könnte? Liebe Grüße, Harald