Probleme mit dem ffmap-backend

Technik
#50

Bist du sicher, dass du den aktuellen master von ffmap-backend hast? Die Abhängigkeit von der Clientzahl in den alfred-Daten ist erst im dev Branch (Achtung: Dafür gibt’s noch kein Frontend) aus genau dem Grund drin. master zählt im Moment noch Clients in batadv-vis.

1 Like
#51

ja, mein Problem basierte ja darauf, dass mein ffmap-d3 (Branch for-uplink) mit den Clientanzahldaten des aktuellen ffmap-backend Masters bei Nodes mit Gluon älter oder gleich 2014.3.1 nichts anfangen konnte (angeblich 0 Clients). Mit Gluon 2014.4 werden die Clients korrekt angezeigt, „clientcount“ in der nodes.json…
Hab jetzt leider keinen Node mit 2014.3 mehr zum testen.
https://github.com/freifunk-ehingen/ffmap-backend
https://github.com/freifunk-ehingen/ffmap-d3/tree/ehingen-master

#52

Wie wäre es mit einer Test-/Pilotumgebung, die schrittweise aufgesetzt wird, eine prima Map zeigt und erst nach einer Übergangsfrist, nach der sich alle an die neuen Gegebenheiten angepasst haben, das alte System komplett ersetzt?

#53

Deine Arbeit ist großartig Nils! Vielen Dank für ffmap-d3.

Ich nutze Gentoo und ich habe was dagegen, dass mir npm und Grunt irgendetwas am System vorbei installieren. Mir reicht ein klares „dies und jenes muss sich auf dem System befinden, notfalls bitte deinen Administrator darum“ und die Installation der ffmap-d3 sollte ohne Root-Rechte möglich sein. Für das Backend habe ich über Sudo den Zugriff auf die Batman-Tools erlaubt, aber das ist von Batman so gewollt, dass es ein Root bedient.

Ich habe von Webentwicklung keine Ahnung und bin das, was npm und Grunt anstellen nicht gewohnt.

#54

Das ohnehin!

Aber ohne einen Entwickler der sich committed (sei es Domi, Julian oder ein neuer) bringt uns das nicht weiter…

#55

npm und Grunt kann man beides so verwenden ohne dass es wild ins System schreibt. Sowas gefällt mir nämlich auch garnicht. Die Doku dazu in der README ist aktuell tatsächlich etwas dürftig. Werde ich demnächst überarbeiten. Bis dahin helfen vielleicht meine Notizen:

1 Like
#56

Wär ich dabei, sowas zu pflegen und zu entwickeln. Derzeit entwickle ich halt gegen Upstream (ffnord/ffmap-d3) und Nils hat mir mittlerweile dort auch Schreibrechte verpasst.

Ich hab derzeit leider keine leistungsfähige Hardware im Mesh, sodass ich selber immer nur temporär Dinge hosten kann. Eventuell sollte ich das mal ändern :wink:

#57

Kann ich Dir bereitstellen, das ist das kleinste Problem!

#58

Wir haben gestern batman-adv aus dem freifunk-gluon Repository auf unserem Gateway installiert (soll ja viele patches beinhalten). Seitdem schmiert mkmap.sh mit folgendem Fehler ab:

Traceback (most recent call last):
  File "./batman.py", line 77, in 
    vd = bc.vis_data()
  File "./batman.py", line 13, in vis_data
    vds = self.vis_data_batctl_legacy()
  File "./batman.py", line 31, in vis_data_batctl_legacy
    output = subprocess.check_output(["batctl","-m",self.mesh_interface,"vd","json","-n"])
  File "/usr/lib/python3.4/subprocess.py", line 616, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command '['batctl', '-m', 'bat0', 'vd', 'json', '-n']' returned non-zero exit status 1
#59

Die Version hat kein batadv-vis:

#60

also batadv-vis (selbst kompiliert) liefert Daten:

root@gw1:~# batadv-vis
digraph {
	subgraph "cluster_ea:98:f6:2a:94:9e" {
		"ea:98:f6:2a:94:9e"
	}
	"ea:98:f6:2a:94:9e" -> "56:4b:5d:3c:ef:eb" [label="1.000"]
	"ea:98:f6:2a:94:9e" -> "e8:94:f6:2a:94:9e" [label="TT"]
	"ea:98:f6:2a:94:9e" -> "34:23:ba:d5:cd:1d" [label="TT"]
	"ea:98:f6:2a:94:9e" -> "b8:27:eb:c5:31:92" [label="TT"]
	"ea:98:f6:2a:94:9e" -> "68:09:27:08:f9:12" [label="TT"]
	subgraph "cluster_a2:f7:c1:65:50:ee" {
		"a2:f7:c1:65:50:ee"
	}
	"a2:f7:c1:65:50:ee" -> "56:4b:5d:3c:ef:eb" [label="1.000"]
	"a2:f7:c1:65:50:ee" -> "a0:f3:c1:65:50:ee" [label="TT"]
	"a2:f7:c1:65:50:ee" -> "c0:9f:42:6c:4d:78" [label="TT"]
	subgraph "cluster_56:4b:5d:3c:ef:eb" {
		"56:4b:5d:3c:ef:eb"
	}
	"56:4b:5d:3c:ef:eb" -> "ea:98:f6:2a:94:9e" [label="1.000"]
	"56:4b:5d:3c:ef:eb" -> "a2:f7:c1:65:50:ee" [label="1.000"]
	"56:4b:5d:3c:ef:eb" -> "ee:db:3b:5e:a2:ed" [label="TT"]
}

Nur batctl liefert keine…

#61

Vermutlich weil eben vis support komplett rausgepatcht wurde…

selbst wenn es dann manuell installiert auf dem Server ist, nutzt das wenig, wenn batman respektive batctl es nicht mehr nutzen, nutzen können, nutzen wollen, usw :wink:

#62

Das heißt konkret ich kann kein no_rebroadcast nutzen wenn das Gateway auch die Karte generieren soll? :frowning:

#63

Also, die legacy ist auf Gateways ohnehin unsupported. Wozu sollte auch no_rebroadcast auf einem Gateway gut sein?!

#64

m( Ah ne sorry ich meinte nicht no_rebroadcast sondern die ganzen Patches die da anscheinend drin sind, die bei der „original“ Version fehlen…

#65

Hier guck, ich untermauer das noch flott mit einer Aussage, diesmal vom NeoRaider:

<CHRIS> wenn man batman-adv-legacy installiert, muss man dann noch nen  echo 1 > /sys/class/net/tap0/batman_adv/no_rebroadcast machen?
<neoraider> CHRIS, wenn du das Feature aktivieren willst, ja
<CHRIS> also ist nicht default an?
<neoraider> Nein, weil es gefährlich ist
<neoraider> **Auf dem Server, zu dem sich Nodes verbinden, darf es auf keinen Fall aktiviert werden**
<neoraider> Und es darf auch auch den WLAN-Mesh-Interfaces nicht aktiviert werden
<neoraider> Daher ist es per Dafault einfach aus
#66

Hat die DKMS vielleicht auch Patches und noch vis support drin?

Kann ich Dir leider spontan nicht beantworten…

#67

dkms hat auf jeden Fall vis noch drin, bisher lief die Map damit auch immer

#68

Nutzt ihr evtl. Ubuntu und habt mit einem kürzlich releasten Security Update des Kernels das alte batman Kernel Modul 2013.4.0 durch die neue im Kernel integrierte Version 2013.5.0 ersetzt?

#69

Es lag an der Legacy Version, dkms wieder drüber und es läuft.