[Berlin-wireless] horst 1.3 prerelease - bitte testen!

Mo Okt 29 23:04:03 CET 2007

hallo bruno + liste,

ich stells mal wieder auffe liste, bin schliesslich
auch bei [horst], nicht das einzige mass aller dinge.
sorry bruno, ich werde dir später detailierter antworten,
aber thanks für die gesprächs-bereitschaft.
in einem ähnlichen geist haben wir mal mit dem [horst]
angefangen: erst die probleme, und daraus die lösungen finden.

vorab sollten wir mal klären, WAS das horst-tool können soll,
und was nicht, weils andere tools schon/besser können, oder
welche funktionalität es lohnt, zu integrieren in eine
mesh-debug-tool-suite.
mal ganz abgesehen davon, wer es dann in code giesst.

angefangen hat es mit meinem bedürfnis, von den einzelnen
empfangbaren olsr-nodes jeweils deren SIG-werte dar zu stellen.
das ist 3jahre her, inzwischen diversifizierte es sich in mehr
our/other-nodes auf diff. channels, SSIDs, olsr/bat-protocols.

wenn inzwischen viele andere features im [horst]-tool eingebaut
sind, soll mir das recht sein, und wegen mir noch viel mehr...
ich könnte mir eine ganze galerie monitore hinstellen und nach
*glitches* und *unexpected_network_events* fahnden.
das hat natürlich seine grenzen in den resourcen der nodes, der links,
der displayenden_kisten und der human_monitor_wetware_awareness,
und dem grundsätzlichen problem, dass man über einen wackeligen link
auch nix zuverlässig messen kann.
(# thomas_hirsch's diagramm meiner "flight-recorder"-idee (FF-website)
   oder rolf_pfeiffer's "trace-packet"-idee.)

mir schwebt vor, dass man sich ganz grob an den exOSI-layern
orientiert, dh. phy-nah anfängt und dann, soweit nötig/möglich
zu den höheren schichten vordringt.
am liebsten alles intuitiv -ich meine meine intu.- :-) benutzbar
und in einer eindeutigen DIR-artigen hierarchie anklickbar.
wobei in einer kopfzeile erkennbar ist, zb. welche filter grad laufen,
und die grad_nicht_aufgeklappten funktionen in einer mini-übersicht
erscheinen.

wir haben nebeneinander physik-specs / packet-specs / routing-specs,
da ist es manchmal wichtiger wiedersprüchliche werte nah nebeneinander
gegenüber zu stellen, denn dort liegt evt. *der hase im pfeffer*.

