[Wien] zeltgaz.funkfuer.at BSSID 00:15:D6:19:10:28

Mi Okt 22 23:59:06 CEST 2014

Hallo!

Am 2014-10-22 um 22:52 schrieb Christofer Brajkovic:
> Wir bennen unsere immer mit richtung und standort
>
> Bsp.: sw5duer9.funkfeuer.at <http://sw5duer9.funkfeuer.at>
>          Somi weiss man richtung/band/standort ;-)
Das mag mit dem Adhoc-Mode sinnvoll sein, weil dort sonst keine 
Unterscheidungsmerkmale bei einem einfachen Scan erkennbar sind (weshalb 
der "Horst" so beliebt war).

Warum ich das für überkommen halte:
Kurzfassung:
Best case: redundante (Meta)information
Worst case: Fehlinformation, verhindert "Roaming"/"Handover", wenn 
mehrere APs vorhanden sind.
Aktuelle Werte liefert stets ein Scan - ein fiktives Beispiel, wie es 
sein sollte:

34% *ozw**.funkfeuer.at*
*Channel:* 108 | *Mode:* Master | *BSSID:* XX:XX:XX:3E:6F:B7 | 
*Encryption:* /offen/

SNR/RSSI -> impliziert gute und schlechte Ausrichtung. Lesen der 
Dokumentation oder Anfrage beim Nodebetreiber ist sowieso erforderlich. 
Kein Knoten ohne Planung.
ESSID -> einheitlicher Extended Service Set Identifier ermöglicht Roaming.
Kanal -> impliziert Band. Sieht man sowieso nur, wenn das eigene Gerät 
das kann.
Modus -> muss ich sowieso wissen.
BSSID = MAC-Adresse des Interfaces. Sollte im AP-Mode (Master) stets 
eindeutig und unterscheidbar sein.
Verschlüsselung.

Fazit-> es ist in der ESSID keine Meta-Information außer der 
Polarization vorhanden, die mir ein Scan nicht sowieso liefert.

Langfassung:
1. Ein Master strahlt seine (üblicherweise) eindeutige BSSID 
(=Interface-MAC-Adresse aus).
2. Die Richtungsangabe in der ESSID stimmt womöglich nach einer 
Neuausrichtung nicht mehr. Gefahr der Fehlinformation. Die beste 
gemessene RSSI bezogen auf eine BSSID indiziert die richtige Richtung. 
Wohin man ausrichten will, weiß man hoffentlich schon bevor man Trial 
and Error unter Zuhilfenahme des Schraubenschlüssel spielt.
3. Eine Richtungsangabe "sw" ist bei einer Nanobeam/Nanobridge, etc 
meist unzureichend. Es hat sich mancherorts eingebürgert, die 
Richtungsangabe in Grad oder in Himmelsrichtungen im Devicenamen 
wiederzuspiegeln. In der Praxis variiert das z.B. durch einen 
Gerätetausch oder eine Neuausrichtung.
4. Das Band/den Kanal erkennt man beim Scannen. Ein Kanal im anderen 
Band ist für das jeweils andere Single-Band-Gerät sowieso nicht zu 
erkennen. Sinnlos. Da kann man den Linkpartner auch Pendeln.
5. Für einen Standort mit multidirektionalem AP-Betrieb ist es 
üblicherweise sinnvoller, nur eine einheitliche ESSID zu verwenden, weil
     a) eine Art Roaming damit möglich wird, durch die
     b) Änderungen an Richtung, Ausstattung, etc ermöglicht werden, für 
die beim Client keine Konfigurationsänderungen erforderlich sind, sofern
     c) nicht im Einzelfall durch Angabe von BSSID und, sofern möglich, 
Kanal die Auswahl auf einen individualisierten AP beschränkt wurde, oder
     d) im jeweiligen nicht zuständigen AP eine MAC-Filter Liste dies 
ermöglicht. (was bei Adhoc nie möglich war).
     e) Auch im Fall von Nebenkeulen kann diese Konfiguration 
-insbesondere bei nahe gelegenen Linkpartnern- sinnvoll sein.
     Fazit: Man vereint einige der Stärken des Adhoc-Modus und kann 
einige seiner Schwächen ausräumen. (Im Scan scheinen alle 
unterschiedlichen BSSIDs auf,
     während beim Adhoc-Mode manchmal nur eine BSSID pro Kanal und dort 
nur das stärkste empfangene Signal sichtbar war; Die einheitliche ESSID pro
     Standort ersetzt die einheitliche BSSID pro Kanal, Fallbacks sind 
mit zusätzlichen Clients selektiv machbar, bei starker Bündelung aber 
nur selten sinnvoll
     [außer alle Hops liegen exakt auf derselben Linie]).
6. In Ausnahme zu 5. sind lediglich dedizierte Links sinnvoller mit 
individuellen ESSIDs zu betreiben.
7. Angaben zum Knoten gehören möglichst exakt in die Knotendokumentation 
und nicht unscharf in die ESSID. ESSIDs sind zudem auf 32 Zeichen 
beschränkt.
8. Etwaige Angaben zur Polarisation können zwar im Einzelfall noch 
sinnvoll sein, stehen aber im Widerspruch zu 5. und sind mit dualer 
Polarisation+MiMO weitgehend obsolet.
9. Azimuth (3.) und Elevation sind möglichst genau zu dokumentieren, 
damit Weitstrecken optimal geplant werden können. ESSIDs sind dafür 
nicht geeignet und eine möglichst kurze Codierung dafür ist weder 
nutzerfreundlich, noch mit 5. vereinbar.
10. Bestes Argument - die Praxis: Knoten wie das OZW zeigen, dass ein 
solcher roamingfreundlicher multi-AP Knoten beherrschbar ist und bestens 
funktioniert. Wenn ein Device ausfällt, kann in so einem Fall bei guten 
Bedingungen sogar ein anderes die Aufgaben schnell übernehmen. Clients, 
die roamingfreudig konfiguriert sind, sollten ihren "besten" 
Linkpartner, sobald dieser wieder online ist auch danach wieder finden. 
(Notfalls auch via Workaround: Script/wifi restart). Erweiterungen des 
Knotens sind so grundsätzlich bei geschickter Durchführung "on-the-fly" 
(also ohne allzu große Downtime) möglich.

