Benutzer:Lars/Blog:2015 July 21 00:02:51 CEST

Aus Opennet
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Montagstreffen (20.07.2015)

Besuch

  • Ein zukünftiges Lohro-Mitglied war zu Besuch (Steve). Johannes hat gleich eine Nanostation M5 vorbereitet und ihm mitgegeben. Wir freuen uns über Feedback.

Christian-Ersatz / Finanzen im nächsten Jahr

  • Christian hat angedeutet, dass er nächstes Jahr nicht mehr als Finanzer nicht mehr zur Wahl steht.
  • Es stellt sich die Frage, was die Aufgaben eines solchen Posten sind und wie sich die aktuell in Aufwand wiederspiegelt?

vServer (in-berlin.de)

Im Rahmen des IPv6 Ausbaus, benötigen wir noch ein UGW-Server, welcher große IPv6 Netze (>/60) zur Verfügung stellt. Dies ist bei allen derzeitigen Hostern ohne größeren geldlichen Aufwand nicht möglich. Daher hat Martin einen neuen vServer bei www.in-berlin.de angemietet. Der Provider ist in einer Genossenschaft organisiert und hier scheint es möglich auch größere IPv6 Netze zu veralten. Der Berliner Freifunk Verein betreibt dort auch Server. Passenderweise ist der neue Server unter opennet-initiative.in-berlin.de erreichbar. Bisher ist noch nichts konfiguriert.

todo:

  • UGW-Server Konfiguration einspielen (mittels Ansible, Server Installation/Ansible)
  • Erweiterung der bisherigen IPv4 UGW Konfiguration um IPv6 erweitern. Teilweise gibt es schon Dinge, welche früher auf dem aten erina liefen. Hier sollte Mathias mehr wissen.
  • größeren IPv6 Block (/56) bei Freifunk.net anfragen.
  • Den von Freifunk.net freigegebenen IPv6 Block über in-berlin.de erreichbar machen.

Ziel: Am Ende soll es möglich sein, dass User, welche das in-berlin.de Gateway als UGW Server nutzen, einen /64 Block für ihr Heimnetz bekommen.

Wireless-Regulierung für 5 GHz

Kanal 36-48

  • nur indoor verwendbar ("sicherstellen, dass sie die nur innerhalb von Gebäuden empfangen werden können")
  • bis 200mW Sendeleistung (23dBm)
  • DFS + TPC sind nicht erforderlich

Kanal 52-64

  • DFS + TPC sind Pflicht
  • bis 200mW Sendeleistung (23dBm)
  • ansonsten identisch zu Kanal 36-48, d.h. nur in Innenräumen verwendbar

Kanal 100-140

  • DFS + TPC sind Pflicht
  • maximale Sendeleistung (1W, 30dbm)

Kanal >140

  • nur für Provider ("Versorgung im ländlichen Raum")
  • DFS und TPC sind ebenfalls erforderlich
  • 4W Sendeleistung

Verbesserungsmöglichkeiten für DFS

1. Vermeiden von Indoor-Kanälen
    • chanlist-Option: es muss ein Patch entwickelt werden, damit die chanlist-Option in hostapd.conf über eine passende UCI-Variable definiert werden kann
    • mit der chanlist-Option kann Whitelist erlaubter Kanäle für hostapd vorgegeben werden, so dass wir hostapd's Kanalauswahl z.B. auf 100-140 beschränken können um zu verhindern, dass Radar-Erkennung dazu führt, dass hostapd auf einen Indoor-Kanal springt
2. Interimsproblem
  • hostapd regelmäßig motivieren, nach der Radarerkennung (nach einiger Zeit) wieder auf einen Outdoor-Kanal zu wechseln
  • aktuell: hostapd springt nach massiver Radarerkennung irgendwann auf einen Indoor-Kanal und bleibt da, weil dort nie wieder Radar erkannt wird (weil nicht danach gesucht wird)
  • Ansatz: per Cronjob regelmäßig prüfen, ob wir auf einem Indoor-Kanal sind und wenn ja hostapd anweisen, auf einen Outdoor-Kanal zu wechseln
  • Weg: "chan_switch" Kommando via hostadp-Control-Interface absetzen (hostapd_cli kann das)
  • Problem: hostapd antwortet aktuell immer mit "FAIL", wegal, auf welchen Kanal er wechseln soll
3. Radar-Erkennung ist "empfindlich"
  • Aktuell detektiert Linux auf manchen APs (z.B. 2.5 auf der Südstadtklinik) auf (fast?) allen Outdoor-Kanälen Radar
  • das führt dazu, das kurz nach dem Booten schon auf einen Indoor-Kanal gesprungen wird (da dort keine Radarerkennung gemacht wird, bleibt der hostaps dann dort)

Sonstiges

  • Die Getränkereserven wurden aufgefüllt (Mate + Bier).
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge