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

Mi Okt 31 01:42:02 CET 2007

hallo bruno + liste,

arg, letztens vergessen,
 [horst.neu]/STATUS-fenster(unten-rechts):
  der SIG-lattenkreuz-bargraf 'hängt' auf maximal.

zu der inneren architektur des horst-tool, und wer daran mitarbeiten
will, bzw. wie mans dann organisiert, dazu kann ich wenig sagen,
ausser 'schlanke_basic-engine' + 'plugins', uä. dau-geschwafel.

zur horst-FENSTER-BREITE
wenn es nach mir geht, 512 pix breit, damit man beide link-enden
mit 2 hörstern nebeneinander monitoren kann.

die fenster-höhe ist beliebig, bzw. auf busy nodes ist man
gezwungen, eine sehr hohes fenster aufzuziehen, damit
im (oberen)node-list-fenster nix unten 'abgeschnitten' wird;
das hat leider zur folge, dass auch das (untere)paket-fenster
ebenso hoch wird, was cpu/grafikcard belastet, selbst wenn man diesen
teil des horst-window nach unten über die desktop-grenze hinaus-schiebt.
(zb: um 'molly-SO'_104.131.41.2/horst darzustellen,
     dh. zZ. 18 einträge in der (oberen)node-liste,
     braucht es 2x18 + 5(rahmen/titel) = 42 zeilen gesamt-höhe;
     mein celeron ist zu 100%-cpu-load mit der darstellung beschäftigt,
     überwiegend mit den durchrauschenden zeilen im unteren fenster. 
würde evt. eine verschiebbare grenze zwischen dem oberen/unteren horst-
fenster eine verringerung der last bringen?

zur CHAR-grösse:
unter xubuntu/system/../schrift/einstellungen/details_96dpi + mono-10pt
und terminal/einstellungen/schriftart/mono-6pt + keine fettschrift,
    sondern hervorhebung durch farbe grün/weiss,
ist grad noch eindeutig lesbar, für normal-user schon arg fitzelig.
horst.old so breit gezogen, dass "o=olsr" noch kein zeile umbricht,
ist dann (rechtsklick auf den fensterrahmen) 96char breit
          + scrollbar + fensterrahmen
also grad so breit, dass sich 2 x horst.old-fenster nebeneinander
stellen lassen, ohne überlappung.

auf dieses mass hätte ich auch gern horst.neu, aber das geht eigentlich nur,
wenn man einen 'grosse' spalte weg lassen würde.
der einzige spar-kandidat, der mir einfällt, wäre "source"-MAC, weil, die ist
-imho- am wenigsten 'mesh-relevant', und wird mit 
die man ja in grösseren zusammenhang im option"e"-fenster angegeben ist,
aber das ist für andere leute vielleicht unverzichtbar...

im option"e"=essid-popup ist in jeden listenplatz die bssid 2x vertreten,
da könnte man eine weglassen, stattdessen die IP auch in dieser liste,
damit man alle 'synomyme' eines node zusammen hat.

sven-ola's packet-art/speed/length/count/(kollisions?) - infos/stats
könnten zb die option "i"=info, oder "s"-stats werden?
aber da steckt sven-ola als packetiser mehr drin :-)
wichtig ist es, weil an diesem digitalen ende der verarbeitung kann
viel vom_tisch_fallen, wg. cpu-load, stack-overlow, dicker_luftzeit,
ähnlich wie durch schlappen snr, (sogn. schlechtes_funkwetter) :-)),
o. durch *brüller* die dem analogen radio-frontend in den ohren liegen.

zu SCAN, [scanCG.pl]-artig, in separatem 3.fenster
(oberhalb v. node-liste-fenster)
soll es ermöglichen zu untersuchen:
- noise-level über alle CH, auch un-belegten, zb. µ-wellen-öfen-müll,
- gesamt-signal-level auf den belegten CH,
- cell-konkurrenz im gleichen CH,
- starke *brüller* auch auf abgelegen CH.
wieweit der scan mit der flüssige normal-funktion eines wrt-artigen node
zusammenpasst, kann ich nicht wirklich beurteilen, für mich geht nicht
die welt unter, wenn mal ein paar packets nicht angezeigt werden.
uuund auch jetzt werden CH-fremde nodes im oberen fenster angezeigt, was
auch sinn macht, weil es daran erinnert, dass auf den ersten IF-stages
die selektion längst nicht so absolut ist, wie dort, wo aufs bit-genau
gefiltert werden kann. (ich erspare mir *non-overlapping-CHs*-FOO-bashing)
"wispy" ist chick, für den, der es hat und benutzen kann,
aber wir wollten es wrt-kompatibel.
wobei der vorschlag, daten auf den ohnehin als terminal notwendigen lappi
rüberzuschaufeln und dort vertieft zu bearbeiten, seinen charm hat.

soweit, sogut, das mit den SIG/NOI-werten krieg' ich jetzt nicht mehr hin.
to be continued.

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
> 
> 