Mir ginge es nur um „Mesh on Wan“.
Also WAN und Mesh auf dem gleichen Interface.
Mit anderen Worten: Gar kein herausgeführtes br-client.
BTW: Wäre ein Backport ein BarrierBreaker nichtzielführender?
Nein, da BB auf Kernel 3.10 basiert und wir in CC schon 3.18 haben. Den Support für den Allwinner A20 gibt’s aber erst ab 3.12.
Insgesamt mehr Arbeit als Nutzen zumal das OpenWrt Team geäußert hat dass sie vielleicht jetzt öfter mal ein Release machen wollen 
2 „Gefällt mir“
Dann hoffe ich schlicht mal auf ein OpenWRT-Release vor Ende April.
Ich „missbrauche“ dafür z.B. einen 1043ND
Der lässt sich wunderbar als VLAN-tauglicher 5Port Switch nutzen.
1 GBit-Ethernet-Port reicht dann locker.
Billigere VLAN-tauglichen Switche wirst du kaum finden.
Nebenbei kann der noch mein privates (dank VLAN aber völlig getrenntes) WLAN unterstützen.
Bei mir hat FF-Client, priv. LAN etc. jeweils eigene VLANs, und die meisten Router sind so konfiguriert, daß sie tagged Pakete akzeptieren.
In dem Router kann ich dann über die übrigen Ports jedes gewünchste VLAN raus ziehen.
Das geht übrigens auch mit den 841er, dann aber nur mit den gelben Ports und natürlich nur 100mbit
[edit] es ist tatsächlich sogar ein 6-Port-Switch, bei dem 1 Port mit dem internen SoC fest verdrahtet ist. [/edit]
2 „Gefällt mir“
Vielleicht könntet ihr auch mal zur Abwechselung die deutsche Sprache benutzen, euer Denglisch verirrt GoogleÜ total.
???
[20 zeichen eben…]
Welcome to Freifunk. Eigentlich sollen die Leute experimentieren und eigentlich sollte das Netz nicht gleichgeschaltet sein. Klar, unter operativen Gesichtspunkten will man genau das Gegenteil, aber im Grundsatz sollte jedes technisch kompatible Setup willkommen sein …
Äh, nein?
Ditte. Auf einem Interface ist doof, und der normale BananaPi hat ja, anders als dessen brombäriger Vorgänger, nix auf dem USB-Bus …
1 „Gefällt mir“
Hi,
ich möchte gerne den Durchsatz an unserem Marktplatz erhöhen.
Dort ist eine 150.000UnityMedia Leitung geschaltet.
Aufgrund der geringen Rechenleistung der Router ist da ja bekanntlich schnell schluss.
Nun zu meiner Frage.
Gibt es jemanden der schon mal ein System mit debian/ubuntu aufgesetzt hat und hierzu etwas berichten kann?
Was würde es genau auf der Rechennudel benötigen um den FastD Verschlüsselungsaufwand auszulagern?
FastD sowie BatmanADV sind klar.
Gibts irgendwo config files, Firewall regeln oder sogar ne Anleitung?
Wieviel Rechenleistung wird denn überhaupt benötigt?
Ich hab noch nen alten 1HE Dell im Keller liegen. Der wird ja wohl ausreichen?
RaspberryPI wird wohl nicht viel besser als ein WR841N/D sein.
Wenns gut läuft soll die Kiste auch noch für andere Sachen benutzt werden.
z.B. Fileserver , SIPgateway etc
Gruß
Die Schritte sind grob in einem Pad von @CHRlS zusammengefast und von mir getestet worden.
http://pad.freifunk.net/p/fastd_anbindung
Im Prinzip kannst Du nach diesem Pad vorgehen, Details musst Du testen.
Bisher hatte ich keine Zeit, dass mal ins Reine zu schreiben, wenn Du es machen würdest um so besser.
Als Hardware würde ich einen NUC empfehlen, der Stromverbrauch ist sehr gering und klein sind die Kisten auch.
6 „Gefällt mir“
Wär’s nicht weniger Fehleranfällig dafür 'n x86-Gluon auf den NUC zu installieren? Weniger bastelei, weniger Arbeit beim Upgrade etc…
1 „Gefällt mir“
Wie geil, x86 Gluon. Das war mir bisher entgangen.
Das würde ja standardisierte High-End Clients ermöglichen - coole Idee.
1 „Gefällt mir“
Das x86 Target von Gluon baut aktuell noch mit Fehlern. Ich habe darüber mit Neoraider beim FFNord-Treffen gesprochen. Dort wird aktuell noch an den Eigenheiten der x86 Plattform optimiert. Sollte aber in einer der nächsten Versionen unterstützt werden.
3 „Gefällt mir“
Hach das Gluon X86 würde mich auch interessieren. Vorallem als KVM Instanz auf einer Intel NUC mit durchgereichtem WLAN Adapter
2 „Gefällt mir“
durchgereichtem WLAN-Adapter. Nur einer? Ach so, Du willst ja nur Wifi-Mesh machen, kein Wifi-AP.
Trotzdem: wlan-Hardware (egal ob pci oder gar USB) in virtuelle Maschinen durchreichen: Das ist selten stabil.
Aber ich lasse mich gern eines Besseren belehren.
(Nur warum sich potentielle Baustellen aufmachen, wenn man es vermeiden kann.)
Hi Adorfer,
für mein Verständnis hat docha uch jeder 841er oder so nur einen WLAN Adapter.
Aber ja, ich will nur WLAN Mash damit machen.
zur Stabilität kann ich aktuell noch nichts sagen, da ich noch nicht weiter gekommen bin.
Aktuell ist einfach zu wenig Zeit 
Generell scheint das durchreichen aber stabil genug zu sein. Mehrere Kollegen hier reichen USB Headsets in eine Windows KVM durch um Lync zu betreiben
Und das geht super.
Gruß
Thomas
Hi,
Hab das Pad geupdated, dort war der Split-Horizon/No rebroadcast patch nicht berücksichtigt. Ohne diesen hat man exponentiell mehr Meta-Traffic mit jeder neuen Node im Mesh wenn man Fastd verwendet.
Falls ihr diese Anleitung benutzt habt dann bitte unbedingt die Punkte Fastd Config sowie Batman-Adv kompilieren wiederholen. Dieses Feature is notwendig, falls Rebroadcasts aus dem VPN kommen werden wir die entsprechende Node aus dem VPN ausschließen um den VPN Service nicht zu degradieren.
Gruß
Cyrus
Edit: Hier noch ein paar Infos dazu 
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2013-September/010586.html
Sowie
http://wiki.freifunk.net/images/e/e1/Batman-adv-scalability.pdf ab Seite 31
Im PDF sieht man das der Uplink Traffic bei Nodes von 340kbit/s auf 56kbit/s sinkt wenn Splithorizon aktiv ist. Es ist also signifikant 
Ich spiel das ganze Pad auch mal durch…
Ursprüngliche Idee war, das alles in einen Docker-Container zu verpacken. Bin dann ziemlich schnell drauf gekommen, dass das ja Blödsinn ist, da BATMAN zwingend erforderlich ist, und das nunmal im Kernel läuft.
Habs also aufgegeben. Falls jemand ne Idee hat, wie man das trotzdem backen kann, immer her damit.
Nun baue ich also einen dedizierten Host zum Freifunk-Server um, und hab daher die Frage: Gibt es irgendwelche Anforderungen an die Kernelversion oder Architektur? Läuft das also auf einem Raspberry Pi mit Debian Stable genau so gut wie mit dem amd64-Arch-Linux?
Ich hätte als Platform am liebsten einen Banana-Pi, wenn ich mir was wünschen dürfte.
(CPU-Kraft sollte selbst für eine 200/10er Docsis-Leitung reichen, oder?)
Den gibt es für kaum 50€.
1 „Gefällt mir“
Hab das Pad mal durchgespielt mit einem aktuellen Arch Linux. Leider gibt es da einige Probleme.
Zunächst sei angemerkt, dass ich dies auf einem Host ohne IPv6-Verbindung probiert habe.
Da Arch standardmäßig /etc/network/interfaces und andere Kollegen nicht mehr unterstützt, habe ich es mal mit netctl probiert. Ich hab grade keine Lust mehr weiter rumzuprobieren, da ich annehme dass dies eine Sackgasse ist, und werde später nochmal mit den Legacy-Tools (sind doch die net-tools oder?) probieren
Am Ende habe ich es in der Tat geschafft, eine Verbindung aufzubauen, aber ein Neustart lief nicht sauber durch. Am Ende fand ich heraus, dass ich genau folgende Reihenfolge einhalten muss:
ip link set down br0
systemctl stop fastd@rheinufer
systemctl start fastd@rheinufer
systemctl start netctl@br0
Alles andere führt dazu, dass br0 keine IP erhält. Auch nicht versuchen irgendwie aus den aufeinanderfolgenden stop/start-Befehlen ein restart zu machen, das funktioniert ebenfalls nicht! Außerdem ist es nicht möglich eine IPv6 per SLAAC anzufragen, weil dann ebenfalls DHCPv4 scheitert.
Als weiteres Problem war es mir nicht möglich, eine feste MAC-Adresse auf br0 zu setzen, da netctl anscheinend nicht den Fall berücksichtigt, einer Bridge eine MAC zuzuteilen. Ich habe also immer eine zufällige (nehme ich an…) von bat0 bekommen. Ist irgendwie doof. Ich habe außerdem versucht bei IfPreUp zu versuchen br0 mit dem ip-Befehl eine MAC zu geben, aber das hat auch irgendwie nicht geklappt. Ich weiß den Befehl den ich probiert hab leider nicht mehr, kann auch mein Fehler sein.
/etc/netctl/br0:
Description="fastd bridge"
Interface=br0
Connection=bridge
BindsToInterfaces=()
IP=dhcp
#IP6=stateless # breaks everything
## Ignore (R)STP and immediately activate the bridge
SkipForwardingDelay=yes
/etc/fastd/rheinufer/fastd.conf
bind 0.0.0.0:10040;
include "secret.conf";
interface "tap0";
log level info;
mode tap;
method "aes128-gcm";
method "salsa2012+gmac";
method "xsalsa20-poly1305";
method "null";
mtu 1426;
secure handshakes yes;
log to syslog level error;
user "fastd";
peer "rheinufer0" {
key "1f9ad5481a6773d963fa38980afbf7d296163070aecd8d600863d866bafddf32";
remote "rheinufer0.freifunk-rheinland.net" port 10040;
}
peer "rheinufer1" {
key "ab8959c1f974fa24354734f5bbe8106f8980a1b33eff22be580d9bcd3052e357";
remote "rheinufer1.freifunk-rheinland.net" port 10040;
}
peer "rheinufer2" {
key "4ab84305bad610bf8c8b76c7897aa97dd4740893f680ac486ee1ee0b7e4ec18b";
remote "rheinufer2.freifunk-rheinland.net" port 10040;
}
peer "rheinufer3" {
key "052ff3cc4d383ce4797ef12f4dabe22b8fc62c76e24f9b7827fe14c11522c474";
remote "rheinufer3.freifunk-rheinland.net" port 10040;
}
on up "
ip link set up dev tap0
batctl -m bat0 if add $INTERFACE
batctl -m bat0 it 5000
batctl -m bat0 bl enable
batctl -m bat0 vm client
echo 1 > /sys/class/net/tap0/batman_adv/no_rebroadcast
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1
ip link set up dev bat0
brctl addif br0 bat0
ip route replace 10.0.0.0/8 via 10.53.16.254
ip route replace 172.0.0.0/8 via 10.53.16.254
";
Ich hoffe das hilft anderen bei ähnlichen Versuchen! (Auf die Gefahr hin mich lächerlich zu machen, weil ich teilweise nicht wirklich weiß, was ich da getan hab )
Am Ende stand ich übrigens da mit Konnektivität ins IPv4 Internet über fastd, und hatte selber eine IP aus dem 10.40.0.0/16. Reicht zwar noch nicht, um selber was zu hosten (IPv6 fehlt), aber ich weiß auch gar nicht, ob das so gewünscht ist…
Selber als VPN-Uplink für die Nodes zu agieren hab ich noch nicht probiert, kann sein dass das funktionieren würde…
Wie @adorfer immer so schön sagt: „Ich mach mal die Ingrid“
Jetzt hab ich die Configs ins Forum gepostet und nun seh ichs auf einmal:
ip route replace 10.0.0.0/8 via 10.53.16.254
ip route replace 172.0.0.0/8 via 10.53.16.254
Klingt irgendwie doof oder? Zumindest, wenn man alles auf Rheinufer umgeschrieben hat.
s/10.53.16.254/10.40.250.1/
und presto! Nun krieg ich auch wesentlich schneller meine IPs, und ich kann auch die Reihenfolge der Befehle nun verändern. Alles wesentlich robuster. Auch kann ich die IPv6-Zeile auskommentieren und habe trotzdem Verbindung (ich krieg aber immer noch keine IPv6…)
Ehrlich gesagt frage ich mich, wieso es vorher ging, wo kam die korrekte Route her? oO
Fragen über Fragen. Jedenfalls seid ihr schonmal gute Quietscheentchen.
EDIT: Korrektur: Alles wieder wie vorher, nun geht es auch mit der Befehlsreihenfolge, die vorher immer so schön aus der Patsche geholfen hat, nicht mehr. Komische Kiste. War wohl doch nur alles Cargo Cult.
1 „Gefällt mir“