für die routing-freaks ist ihr -protokoll/-table die bibel,
für andere fängt die welt am header eines packets an ,-)
als radio-fritze fängts mit SIG/NOI an,
eigentlich sogar mit:
- layer_0, also wer/ort/wann/wieviel (zb. TX-pwr);
- layer_0,5 , dh. antennen- höhe, locali-/polari-sation, gewinn,
  (# die maps mit diff. (popup-)infos sind da ja nah dran)
- layer_1 ist für mich zuerst die frage nach dem
  - Noise-Level_dBm, bzw.
     störungen durch our/other-nodes auf dem gleichen CHannel, bzw.
     müll der von starken stations auf evt. entfernten CHs *rüber-schwappt*
    (# das macht [scanCG.pl] kontinuierlich, ähnlich wie [wlanscan]_once )
  - die Signal-Level_dBm jeder empfangbaren station.
    (# die ursprüngliche [horst]-tool-funktion,
     speziell mit den optionen "o=olsr" u. "c=ctrl")
- dann gibts die ETX/originator-countings, die link-*qually*-infos liefern,
  aber, wegen ihrer udp/lowrate-*robustness*, für real-live-payload-packets 
  leider wenig repräsentativ sind.
  (# olsr-LQ/NLQ/ETX zeigt hoerst_mäders-[fftrace];
     für die bats gibts -imho- noch nix äquivalentes...
      wünschenswert wäre ein klapperatismus, der mit 100/200/../2k-packet-lenghts
      oder netperf, oä. in grösseren zeitlichen abständen testet/darstellt.
      damit man nicht nur sieht, wo/warum ne route gelegt wird,
      sondern, ob wirklich wieviel durchgeht.

@sven-ola:
erkläre mal in langform, wofür du die packet-arten-*torten-diagramme* brauchst,
und wie dass lücken i.d. [horst]-funktionen ergänzt.
 diagonal habe ich mitgelesen, dass du letztlich eine panne am
 emma-link durch auszählen der paket-sorten, bzw. derer *air-time* (!?!)
 aufgedeckt hast.
bruno grummelt ja schon seit 2 jahren, dass er es eigentlich in kismet
hätte einbauen sollen.
und tcpdump/etherreal machen sowas bis_aufs_bit_runtergebrochen.

soweit, soviel
gruss horst_104.131.10.1
offlinehorst at web.de

On Mon, 29 Oct 2007 11:03:53 +0900
bruno randolf <br1 at einfach.org> wrote:

> hallo horst!
> 
> vielen dank fuer das feedback!
> 
> On Sunday 28 October 2007 01:35:16 Horst Krause wrote:
> > wenn man zeilen-umbrüche vermeiden will, benötigt horst.neu
> > leider durch ein paar neue features mehr platz aufm display,
> > so dass es nicht mehr möglich ist, auf 1024x768 nebeneinander
> > 2 hörster laufen zu lassen, zb. um beide link-enden zu monitoren.
> > (mir gelingt es auch nicht, dies grössere format mit copy+paste
> >  aus dem term-fenster unzerhackt in'ne mail zu kopieren :-((
> >  des wär aber nett, für doku und bug-kommunikation)
> 
> ja - aber... was kann man weg lassen oder kuerzer machen? vorschlaege?
> 
> wie viele zeichen auf deinen 1024x768 screen passen haengt auch stark von der 
> verwendeten schriftgroesse ab... trotzdem waere es gut von einer bestimmten 
> groesse ausgehen zu koennen. da wir im textmode sind, sind das zeilen und 
> zeichen pro zeile. was macht sinn?
> 
> > die alte option "o" = 'OLSR/All' haben robert u. ich schmerzlich vermisst,
> 
> die will ich in das neue filter fenster einbauen, deshalb hab ich sie erst mal 
> rausgenommen. vielleicht habe ich das pre-release zu frueh angekuendigt...
> 
> > bitte bau die option "o" wieder ein; ja, mach sie für die wrt-ver. zur
> > default-einstellung, um unerfahrenen usern probleme zu ersparen, 
> 
> ok. das ist eine gute idee. ich werde das zu einer command line option machen, 
> die kann dann auf wrts automatisch angeben (ueber ein start script).
> 
> > die neue option "e" = 'ESSIDs' zeigt die empfangenen cells in einem
> > internen fenster, mit ESSID, BSSID, IBSS/AP, TSF (u. clients/peers?). 
> 
> es werden nur AP und "peers" (ad-hoc nodes) gezeigt, keine AP-clients. dh. es 
> ist eine auflistung aller wlan karten, die BEACONs senden.
> 
> es gibt nur noch 2 andere paket typen, die die ESSID enthalten: PROBE_REQUEST 
> und PROBE_RESPONSE (die requests koennen koennen auch von clients versendet 
> werden), diese werden momentan aber *nicht* ausgewertet.
> 
> >  neben den bereits angebotenen daten fehlen mir an dieser stelle
> >  noch SIG/NOI, u. CHannel, um einen überblick zu haben.
> 
> ok. wird eingebaut.
> 
> >  (eigentlich wünsche ich mir ein 3. horst-fenster am oberen rand,
> >   wie [scanCG.pl] als simpel-'SPECTRUM-analyser' mit life-NOISE, um
> >   CH-'belegung' u. nachbar-CH-'übersprechen' beurteilen zu können)
> 
> das koennte man machen. mit dem nachteil dass man in der zeit wo gescanned 
> wird pakete verliert, oder pakete von anderen channels rein kriegt.
> 
> > leider kann man nicht mehr alle cells anzeigen, wenn "f" = aktiv ist.
> 
> ist das nich der sinn eines filters? oder soll sich der filter 
> nur auf die darstellung beziehen?
> 
> > unglücklich bin ich mal wieder über die anzeigen von signal. noise, evt.
> > [...]
> > - dh, das verhältnis beider pegel (engl: signal_to_noise_ratio = SNR) 
> >       hier die differenz (wg. der logarithmierung) beider werte ist
> >         SNR = SIG - NOI
> >             = (-84dBm) - (-94dBm)
> >             = (-84dBm) + 94dBm
> >             = +10dB
> > beim SNR sind nur positive werte sinnvoll, weil
> 
> ja, das ist mir klar, horst (u.a. dank unermuedlicher aufklaerung 
> deinerseits). das problem ist wie du weisst, dass unterschiedliche karten 
> diese werte unterschiedlich zurueckgeben und das ganze lange zeit ueberhaupt 
> nicht standardisiert war. eine loesung dafuer ist das "radiotap" header 
> format (statt des bisher unstandardisieren "prism2" headers) das kann "horst" 
> auch schon lesen, nur benutzt der wlan treiber im wrt offensichtlich noch 
> prism2 headers.
> 
> und was genau stimmt jetzt eingentlich nicht??? wie gesagt, ich habe keinen 
> WRT und der sinn des pre-release war genau diese fehler zu finden.
> 
> > ein anderes sorgenkind ist die bat-entwicklung.
> > im oberen horst-fenster rasseln diese werte alle wild nacheinander
> > mit ca. 50 packets/sec durch die EINE zeile des nachbar-node
> > "molly-SO"_MAC=00:0d:0b:fd:56:ad mit den IPs
> > - 103.. und
> > - 104.. und
> > - 105.131.41.2,
> 
> ja, wie sollen unterschiedliche IPs angezeigt werden? klar, ich koennte die 
> alle auflisten, aber dann wird das display noch laenger...
> 
> btw: die neue version (git) hat einen signal/noise/rate history graphen :)
> 
> lg,
> bruno
> 
> >
> > On Wed, 24 Oct 2007 19:10:47 +0900
> >
> > bruno randolf <br1 at einfach.org> wrote:
> > > hallo allerseits!
> > >
> > > ich habe mich mal des seit 2 jahren maintainer-losen "horst" tools
> > > angenommen, die in der zwischenzeit von sven-ola und robert gebastelten
> > > patches eingebaut und ein paar weitere verbesserungen gemacht: es wird
> > > nun automatisch erkannt ob beim monitor interface ein radiotap oder
> > > prism2 header verwendet wird, und ich habe ein neues fenster 'e' zum
> > > auflisten alles ESSIS eingebaut, incl. automatischer ESSID split
> > > detection... und ne menge kleinigkeiten...
> > >
> > > es ist noch nicht ganz fertig, aber fast, und ich wuerde es jetzt gerne
> > > mal auf einer anderen platform und mit anderen wlan chipsets testen - ich
> > > selbst kann hier leider grade nur auf atheros/x86 basis testen (hab mein
> > > cube passwort vergessen, und keine serielle... argl...)
> > >
> > > also fuer die mutigen, hier ungetestete pakete fuer kamikaze trunk
> > >   wrt:  http://br1.einfach.org/horst/horst_1.3pre-1_mipsel-wrt.ipk
> > >   cube: http://br1.einfach.org/horst/horst_1.3pre-1_mipsel-mtx.ipk
> > >
> > > den source gibts per
> > >   git clone git://br1.einfach.org/git/horst.git
> > >
> > > und hier noch als download:
> > >   http://br1.einfach.org/horst/horst-1.3pre.tgz
> > >
> > > und es gibt ein git-web interface :)
> > >   http://br1.einfach.org/gitweb?p=horst.git;a=summary
> > >
> > > hier die openwrt build files
> > >   http://br1.einfach.org/horst/horst-openwrt.tgz
> > >
> > > also, wuerde mich freuen wenn das jemand auf nem wrt und/oder cube
> > > ausprobieren kann... interessant waere vor allem ob die SNR auswertung
> > > auf nicht-madwifi karten noch stimmt, und ob die TSF anzeige stimmt oder
> > > bytes geswapped werden. bugreports bitte an mich.
> > >
> > > lg aus japan,
> > > bruno
> > > _______________________________________________
> > > Berlin mailing list
> > > Berlin at berlin.freifunk.net
> > > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> 
> 