bind 0.0.0.0:10000;
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 "mesh_vpn_backbone_peer_rheinufer3" {
key "052ff3cc4d383ce4797ef12f4dabe22b8fc62c76e24f9b7827fe14c11522c474";
remote "rheinufer3.freifunk-rheinland.net" port 10040;
}
peer "mesh_vpn_backbone_peer_rheinufer1" {
key "ab8959c1f974fa24354734f5bbe8106f8980a1b33eff22be580d9bcd3052e357";
remote "rheinufer1.freifunk-rheinland.net" port 10040;
}
peer "mesh_vpn_backbone_peer_rheinufer2" {
key "4ab84305bad610bf8c8b76c7897aa97dd4740893f680ac486ee1ee0b7e4ec18b";
remote "rheinufer2.freifunk-rheinland.net" port 10040;
}
peer "mesh_vpn_backbone_peer_rheinufer0" {
key "1f9ad5481a6773d963fa38980afbf7d296163070aecd8d600863d866bafddf32";
remote "rheinufer0.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 server
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
";
Der Server soll das machen was ein Server macht Er muss nicht als Gateway dienen. Ich bräuchte halt nur ne IP um loszulegen,
@thomasDOTwtf ich habe laut der Anleitung batman installiert. Ob das nun richtig war kann ich nicht sagen. Wie finde ich das herraus?
Gar nicht gut, wenn dies kein Supernode ist am besten sofort den Server Mode aus für Batman. Du störst sonst den Zugang für alle anderen Netzteilnehmer.
Tests mit sowas am besten nur im eigenen Test-Mesh Falls vorhanden. Ansonsten lokal mit zwei Laptops oder ähnlichem testen.
Z.b. Dienste im Mesh bereitstellen, eigenes Monitoring der Nodes innerhalb des Meshes oder auch einfach nur für Remote-Zugriff auf Nodes falls das Routing mal nicht klappt.
vm server, bedeutet das nicht nur, dass das Ding in den Karten schließlich als Server, nicht als Node erscheint? Das mit dem Supernode geht doch mit dem Befehl gw bzw. gw_mode.
Einstellungen unter batctl vm (auch batctl vis_mode) betreffen die Auslieferung der Daten über die Netztopologie (das woraus dann mal die Karte erstellt wird).
„client“ bedeutet hier, dass der Knoten seine Daten wie jeder andere Teilnehmer auch an den jeweiligen Server schickt.
„server“ bedeutet, dass der Knoten sich selbst als Server bekannt macht und Clients an ihn Daten schicken.
Wenn du mehrere vis_mode Server gleichzeitig betreibst, kommt es zu lustigen Effekten. So werden zB nicht mehr alle Daten an den eigentlichen Server geschickt (der dann die Karte generiert) und auf der Karte fehlt plötzlich ein großer Teil des Netzwerks.
Deswegen am besten nichts an dieser Einstellung ändern, es sei denn du weißt ganz genau was du tust.
vis_mode ist in Gluon rausgepatcht und in der nächsten Batman-adv.-Version vollständig verschwunden. Als Normalsterblicher stellt man sie auf client; oder off, wenn die Wolke die Daten via Alfred übermittelt. Mit vis_mode off war der Knoten vor Alfreds Zeiten unsichtbar. Mit vis_mode server habe ich in unserer alten Wuppertaler Installation keine Nachteile bei mehreren Servern gesehen; die Wolke war aber nicht so riesig. Grundsätzlich gibt es Probleme mit Schmalband Internetanschlüssen. Mit Alfred macht man seinen Knoten/Server so (provisorisch) sichtbar:
Man sollte ich in Alfred einarbeiten, wenn darüber die Informationen in der Wolke ausgetauscht werden.
gw_mode stellt man bitte auf client, wenn der Server DHCP erhalten soll. Wenn man seine Freifunk-Wolke nicht sabotieren möchte, stellt man gw_mode niemals auf server!
Dies kann Probleme mit der Visualisierung bringen, Nodes die dann fehlen z.b.
Die FFMap ist jetzt schon unstable weil es durch das Packetloss Merging-Probleme gibt und dies verstärkt das Problem nur zusätzlich.
Nur Supernodes bzw Map-Server sollten diese Option aktiviert haben.