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 <[email protected]
<mailto:[email 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" <[email protected]>
*An:* [email 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" <[email protected]>
*An:* "FunkFeuer Wien" <[email 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
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/wien
--
Wien mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/wien
-- Wien mailing list [email protected]
https://lists.funkfeuer.at/mailman/listinfo/wien
--
Wien mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/wien
--
Wien mailing list
[email protected] <mailto:[email protected]>
https://lists.funkfeuer.at/mailman/listinfo/wien
--
Wien mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/wien
