[Berlin-wireless] Emmaus, hOrst-tool, WRT-brick, et alt

[Horst Krause]

hallo liste,

ich habe es mir Sa-nachmittag gegeben, mit dem bereits in der c-base
vorgeführten wrt-h0rst-mobil-scan-setup :
- akku + wrt im rucksack, 
- libretto als wrt-terminal +  wrt-antenne(4xQuad_horiz-pol) in der hand
aus der umgebung der Emmaus-Kirche die signale des turms zu scannen.
bis mir die beine am arsch anfroren, und...

!!! HELP !!!-  der WRT VERENDETE   :-(((
------------------------------------------------------------------
power blinkt, dmz nicht, power-reset bootet er nicht. 
  ich hab weder mech.-phy., elektrisch, noch softisch dran gespielt.
  zuerst hielt ich es für ein brown-out wg. ende der akku-laufzeit,
  und glaubte, der libretto noch zeigt 'no connect..', weil der noch auf
  seinem eigenen akku weiterläuft, aber ein blick in den rucksack
  zeigte mir, der akku war NICHT leer.
 am frischgeladenen_akku / wrt-netzteil bootets auch nicht;
ist der wrt nu gebrickt?

was nu weiter, ich bringe ihn Mi zum wavelöten in die c-base mit,
da können die WRTologen mal ne tiefbohrung machen...

die entwicklung d. mess-methode, dh. wo/wie/was man erst mit h0rst
und dann mit dem setup, besonders mit der antenne tun muss,
damit man sich bessere link-strecken einrichten kann, ist jetzt erst mal
mangels lauffähigem wrt unterbrochen..
fuck, ich war 'grad gut dabei.

anfang eines h0rst_HOWTO-txt as attachment...


EMMAUS-SURVEY
------------------------------
die zahlen unten entsprechen den in der ersten spalte d. wrt_*h0rst*-display 
angezeigten 'SN'-werten, ohne minus-vorzeichen. ich nenn es absichtlich nicht 
'SNR' oä., und schon gar nicht 'dB'; siehe dazu unten.: *algorithmos*

 dabei bedeuten:
 - geringere zahlenwerte (zb.: 80) = BESSERES signal,
 - höhere werte (zb.: 90) = schwächeres signal.
 
! nur Emmaus-nodes notiert, die IPs  sind immer 104.192.192.xxx !
! liste zt. unvollständig, weil das display kürzer als die liste war,
  die glatten strassen auch aufmerksamkeit erforderten, und ich
  gut noch 2 hände mehr hätte haben können, da
  - ich nicht-Xberger noch die olsr-map,
  - die IP-liste, und
  - die messwert-notizen
in print zur hand haben wollte (die Zwingli-notices waren akku_leer=futsch!


folgende locations habe ich abgeklappert, alle mit sicht a.d. E-K-Turm:
..IP  |  'SN'-Wert

NEW-THINKING / SKALITZERstr. 41
..??   SN=73  # IP nicht notiert, aber sicher eine turm-IP,
                     # nicht der test-wrt im N-T-schaufenster :-))

WIENERstr. / LAUSITZERstr.
..66   SN=88
..33    SN=83
..1     SN=90

SPREEWALD-PLATZ / EINGANG-BAD
..1     SN=83

TANKE GÖRLITZERstr / SKALITZERstr
..1     SN=83
..225  SN=83
..199 SN=88

SKALITZERstr Nr.50, westlich d. lause-platz
..225 SN=90
..199 SN=90

WRANGELstr Nr.98, v.d. handels/OS-schule
..225 SN=96
..199 SN=90
..166 SN=93

EISENBAHNstr. / MUSKAUERstr
..166 SN=83
..133 SN=81

...und denne: *connection closed by remote host* , grrrr.


BEWERTUNG
-----------------------
die mess-ergebnisse sehen soweit alle konsistent aus, jedenfalls sind alle 
beobachteten Emmaus-K-T-nodes: ..1, ..33, ..66, ..133, ..166, ..199, ..225 
funk-/antennen-mäßig *alife*. (lui's home-link=..99 wird wohl laufen :-)

angesichts der nicht-definierten 'SN'-werte, und dem nicht-kalibrierten
wrt_h0rst_mobil-setup lässt sich nicht abschliessend sagen,
ob sie nun alle etwa gleich gut o. etwa gleich schlecht sind, eher gut.
(ich erwarte etwas höhere 'wirkliche' SNR-dB-werte, jedenfalls sah ich
 ähnlich 'schlapp' erscheinende werte auch um die Zwingli) 
 dazu s.unten: *algorithmos* 

woran es liegt, daß sich Zwingli-K-T <-> Emmaus-K-T nicht direkt *sehen*, 
sondern bisher ein connect zwischen Emma_x-berg und Zwingli_strahlau
nur über dritte läuft, ist somit auch noch nicht beantwortet,
es sieht aber -imho- eher nach einem Zwingli-K-T-problem aus.

das Universal_Music-gebäude steht nicht im weg,
ich von der Zwwingli die Emmaus optisch gesehen!
============================================================

ALGORITHMOS
--------------------------
etwa in der mitte des *Scanner*-attachments steht folgende rechnung:
   sigstrength = ((rssi[x] - noise[x])*1.5) + ((rssi[x] +90)*1.5);
der lobenswert ehrliche  kommentar darüber sagt alles:
 #arbitrary strength calc through trial and error... modify as you wish:

vermutlich, ist dies was ähnliches, was mir bruno mal in den treibern für die 
cube_senao-cards gezeigt hat, als ich mich beschwerte, dass jede neue
version andere signal-/noise-level-'dBm' in der iwconfig anzeigen würde;
(bei gleichem setup und stabilen radio-conditions.)
tatsächlich wurden 2 verschiedene 'algorithmen' verwendet !?!, seriös-seriös!

anscheinend wird dort aus den rohdaten, die von der firmware in hex-format256
ausgeworfen werden, der wert ausgerechnet, der dann als 'Signal-level:' xx
mit der mass-einheit 'dBm' gelabelt wird.
das wünsche ich mir, ehrlich gesagt, etwas mehr begründet, und
weniger beliebig gehandhabt.

wo/wie die firmware diese rohdaten hernimmt, oder welche hardware-stufen
daran beteiligt sind, darüber weiss ich leider garnix.

in den treibern, zumindestens deren output und iwconfig, auch bei den bunten 
rrd-statistiken gibt es -imho- ein ziemliches durcheinander/mythenbildung,
da werden die begriffe:
- link-quality             (xx/yy-werte; keine einheiten?),
- RSSI                     (radio_signal_strength_intensity; in hex o. dBm?),
- RSSID                  (radio_signal_strength_identifier,hä? watendat?),
- signal-level           (signal-pegel, meist in dBm),       
- signal-strength      (feld-stärke?, aber wohl kaum in Volt/Meter),
- S/N                       (signal_to_noise, in dB),
- S&N                     (signal_and_noise; in dBm),
- SNR                     (signal_to_noise_ratio; in dB),
wild durcheinander gewürfelt, natürlich mit versch. werten/einheiten,
das sieht aus, als wenn da nicht viel konkrete anschauung hinter steckt.

für die mess-anwendung, wo ich genaue, reproduzierbare werte haben will,
jedenfalls ein quell_steter_freude...
als wenn es in der HF-technik und auf den link-strecken ncht schon so genug
unüberschaubare einflüsse gäbe.

Also, zeigt mir bitte mal in den debian- u. wrt-h0rst-tools-sourcen die 
stellen, wo dies verarbeitet wird. auch für jeden anderen hinweis u.
unterstützung zu diesem themen-kreis bin ich dankbar.

schliesslich will ich, dass 'dBm' auch drin ist, wo 's drauf steht.
(bei einem zollstock will man auch nicht jeden tag andere 
 strich-abstände oder symbole an den strichen)

ein erläuterungs-entwurf des dB-komplex im *what IS...*-attachment.
 versteht ein nicht-funk/antennen-'guru' davon etwas,
 oder ist es fehlerhaft oder gar betriebs-blind / partei-chinesisch? 

anregungen/korrekturen an offlinehorst at web.de 
===============================================================

hOrst-SCAN-TOOL
----------------------------
wenn mir jemand die innereien der *hOrst*-scan-tools-sourcen 
auseinander-dröseln will, gerne.
ich verstehe als nicht-coder wahrscheinlich nur bahnhof, aber
wenigsten den ablauf möchte ich in groben zügen kennen.

C++-coder, die das tool frisch machen, find ich natürlich auch toll.
damit es für link-evaluierung / -optimierungen / -debug nutzbar ist.
dazu als anhang eine hOrst-TODO/wunschliste.

gerne schaue ich mir previews an, um gegen zu checken,
ob funktion u. anzeige plausibel und praxis-nah sind.


tschüss horst
 
-------------- nächster Teil --------------
# Show scanresults in consistent order with graphical bars.  
# To be run via telnet to WRT54g running modified firmware. 
# Do the following. Use your own router address instead of 192.168.1.1 on the following lines 
# Login via telnet: 
#    telnet 192.168.1.1 
# a simple test to make sure you can run this script, type:  
#    wl scan; wl scanresults 
# and make sure you can run those commands. If not this program will not work. 
# If you succeeded with the scanresults then  
# copy and paste this entire text into the terminal window  
# (the cat - >scanner line will copy the rest of the file into a file named 'scanner') 
# and then hit return and then ctrl-c to close the file. 
# then just run script by typing tyhe following line: 
#    awk -f scanner 
# 
# I hereby release this into the public domain. Justin Jones, 2005 
# 
 
 
BEGIN{ 
 IGNORECASE = 1; 
 command = "wl scan 2> /dev/null ; wl scanresults 2> /dev/null"; 
 red = "\x1b[31m";              green = "\x1b[32m"; 
 greenback="\x1b[42m";          yellow = "\x1b[33m"; 
 cyan = "\x1b[36m";             blue = "\x1b[34m"; 
 blueback = "\x1b[44m";         white = "\x1b[37m"; 
 whiteback = "\x1b[47m";        reset = "\x1b[0m"; 
 underscore = "\x1b[4m";        clear = "\x1b[2J"; 
 home = "\x1b[0;0H";            erase2end = "\x1b[K"; 
 cName = white;                 cSignal = green; 
 cNoise = red;                  cCaps = green; 
 cStrengthLow = blue blueback;  cChannel = green;                
 cStrengthMed = white whiteback; 
 cStrengthHi = green greenback; 
 cStrengthAged = red; 
   
 print clear; 
 for(;;) 
 { 
  while (command|getline) 
  { 
  if(/^SSID/) {cn = $2; name[cn] = cn;  rssi[cn] = $6;noise[cn]= $9} 
  if(/^Mode/) {rssi[cn] = $4;noise[cn]= $7; channel[cn] = $10 } 
  if(/^BSSID/) {caps[cn] = $4" "$5" "$6" "$7" "$8" "$9" "$10 } 
  } 
  close(command) 
  printf home; 
  ln = 0; 
  print white " Name   Signal Noise Channel Type"; 
  for (x in name) 
  { 
        { 
        #arbitrary strength calc through trial and error... modify as you wish: 
        sigstrength = ((rssi[x] - noise[x])*1.5) + ((rssi[x] +90)*1.5); 
        if (sigstrength <1) sigstrength=0; 
        cStrength = cStrengthLow; 
        if(sigstrength>4) cStrength = cStrengthMed; 
        if(sigstrength>7) cStrength = cStrengthHi; 
        if(age[x]=0) cStrength = cStrengthAged; 
         
        fmt = "%s%-15s %s%0"sigstrength"d "reset erase2end "\n           %s%-4d %s%-4d %s%-4d %s%2s %s%10s "  reset erase2end "\n" erase2end "\n"; 
        printf fmt, cName,name[x],cStrength,0,cSignal,rssi[x],cNoise,noise[x],cChannel, channel[x],cCaps,caps[x];  
        rssi[x] = -100; 
        ln++; 
        } 
  }   
  print erase2end; 
 } 
} 
-------------- nächster Teil --------------
[wget http://wiki.funkfeuer.at/images/9/94/Scanner] 

auf wrt starten mit [awk -f Scanner]
-------------- nächster Teil --------------
what IS/FOR Signal/Noise/SNR_dBm         
was sollen die SNR / SIGNAL / NOISE -werte im h0rst-tool sagen.
by offlinehorst at web.de                    29.1.'06

SNR / SIGNAL / NOISE 

  SIGNAL in (+/-)dBm
 engl.: signal-level; deutsch: (nutz-)signal-pegel;
  was man empfangen will.  

 NOISE in (+/-)dBm
 engl.: noise-level (auch: noise-carpet);
 deutsch: rausch-, o. stör-pegel, trivial: matsch, müll.
  was man nicht empfangen will.

 SNR, manchmal auch S/N, in dB (ohne 'm')
 engl.: Signal_to_Noise_Ratio;
 deutsch: stör-abstand; genauer: signal_zu_stör_abstand.
  das verhältnis von nutz- zu stör-pegel; also mathm. ein bruch,
  wg. dem unten erwähnten 10er-logaritmus, vereinfacht sich
  punkt- zu strichrechnung, deshalb:
  SNR = (signal-level - noise-level).

 zur erläuterung, messen heisst vergleichen mit einem standart:
 leistung wird in watt [W] gemessen, ein 1000stel davon ist milli-Watt [mW].
 es gibt sende- o. empfangs-leistung, je nachdem, was 'raus o. 'rein-geht
 (engl: transmit- o. receice-power = Tx- o. Rx-pwr)

 bei funk-anwendungen gibt es einerseits Tx-pwr von über 100000W = 100kW,
 andererseits unvorstellbar kleine Rx-pwr von weniger als 0,0000000001mW.
 um diese sehr grossen o. kleinen werte anschaulich darzustellen, ohne
 sich mit endlosen reihen von nullen vor/hinter dem komma ab zu plagen,
 verwendet man den mit 10 multiplizierten 10er-logaritmus der obigen
 Watt-'zahlen', dies nennt man *pegel* (engl: *level*), und nennt dieses
 mass *deziBel* = 10tel-Bel (nach dem telefon-opa Alexander Graham Bell).
  
 bei den wlan-üblich kleinen leistungen ist die bezugsgrösse '1 milli-Watt'
 als der 0-punkt dieser logaritmischen scala definiert. je nachdem ob
 der gemessene pegel grösser/kleiner ist, ergeben sich (+/-)-vorzeichen.
    1mW =  0dBm    (auch: 0dbm; index 'm' für: bezogen auf '1mW',
                     sprich: 'null_de_be_index_em', kurz: 'null_de_be_em') 
    2mW = +3dBm
  0,5mW = -3dBm

   10mW = +10dBm
 0,01mW = -10dBm

  100mW = +20dBm  ( weil: 1mW x 100; lg100 = +2Bel = +20dezi-Bel )
 
 bei -90 ~ -100dBm liegt der immer vorhandene Noise-level, ursachen sind:
                   kosmisches-, temperatur-, halbleiter-rauschen, im urbanen raum
                   vor allem elektro-smog: µ-wellen-herde, wifi-IFs, bluetueth, ect.

 im -40 ~ -80dBm -bereich liegen typische signal-level, also >10dB *über* 'm noise. 

 signal- bzw. noise-level repräsentieren beide leistung, also 'energie'.
 dh. des einen sein SIGNAL ist evt. des andern sein NOISE, und umgekehrt.
 SIGNAL-source gibt 's aber meist nur eine, NOISE-quellen dagegen viele 
 eine unterscheidung in signal=gut u. noise=schlecht ist rein subjektiv.
 die technik beurteilt aber nicht moralisch, sondern es ist trivial so:
 - wenn der NOISE grösser als SIGNAL ist, wackelt der link, o. reißt ganz ab;
    da hilft kein vor-verstärker, damit würde nur der NOISE lauter,
    das SIGNAL bliebe trotzdem 'zermatscht' + 'überbrüllt'.
 - der oft geäussere wunsch nach nachbrennern/boostern/schwanzverlängerern
    führt sicher zu mehr gebrüll, aber nicht zu mehr links...
 - SIGNAL soll 'lauter' empfangen werden, als der NOISE, wenn es linken soll;
    also im medium radio zur 'isolation' die antennen-eigenschaften nutzen.


helfen tut:
- der jeweiligen situation angemessene auswahl v. sektor-/richt-antennen
   nach verwendungs-zweck, standort, öffnungwinkel, ausrichtung, polarisation;
- ein tragfähiges, realisierbares 'breiten-sport'-konzept, statt weniger vorturner.
- eine sachgerechte planung nach den geografischen, urbanen bedingungen, dh.
   relais-ketten, die an sektoren verteilen in die strassen-/häuser-/hof-netze.
- lokale absprache/zusammenarbeit in offenen, demokratischen strukturen.
   möge jeder selbst kucken, was er davon sieht, oder nicht. -reclaim your net-

-------------- nächster Teil --------------
hOrst-HOWTO.txt                                berlin,  15. 01.'06
 by offlinehorst at web.de

================================================================

INHALT
======
A. Benennung des tools
B. Wie alles anfing
C. Das README zum hOrst-tool v. bruno


A. Benennung des tools
======================
um das tool v. meinem namen *Horst*_Krause, gleichlautenden DIRs,
ect. unterscheiden zu können, bitte ich darum,
das scanning-tool und div. up-DIRs:
- *hOsrt* (mit gr. 'Oh' für die debian-version, u.
- *h0srt* (mit '0'='NULL' für die mipsel- = wrt-version
zu benennen. thanks!

B. wie alles anfing
===================
im oktober 2004, als robert, sebastian u. ich einen peil- u. feld-stärke-test
zwecks vorbereitung des damals geplanten p'berg_vernetzung-kirchen-uplink
machen wollten, stellten wir erstaunt fest, dass es nicht möglich war,
die einzelnen nodes der berliner ad-hoc-wolke zu differenzieren, weil alle
berliner_ad-hoc_nodes des sogn. OLSR-net die gleichen parameter benutzen:
- mode = ad-hoc,
- channel = 10,
- ESSID = olsr.freifunk-net
- BSSID (=cell-id, übernehmen alle nodes, lt. time-stamp des 'ältesten' node).

seit einführung des ad-hoc_OLSR-protokoll war es mit den gängigen tools,
nicht mehr möglich mit einer richt-antenne nach dem *besten* node zu suchen,
weil *netstumbler*, *kismet*, *wavemon*, *lucent-client-mgr*, ect.
nicht in der lage sind, für jeden node getrennt signal/noise anzuzeigen,
sondern im ad-hoc_mode einen un-interpretierbaren, wild-fluktierenden
misch-masch anzeigen, was aber erstaunlicherweise niemand auffiel o. störte!
(ein angbl. workaround mit iwspy habe ich mangels OS + prism2-card nie gesehen)

noch erstaunlicher war für mich die reaktion der *core-member* auf die obige
mängel-feststellung:
- "das brauchst du nicht, macht bei uns das protokoll",
- "dafür gibt es das olsr-webplugin/status/wlan-scan" (konnte es auch nicht),
-  oder schlicht "olsr ist eben so",
bis hin zu gänzlichem unverständnis der coder, was/wofür sie sich mit
*dBi*, *dBm*, *signal & noise*, *SNR*, *link-quality*, *RSSID*(u.ä. konstrukten),
vom rapid-releasing ablenken lassen sollten, während gleichzeitig die meisten
radio-links wackelig waren, das ganze netz immer unstabiler wurde.
(und es sollte noch viel schlimmer kommen im folgenden jahr mit 
 'routen-flappen', 'channel-trippen', BSSID-spaltungen, net-breakdowns)

mir war dagegen klar, dass es ein stabiles netz nicht geben wird ohne korrekte
radio-links als 'physikalischer' grundlage desselben.
und ohne mess-tools hat niemand eine chance, ordentliche radio-links zu bauen,
ganz abgesehen vom fehlersuchen/bebuggen der komponenten
des funk/antennen/ link-strecken-dB-kram,
der gern als woodoo verballhornt wird.

nun bin ich selbst kein coder, und mehr als einmal wurden meine sorgen/klagen
von grossen_egos in RTFM-manier abgebürstet und ich persönlich niedergemacht,
weil ich zwar ein problem beschreiben, aber es nicht selber lösen konnte.
das war wohl zuviel für's nerven-kostüm derjenigen, die sich nur als lösungen
sehen können, die probleme dagegen immer nur bei den loosern..

und so ging über ein jahr ins land, ohne dass sich was wesentliches tat.
bruno hatte 'ne idee, wie er es angehen würde, die es immerhin bis zum
preview brachte, die er mir lobenswerterweise zum plaui-check vorführte...

dann kam die zeit, wo bruno demnächst für länger nach asien in urlaub fahren
würde, und ich mit bangen sah, dass damit die fertigstellung des scan-tools
auf den sankt-nimmerleins-tag verschoben wäre, zumal er inzwischen zweifel hatte,
sein ansatz wäre zu umständlich und meinte, die ganze funktionalität 
müsste in *kismet* eingebaut werden, da dort der monitor-mode bereits
gehandled wird.
(die allg.-funktionen von *kismet* und ad-hoc-spezifischen von *hOrst*
 zusammen zu führen, oder diese beiden scan-tools parallel laufen lassen
 zu können, ist nach wie vor interessant; vielleicht reizt es jemand?)

nun, bruno hat es nach intensivem Horst-jammern doch fertig-gestellt,
noch spass dabei gehabt und es kurz vor seiner abreise als *horst* releast.
 (eigentlich hätte es ja brunos-olsr-radio-scan-tool = *borst* heissen müssen,
  da klang horst wohl etwas besser; ich nehme es mal als eine hommage .-)
uff und thanks!

wenig später hat alex aus hamburg, während des 22c3, das debian-*hOrst*
auf mipsel/broadcom portiert, wo es  WRT-*h0rst* heissen soll.
ebenfalls thanks!

inzwischen wurde die wunschliste an felix in HH weitergetrommelt,
eine reaktion habe ich noch nicht.


C. das README zum hOrst-tool v. bruno:
======================================

HORST - Horsts Olsr Radio Scanning Tool
---------------------------------------
Copyright (C) 2005 Bruno Randolf
Released under the GPL

"horst" is a scanning and analysis tool for wireless OLSR nodes in ad-hoc mode.

problem description: with the usual wireless tools like iwconfig and iwspy it is hard
to measure the received signal strength (or SNR) for each of the different nodes which
form an ad-hoc network. this information however is very important for setting up,
debugging and optimizing wireless OLSR mesh networks.

"horst" aims to fill this gap and lists the single nodes of an ad-hoc network
seperately including the signal strength (SNR) of the last received packet from each node.
this way you can see which nodes are part of a specific ad-hoc cell (BSSID), discover
problems with ad-hoc cell merging (a problem of many wlan drivers), which of the
nodes send OLSR packets, wether they use the link quality exension, how many neighbors
each node sees and the SNR of the last received packet of each station.

it uses the monitor mode including prism2 headers (for the signal strength information)
of the wlan cards and listens to all packets which come in the wireless interface.
these packets are scanned for OLSR traffic and summarized by the MAC address of the
sending node. [actually what it does is quite similar to kismet, and in might be a good
idea to include this functionality into kismet.]

it should work with any wlan card which can do monitor mode and which has prism2 headers
in monitor mode. but it has been tested only with the following wlan chipsets/drivers:
 * prism2 with hostap
 * atheros with madwifi-ng

you have to put your card in monitor mode and set the channel manually before you start
the tool:

1.) put card in monitor mode:
	hostap:
	# iwconfig wlan0 mode monitor

	madwifi-ng:
	# wlanconfig wlan0 create wlandev wifi0 wlanmode monitor

2.) enable prism headers in monitor mode
	hostap:
	# iwpriv wlan0 monitor_type 1
	or
	# prism2_param wlan0 monitor_type 1

	(madwifi-ng: prism headers are enabled by default)

3.) tune to a channel
	# ifconfig wlan0 up
	# iwconfig wlan0 channel 10

4.) start tool
	# ./horst
-------------- nächster Teil --------------
_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin