[Berlin-wireless] EMMAUS allgemein - Linkstrecken

[Sven-Ola Tuecke]

Achja. Ich könnte ja mal zusammenfassen was ich bereits 'rausgefunden
habe. Also:

- Im AP Repeater-Modus können sich zwei Access-Point gegenseitig
(Ar-)Pingen. Voraussetzung: die sind nicht im Kanal woanders gelandet
(DFS) und die haben dieselbe ESSID. An beide AP können zusätzlich noch
Clients/STA dran. Da kann auch noch zusätzlich noch ein weiterer VAP
drauf, z.B. für BatmanAdv-DHCP-Clients. Funzt alles wunderbar.

- Leider wird die Betriebsart für 2 verschiedene Topologien benutzt:
Punkt-zu-Punkt und Stern / Mesh (mit mind. einer weiterleitende
Zwischenstation. Wenn ein AP zwei andere APs in der Station-Tabelle hat,
dann schaltet er die Paketwiederholung ein ("Repeating-AP"). Das heisst:
die "ath0"-Schnittstelle (der Madwifi-Treiber) sendet, was gerade
empfangen wurde. Geht nicht durch den Kernel. Lässt sich auch nicht mit
ebtables verhindern.

- So ein Repeating-AP sendet Pakete gleich wieder 'raus, die er von
anderen verbundenen APs erhält. Jedenfalls dann, wie die Ziel-MAC des
Pakets FF:FF:FF:FF:FF:FF ist. Aber auch nicht immer. Die Ubiquiti-Foren
haben eine Reihe von Postings, wo sich Leute darüber beschweren, dass es
eben *nicht* wiederholt. Ich hab' jetzt eher das Problem, dass die
Dinger selbständig wiederholen und sich so ein Broadcast-Karussell aufbaut.

- Es gibt offenbar eine Treiber-intern geführte Liste mit
"Pakete-von-diesen-Quell-MACs-nicht-wieder-raussenden". Oder ein
Paketfilter gleichen Zwecks. Kann man alles nicht sehen, weil der
Madwifi da drin ist eine Ubnt-Eigenweiterentwicklung. Und das werden sie
wohl niemals veröffentlichen. Ich sende z.B. ein Paket mit "ARP whohas"
mit der MAC-Adresse einer vierten Atheros-Karte in das Karussell. Die
Pakete kreisen (tausendfaches MAC-von-Karte an FF:FF:FF: "wo bist
du...?"). Verbinde ich jetzt diese vierte Karte mit einem der APs: dann
hört das Karussell sofort auf. Spricht für die Theorie der "Liste mit
MACs die nicht wiederholt werden sollen".

- Leider gibt's kein "iwpriv ath0 lass-das-wiederholen-sein". Oder ein
"iwpriv ath0 do-not-repeat-this-mac". Wenn es überhaupt auf iwpriv
'rausgeführt ist. Die Web-UI (z.B. die Station-Anzeige) unterhält sich
per Pipe+ExtraIOCtl mit dem Extra-Ubiquiti-Kernelmodul da drin. Nicht
die feine Art - funzt aber wohl in der Praxis...

- Achso. Karussell anhalten. Geht ganz einfach: auf einer der
Karussell-APs kurzes "ip l set dev ath0 down;ip l set dev ath0 up" und
es hört auf.

Achso. Fazit. Diese AP-Repeater-Geschichte funzt in jedem Fall
zuverlässig zwischen *zwei* APs. Das Problem tritt ja erst mit dem
dritten AP auf. Und auch nur dann, wenn sich alle 3 APs einigermaßen
zuverlässig untereinander etwas zusenden können. Sonst frisst der
Paketverlust-Teufel die kreisenden Pakete irgendwann von ganz alleine.
Man könnte es auch ignorieren - aber ich will *zuverässige* Setups und
keins was bei der nächsten Gelegenheit tagelang Broadcast-stürmt...

// Sven-Ola

Am 25.02.2014 12:40, schrieb Sven-Ola Tuecke:
> Ich hätt' halt gerne diese
> AP-Repeater-Geschichte


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 263 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140225/979739b7/attachment.pgp>