Erlaube mir daher die Gegenfrage: Warum sollte man es anders als so machen?

LG
Erich
>
> Von meinem iPhone gesendet
>
> Am 22.10.2014 um 00:31 schrieb Erich N. Pekarek <(spam-protected) 
> <mailto:(spam-protected)>>:
>
>> Hallo!
>>
>> Am 2014-10-21 um 22:38 schrieb gerhard poller:
>>> zeltgaz "master" bei knoten "bici" ex "gaz" ex "geraldo" ex "gaz94" 
>>> knoten am galizinberg  1160
>> Aja.
>>> durch os_bridge logisch auch auf zelt (client_bridge)zu sehen im olsr ;)
>> OK.
>>
>> Eine Bitte: Master immer nach dem Knoten benennen, wo sie stehen. 
>> Also bici.funkfeuer.at <http://bici.funkfeuer.at>, ozw.funkfeuer.at 
>> <http://ozw.funkfeuer.at>, brenner.funkfeuer.at 
>> <http://brenner.funkfeuer.at> ...
>> Das macht die Sache in den meisten Fällen einfacher (Scannen, 
>> ausrichten, Failover/Roaming, ...).
>>
>> Danke!
>>
>>
>>> hf akku
>> LG
>> Erich
>>> *Gesendet:* Dienstag, 14. Oktober 2014 um 14:36 Uhr
>>> *Von:* "Erich N. Pekarek" <(spam-protected)>
>>> *An:* (spam-protected)
>>> *Betreff:* Re: [Wien] zeltgaz.funkfuer.at 
>>> <http://zeltgaz.funkfuer.at> BSSID 00:15:D6:19:10:28
>>> Hallo!
>>>
>>> Klärt mich bitte auf:
>>>
>>> Der Router mit der SSID zeltgaz.funkfeuer.at 
>>> <http://zeltgaz.funkfeuer.at> steht wo?
>>> sulm20 war über die Bridge der Zeltgasse auf einigen Devices zu sehen.
>>> Ich frage, da ich einen Widerspruch vermute, und die Namensgebung 
>>> der SSIDs und der empfangenen Signalstärken auf anderen Geräten dort 
>>> mir nicht ganz zusammenpassen.
>>>
>>> Dann möchte ich noch diesen Thread zweckentfremden:
>>> goldegasse - zeltgasse: möglich, denkbar? Die Nanobridge auf der 
>>> Zeltgasse wäre dafür vorbereitet, ist aber noch nicht exakt 
>>> ausgerichtet.
>>>
>>> Danke, LG
>>> Erich
>>>
>>> Am 2014-10-14 um 14:19 schrieb Martin Shivraj Saini:
>>>
>>>     Hey!
>>>
>>>     Danke vielmals! Wenn  du was brauchst, sag bescheid, bin aber
>>>     leider bis freitag im ausland beruflich......
>>>
>>>     Lg
>>>     Martin
>>>
>>>
>>>
>>>     Am 14.10.2014 00:25, schrieb gerhard poller:
>>>
>>>         danke für die meldung
>>>         5ghz ausfall geraldo - bici
>>>         sind uralte osbridges
>>>         muss ich in kürze  hinfahren vor ort rebooten nachschauen
>>>         hf akku
>>>         *Gesendet:* Montag, 13. Oktober 2014 um 22:40 Uhr
>>>         *Von:* "Martin Shivraj Saini" <(spam-protected)>
>>>         *An:* "FunkFeuer Wien" <(spam-protected)>
>>>         *Betreff:* [Wien] zeltgaz.funkfuer.at
>>>         <http://zeltgaz.funkfuer.at> BSSID 00:15:D6:19:10:28
>>>         hallo,
>>>
>>>         war mit 300deg.sulm20 als client 5GHz mit obenstehendem Master
>>>         verbunden, seit samstag null signal - ist da was vorgefallen?
>>>
>>>         mfg
>>>         martin
>>>
>>>
>>>         --
>>>         Wien mailing list
>>>         (spam-protected)
>>>         https://lists.funkfeuer.at/mailman/listinfo/wien
>>>
>>>     --
>>>     Wien mailing list
>>>     (spam-protected)
>>>     https://lists.funkfeuer.at/mailman/listinfo/wien
>>>
>>>
>>> -- Wien mailing list (spam-protected) 
>>> https://lists.funkfeuer.at/mailman/listinfo/wien
>>>
>>>
>>> --
>>> Wien mailing list
>>> (spam-protected)
>>> https://lists.funkfeuer.at/mailman/listinfo/wien
>>
>> --
>> Wien mailing list
>> (spam-protected) <mailto:(spam-protected)>
>> https://lists.funkfeuer.at/mailman/listinfo/wien

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20141022/f0e8e014/attachment.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signal-0-25.png
Dateityp    : image/png
Dateigröße  : 495 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.funkfeuer.at/pipermail/wien/attachments/20141022/f0e8e014/attachment.png>