Firmware: respond-babel Modul refaktorieren

[24367dfa]

https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-mesh-babel/src/respondd.c

[24367dfa]

Die Statusseite zeigt derzeit keine Telemetrie an - das deutet auf einen respondd Absturz hin.

[penguineer]

Gibt es dazu Bug-Reports im Original-Repo?
(Oder ist das vielleicht der nächste Teil der Aufgabe?)

[penguineer]

Nächster Schritt ist, mit einem Debugging-Tool herauszufinden, warum der respondd abstürzt. (sagt @christf )

[christf]

Man braucht wohl auch noch ein build mit debug informationen.

[penguineer]

Wie hängt denn die oben erwähnte Datei mit https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-respondd/src/respondd.c zusammen?

[penguineer]

Und wo finde ich die referenzierte respondd.h?

Eine Suche über GitHub liefert lediglich Verwendungen und die Datei in einem PR, aber nicht existent in einem der Gluon-Repos.

[penguineer]

Es ist leider wenig dokumentiert, welche Bibliothek von wo mit welcher Version eingebunden wird, aber https://github.com/christf/libbabelhelper/blob/christf_bugsquash/src/babelhelper.c#L187 verwendet z.B. den File Descriptor, ohne zu prüfen, ob das Öffnen erfolgreich war.

Mein Weg dort hin:

• Für oben verlinkte Datei das Makefile anschauen
• GitHub-Suche nach libbabelhelper liefert u.a. einen Verweis auf ein Repo bei @christf
• Der master-Branch dort enthält die Funktion nicht
• Der Branch christf_bugsquash hat die Funktion, ich kann aber nicht entscheiden, ob das der korrekte Branch ist. Eingebunden wird der Commit 9301ea3

[penguineer]

Fazit: Es ist sehr schwer, dieses Problem zu debuggen, weil die Dokumentation nicht hergibt, was überhaupt gebaut wird. Der größte Teil der Arbeit wird sein, diese Informationen zu rekonstruieren und zu dokumentieren.

[penguineer]

@christf Hast Du Antworten zu den Fragen bzw. kannst Du die Links auf die tatsächlich verwendeten Repos (inklusive Branch) posten?

[24367dfa]

git clone [email protected]:christf/gluon.git
git checkout christf_next
git clone [email protected]:FreifunkMD/site-ffmd.git site
cd site
git checkout babel
cd ..
./scripts/container.sh

[penguineer]

@24367dfa Was genau hast Du im Container gemacht?

Ich teste mal mit

make update
GLUON_TARGET="x86-64" make -j12

[penguineer]

Das Image läuft bei mir, bekommt aber keine Verbindung mit irgendetwas.
Die wird Firmware im Config-Modus gestartet und braucht nun ein Netz-Segment 192.168.1.0/24

Meine Config dafür sieht so aus:

<network>
  <name>setup</name>
  <uuid>e6cd6350-f473-44d2-8206-7ebc0ee9c479</uuid>
  <forward mode='nat'/>
  <bridge name='virbr1' stp='on' delay='0'/>
  <mac address='52:54:00:6a:c5:ec'/>
  <domain name='setup'/>
  <ip address='192.168.1.10' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.1.128' end='192.168.1.254'/>
    </dhcp>
  </ip>
</network>

(Achtung, der Knoten hat schon 192.168.1.1, d.h. die Default IP des Hosts muss geändert werden.)

Unter http://192.168.1.1 auf dem host erreiche ich nun das Config-Interface.

[24367dfa]

@24367dfa Was genau hast Du im Container gemacht?

Ich teste mal mit

make update
GLUON_TARGET="x86-64" make -j12

ich denke, genau das hab ich gemacht, eventuell export GLUON_TARGET="x86-64", aber das sollte keinen Unterschied machen.

[24367dfa]

Plan:

• im christf/gluon im christf_next branch das modul im gluon_mesh_babel befindliche respond plugin so umbauen, dass es mit dem aktuellen master von christf/libbabelhelper funktioniert
• Test: firmware x86 bauen, in qemu starten, client connecten, statusseite aufrufen, vom client http://nn/