Hood file
|
Hood
|
Überblick
Das Hood File enthält die Konfiguration der Router in einer V2-Hood bzw. für dezentrale Hoods basierend auf der L3-Firmware.
Dieses Hood File wird dann per Mesh weitergegeben.
Zentrale Hoods
Für die zentral verwalteten Hoods erhält man je nach Koordinaten ein Hoodfile vom KeyXchangeV2 (alle Router mit Internet-Uplink rufen einfach diese Adresse auf):
ACHTUNG: HIER HANDELT ES SICH NUR UM EIN BEISPIEL UND DARF NIRGENDWO ANDERS EINFACH UNGEÄNDERT ÜBERNOMMEN WERDEN
http://keyserver.freifunk-franken.de/v2/?lat=50.0&long=20.1
Inhalt:
{"version":1,"network":{"ula_prefix":"fd43:5602:29bd:abcd:\/64"},"vpn":
[{"name":"fff-test1","protocol":"fastd","address":"127.0.0.1","port":"10003",
"key":"1234123412341234123412341234123412341234123412341234123412341234"},{"name":"fff-test2","protocol":"fastd","address":"127.0.0.1","port":"10008",
"key":"4321432143214321432143214321432143214321432143214321432143214321"}],
"hood":{"name":"IchBinDumm","essid":"ichbindumm.freifunk",
"mesh_bssid":"","mesh_essid":"ibd.batman.fff",
"mesh_id":"ibd.mesh.fff","protocol":"batman-adv-v15",
"channel2":"13","mode2":"ht20","mesh_type2":"802.11s","channel5":"40",
"mode5":"ht20","mesh_type5":"802.11s","upgrade_path":"",
"ntp_ip":"fd43:5602:29bd:ffff::DAS_NICHT_NEHMEN_GRUMML","timestamp":"1515353626",
"location":{"lat":"50.0000","lon":"20.1000"}}}
lesbar:
{
"version":1,
"network":{
"ula_prefix":"fd43:5602:29bd:abcd:\/64"
},
"vpn":[
{
"name":"fff-test1",
"protocol":"fastd",
"address":"127.0.0.1",
"port":"10003",
"key":"1234123412341234123412341234123412341234123412341234123412341234"
},
{
"name":"fff-test2",
"protocol":"fastd",
"address":"127.0.0.1",
"port":"10008",
"key":"4321432143214321432143214321432143214321432143214321432143214321"
}
],
"hood":{
"name":"IchBinDumm",
"essid":"ichbindumm.freifunk",
"mesh_bssid":"",
"mesh_essid":"ibd.batman.fff",
"mesh_id":"ibd.mesh.fff",
"protocol":"batman-adv-v15",
"channel2":"13",
"mode2":"ht20",
"mesh_type2":"802.11s",
"channel5":"40",
"mode5":"ht20",
"mesh_type5":"802.11s",
"upgrade_path":"",
"ntp_ip":"fd43:5602:29bd:ffff::GRUMML_NOCH_MEHR",
"timestamp":"1515353626",
"location":{
"lat":"50.0000",
"lon":"20.1000"
}
}
}
Da die Hoodfile bei zentralen Hoods auf allen Gateways exakt gleich sein muss (muss das nach Alpha immer noch? Bitte prüfen!) darf die Datei am Gateway nicht verändert werden und muss 1:1 wie vom keyxchange geliefert verwendet werden!
Für andere Hoods kann die Hoodfile hier gefunden werden: http://keyserver.freifunk-franken.de/v2/hoods.php
Dezentrale Hoods
Werden die dezentralen Hoods per Hood-File konfiguriert, entfällt die VPN-Konfiguration aus obigem Beispiel. Stattdessen baut man einfach
"vpn":[],
ein.
Die Angabe der Location kann entweder im Hoodfile (wie oben) oder in der /etc/config/fff (manuell oder per WebUI) erfolgen.
Router mit manuellem Hoodfile in /etc/hoodfile können nur mit Routern meshen, auf denen ebenfalls manuell das Hoodfile installiert wurde. Solche Router bekommen auch kein zentrales Hoodfile mehr, wenn später eine gleichnamige Hood existieren sollte, außer das manuelle Hoodfile wird wieder vom Router gelöscht.
Parameter
| Name | Optionen | Beschreibung |
|---|---|---|
| version | "1" | ... |
| network:ula_prefix | IPv6 prefix (<=64) | Prefix für Router und Clients in der Hood (aus dem ganzen FF-Netz erreichbar) |
| vpn | Liste | Gateway-VPN-Daten |
| vpn:name | string | Bezeichner des FastD Interfaces |
| vpn:protocol | "fastd" | - |
| vpn:address | IP | Öffentliche IP Adresse des Gateways |
| vpn:port | int | FastD Port |
| vpn:key | Keystring | Öffentlicher FastD Schlüssel, kann auf dem Gateway abgefragt werden mit "fastd --show-key -c /etc/fastd/<Interface>/fastd.conf" |
| hood:name | string | Anzeige-Name der Hood (möglichst ohne Leerzeichen) |
| hood:essid | SSID | SSID für den Wifi AP |
| hood:mesh_bssid | BSSID | BSSID für Mesh via IBSS |
| hood:mesh_essid | ESSID | ESSID für Mesh via IBSS |
| hood:mesh_id | SSID | SSID für Mesh via 802.11s |
| hood:protocol | "batman-adv-v15" | andere Angaben setzen eigene FW-Implementierung voraus |
| hood:channel2 | int | WLAN-Kanal 2.4 GHz |
| hood:mode2 | "ht20" | WLAN-Frequenzbreite 2.4 GHz |
| hood:mesh_type2 | "802.11s"/"ibss"/"none" | Mesh-Protokoll ("none" deaktiviert Meshing in der Hood) |
| hood:channel5 | int | WLAN-Kanal 5 GHz |
| hood:mode5 | "ht20" | WLAN-Frequenzbreite 5 GHz |
| hood:mesh_type5 | "802.11s"/"ibss"/"none" | Mesh-Protokoll ("none" deaktiviert Meshing in der Hood) |
| hood:upgrade_path | URL | URL of upgrade server |
| hood:ntp_ip | IP | IP address of NTP Server |
| hood:timestamp | Timestamp | Last change of Hood file |
| hood:location:lat | double | Hood center location latitude (or dez. GW Position) |
| hood:location:lon | double | Hood center location longitude (or dez. GW Position) |
Wie finde ich eine sinnvolle SSID
Mit dem KeyXchangeV2 erhält jede Hood ihre eigenen SSIDs, wie es eigentlich schon von Anfang an sinnvoll gewesen wäre. Dies ist notwendig, damit ein Client erkennen kann, mit welchem Gateway er kommunizieren muss.
In meiner Region gibt es keine individuelle V2-Hood. Ich will aber nicht die SSID einer anderen Stadt ausstrahlen!
Siehe: KeyXchangeV2#FAQ
Kann ich trotzdem die alte SSID franken.freifunk.net ausstrahlen?
Wir können es nicht verhindern. Allerdings wirst du dir damit keine Freu(n)de machen:
In ländlichen Gebieten ist das Problem der Hood-Überlappung selten ein Problem. Theoretisch wäre es hier technisch kein Problem, wenn eine Hood franken.freifunk.net ausstrahlt, wenn alle anderen etwas anderes ausstrahlen. Selbst bei zwei benachbarten Hoods ist der Weg für einen sich bewegenden Client u.U. lange genug, dass es nicht/selten zu Problemen kommt.
ABER: So lange V1-Router herumstehen, existiert immer eine Verschränkung zweier Hoods, nämlich der lokalen V1- und V2-Hood. Dies führt dazu, dass ein Endgerät (z.B. Handy) anhand der SSID nicht zwischen V1- und V2-Routern unterscheiden kann. Hat es die IP von einem V2-Gateway, kriegt es dann von einem V1-Router keine Daten und umgekehrt.
Da wir noch für einige Zeit von einer Parallelexistenz von V1 und V2 ausgehen müssen und aus den o.g. technischen Gründen ist daher eine Verwendung von franken.freifunk.net mit V2 keine Option.
Aber dann muss ich alle Flyer, Infomaterial, Speisekarten, etc. ändern!
Kurze Antwort: ja!
Einige Nutzer sind daher dazu übergegangen, keine SSID mehr irgendwo abzudrucken, sondern nur lapidar auf "Freifunk" zu verweisen. Es ist zu erwarten, wenn jemand kostenloses WLAN will, dass er es schafft in der Liste auf etwas mit Freifunk zu klicken.
Wer keine Lust hat, mit drölfzig Leuten darüber zu diskutieren, kann natürlich auch einfach etwas an die bestehende SSID anhängen oder davor schreiben:
Beispiel Bayreuth (Kennzeichen BT):
bt.franken.freifunk.net
franken.freifunk.bt
Mit solchen Varianten ist man nahe genug an der ursprünglichen SSID, dass sich in meinen Augen niemand beschweren kann. Ob man das so löst oder es vielleicht im Hinblick auf die Zukunft gleich ordentlich macht, ist jedem GW-Betreiber selbst überlassen.
Wie wähle ich eine gute SSID für den Access Point
Neben der Notwendigkeit etwas zu ändern (siehe voriger Punkt) bietet das freie Gestalten einer SSID gewisse Vorteile zwecks Benutzerfreundlichkeit. Da viele Nutzer Mobiltelefone einsetzen, wird häufig eine lange SSID nicht vollständig angezeigt. Daher sollte die relevante Information am Anfang stehen.
Dies ist je nach Präferenz etwas anderes:
- Einige drehen die bisherige Schreibweise um, sodass "freifunk" am Anfang steht und so unmittelbar vom Nutzer erkennbar ist, z.B. freifunk.bayreuth
- Einige wollen die Region bewusst als Identifikationsmerkmal einsetzen und stellen diese voran, z.B. fichtelgebirge.nord.freifunk
Hier ist das neue System also flexibler und wenn man so will auch dezentraler.
Wie wähle ich eine gute SSID für das Mesh-Netz
In V1 strahlt jeder Router zwei SSIDs aus:
- franken.freifunk.net
- batman.franken.freifunk.net
Dies führt gelegentlich bei Nutzern zu Verwirrung, die sich versehentlich ins B.A.T.M.A.N.-Netz einwählen. Auch hier bietet die manuelle Konfiguration gewisse Vorteile:
So wie ich bei der SSID für AP auf eine gute Nutzerfreundlichkeit/Erkennbarkeit setze, so kann ich bei der Mesh-SSID dafür sorgen, dass sie dem Nutzer nicht gleich ins Auge springt. Trotzdem kann man aber alle relevanten Informationen einbauen. Statt "freifunk" kann man dann z.B. "fff" verwenden - schon wird kaum ein Nutzer noch drauf klicken, aber für Debugging etc. ist klar noch erkennbar, worum es sich handelt. Ähnlich kann man mit den anderen Elementen verfahren:
bt.mesh.fff (Für Bayreuth)
nmesh.fichtel.fff (Für FichtelgebirgeNord)
Wenn jemand lieber mesh.bayreuth.freifunk.net austrahlt, steht dem technisch natürlich nichts im Wege. Lediglich muss die Eindeutigkeit natürlich auch hier auch gewahrt bleiben.
Warum gibt es mehrere Mesh-SSIDs
V2 ist so konzipiert, dass sowohl IBSS als auch 802.11s verwendet werden kann. Da pro Hood nur eine Variante aktiviert ist, kann prinzipiell auch für beides die selbe ESSID verwendet werden. Für IBSS ist zusätzlich eine BSSID notwendig.
Für Debugging etc. empfiehlt sich allerdings, beide Varianten unterschiedlich zu benennen und dies auch von Anfang an einzutragen, wenn man die Hood aufsetzt. Zum Beispiel:
802.11s: bt.mesh.fff IBSS: bt.ibss.fff
Kostet nichts und macht viel Freude ...
Ich betreibe ein dezentrales Gateway
Wenn das dezentrale Gateway V2-Router unterstützen soll, sind alle Hood File-Parameter sowie die o.g. Überlegungen identisch. Insbesondere muss hier die zusätzliche Überlappung von dez. Hood und zentraler V2-Hood bedacht werden (zwecks SSID-Auswahl). Gleiches gilt für die Gatewayfirmware.
Im Gegensatz zu einer regulären V2-Hood wird das Hood-File jedoch nicht am KeyXchange abgelegt, sondern existiert NUR auf den Gateways. Für den seltenen Fall einer dezentralen Hood mit mehr als einem GW ist hier auf die Synchronisierung der Hood-Files zu achten, sonst geht einiges kaputt!
Hood-Location
Wie platziere ich meine Hood?
Zur Zeit (Juni 2018) haben einige V1-Hoods das Problem (z.B. Erlangen, Nürnberg), dass sie sehr viele Router (> 100) und Clients (> 300) in ein L2-/B.A.T.M.A.N.-Netz stopfen. In einer Stadt konnte man bisher jedoch auch nicht vernünftig teilen, da ja sonst immer irgendwo ein Mesh die beiden Hoods verbinden würde. In den ländlichen Gebieten sind solche Teilungen größtenteils schon lange erfolgt.
Mit V2 ist genau das jedoch kein Problem mehr. Man kann jetzt Trennlinien quer durch die Stadt ziehen, ohne dass irgendwas kaputt geht. Findet ein Mesh über die Grenze statt, ist das auch kein Problem, solange nicht mehrere Uplinks beteiligt sind. In letzterem Fall teilen sich dann die Mesh-Router automatisch entsprechend auf.
Man könnte also ohne weiteres z.B. Erlangen in 3-4 Hoods oder Forchheim in 2 Hoods aufteilen und hätte damit plötzlich viel kleinere und performantere Netze. (Das Ganze wird natürlich immer noch viel langsamer sein als ein ordentlich Layer3-Setup.) Wenn sich jemand ohnehin Gedanken macht, ein V2-Gateway zu bauen, sollte dann auch der Aufwand eine weitere Hood einzurichten wesentlich kleiner sein als der Aufwand, das Gateway an sich aufzusetzen. Ich würde also für einen solchen Fall anregen, sich möglichst früh Gedanken über eine sinnvolle Hoodaufteilung zu machen!
Wie kann ich die Position einer Hood testen
V2-Hoods können hier testweise platziert werden:
https://freifunk.jubt.org/voronoi1.php
Eine Übersicht der V1-Hoods ist verfügbar unter:
https://freifunk.jubt.org/voronoi-v1.php
Durch Entfernen der Haken kann die Abschaltung von Hoods simuliert werden.
