Projekte/v642/olsrd2-Debug-Party - Versionsgeschichte

Albert: Details für 04.04.2018 ausformuliert

2018-04-05T15:58:44Z

Details für 04.04.2018 ausformuliert

← Nächstältere Version		Version vom 5. April 2018, 15:58 Uhr
Zeile 64:		Zeile 64:
	*** <del>Telnet/HTTP-Plugin auf TCP-Port 8000</del>. Das wird wieder ausgeschlossen, als der Daemon am Metalab-v642-EdgeRouter abstürzt. Hier ist Port 8000 nicht offen.		*** <del>Telnet/HTTP-Plugin auf TCP-Port 8000</del>. Das wird wieder ausgeschlossen, als der Daemon am Metalab-v642-EdgeRouter abstürzt. Hier ist Port 8000 nicht offen.
	* 03.04.2018: Absturz um 05:05. Es wird wieder eine problematische Version in Betrieb gefunden: v0.15.0-9.		* 03.04.2018: Absturz um 05:05. Es wird wieder eine problematische Version in Betrieb gefunden: v0.15.0-9.
	* 04.04.2018: ~~Start eines~~ <code>tcdump</code>s auf einem EdgeRouter.		* 04.04.2018: @Pocki startet zu Mittag ein <code>tcdump</code>s auf einem EdgeRouter. Gegen 20:00 startet @kosh am Tunnelserver <code>ts2018</code> eine <code>olsrd2</code>-v0.15.0-9-Instanz. Jetzt warten wir auf den nächsten Crash ;-)

Albert: Hennings Erklärung zu PacketBB / RFC5444 / olsrd2 / NHDP hinzugefügt

2018-04-05T12:54:19Z

Hennings Erklärung zu PacketBB / RFC5444 / olsrd2 / NHDP hinzugefügt

← Nächstältere Version		Version vom 5. April 2018, 12:54 Uhr
Zeile 1:		Zeile 1:
	== Worum geht es? ==		== Worum geht es? ==

	<code>olsrd2</code>-Versionen bis hinunter zu (mindestens) 0.14.0 stürzen unter zu recherchierenden Bedingungen ab, wenn mindestens eine Instanz mit Version 0.15.x im Netz läuft.		<code>olsrd2</code>-Versionen bis hinunter zu (mindestens) 0.14.0 stürzen unter zu recherchierenden Bedingungen mit einem <code>segfault</code> ab, wenn mindestens eine Instanz mit Version 0.15.x im Netz läuft.

	v0.14 und v0.15 dürften beide einen Bug haben, den aber nur v0.15 "aktiv erzeugen" kann, um dann selbst abzustürzen und v0.14 mitzureißen.		v0.14 und v0.15 dürften beide einen Bug haben, den aber nur v0.15 "aktiv erzeugen" kann, um dann selbst abzustürzen und v0.14 mitzureißen.
Zeile 11:		Zeile 11:
	== Debugmethode ==		== Debugmethode ==

	Es bieten sich verschiedene Möglichkeiten an, um diesen Problemen auf den Grund zu gehen. Wir untersuchen zunächst einmal den Netzwerkverkehr; parallel dazu hat @dabeani ein <code>olsrd2</code>-Executable mit Debugsymbolen gebaut, dessen Dumps untersucht werden können.		Es bieten sich verschiedene Möglichkeiten an, um diesen Problemen auf den Grund zu gehen. Wir untersuchen zunächst einmal den Netzwerkverkehr; parallel dazu hat @dabeani ein <code>olsrd2</code>-Executable mit Debugsymbolen gebaut, das lokal ausgerollt und dessen Dumps untersucht werden können.


Zeile 40:		Zeile 40:
	Zwar hat <code>tcpdump</code> sogenannte ''"Printer"'' für viele Protokolle (siehe die <code>print-*</code>-Module in [https://github.com/the-tcpdump-group/tcpdump den Sourcen]), d.h. es kann Paketinhalte in menschenlesbarer Form ausgeben. Allerdings zählt <code>olsrd2</code>-Verkehr nicht dazu.		Zwar hat <code>tcpdump</code> sogenannte ''"Printer"'' für viele Protokolle (siehe die <code>print-*</code>-Module in [https://github.com/the-tcpdump-group/tcpdump den Sourcen]), d.h. es kann Paketinhalte in menschenlesbarer Form ausgeben. Allerdings zählt <code>olsrd2</code>-Verkehr nicht dazu.

	[https://www.wireshark.org/#download Wireshark] hingegen hat einen passenden ''Dissector'' (siehe [https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-packetbb.c;hb=HEAD Source]). Beachte, dass Wireshark <code>olsrd2</code>-Verkehr als '''PacketBB'''-Protokoll klassifiziert. Die Auswertung der Nachrichteninhalte von <code>olsrd2</code> und <code>NHDP</code> funktioniert aber ~~mit~~ wenigen nicht implementierten Ausnahmen ~~korrekt~~.		[https://www.wireshark.org/#download Wireshark] hingegen hat einen passenden ''Dissector'' (siehe [https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-packetbb.c;hb=HEAD Source]). Beachte, dass Wireshark <code>olsrd2</code>-Verkehr als ''"PacketBB"''-Protokoll klassifiziert. Die Auswertung der Nachrichteninhalte von <code>olsrd2</code> und <code>NHDP</code> funktioniert aber korrekt, von wenigen nicht implementierten Ausnahmen abgesehen.

			Henning, der den Dissector ursprünglich geschrieben hat, erklärt dazu:

			<blockquote>''PacketBB'' ist die alte Bezeichnung für [https://tools.ietf.org/html/rfc5444 RFC5444], das ''Generalized Mobile Ad Hoc Network Packet/Message Format'', das von <code>olsrd2</code> und <code>NHDP</code> verwendet wird.</blockquote>



	== Zeitleiste ==		== Zeitleiste ==

Albert: /* Wie wird Netzwerkverkehr aufgezeichnet? */ Abschnitt umbenannt und neu strukturiert, um auf Wireshark und PacketBB-dekodiert-olsrd2 hinzuweisen

2018-04-05T12:41:16Z

Wie wird Netzwerkverkehr aufgezeichnet?: Abschnitt umbenannt und neu strukturiert, um auf Wireshark und PacketBB-dekodiert-olsrd2 hinzuweisen

← Nächstältere Version		Version vom 5. April 2018, 12:41 Uhr
Zeile 9:		Zeile 9:


	== ~~Wie wird Netzwerkverkehr aufgezeichnet?~~ ==		== Debugmethode ==

	<code>tcpdump</code> [https://www.tcpdump.org/] ist das Mittel der Wahl. @Pocki macht konkret		Es bieten sich verschiedene Möglichkeiten an, um diesen Problemen auf den Grund zu gehen. Wir untersuchen zunächst einmal den Netzwerkverkehr; parallel dazu hat @dabeani ein <code>olsrd2</code>-Executable mit Debugsymbolen gebaut, dessen Dumps untersucht werden können.


			=== Netzwerkverkehr analysieren ===

			Hierzu braucht es zwei Schritte: Zuerst wird der Verkehr aufgezeichnet, dann untersucht.

			==== Aufzeichnung ====

			<code>tcpdump</code> [https://www.tcpdump.org/] ist das Mittel der Wahl.. @Pocki macht auf einem seiner EdgeRouter konkret

	nohup tcpdump -C 1 -W 10 -w /tmp/olsr2dump -i br0 "udp port 269" &>/dev/null &		nohup tcpdump -C 1 -W 10 -w /tmp/olsr2dump -i br0 "udp port 269" &>/dev/null &
Zeile 24:		Zeile 33:
	# & um den Prozess in den Hintergund zu schicken		# & um den Prozess in den Hintergund zu schicken

			Die Dumps stellt er hier im Web bereit: http://78.41.113.166:8000/www/dumps.html


			==== Analyse ====

			Zwar hat <code>tcpdump</code> sogenannte ''"Printer"'' für viele Protokolle (siehe die <code>print-*</code>-Module in [https://github.com/the-tcpdump-group/tcpdump den Sourcen]), d.h. es kann Paketinhalte in menschenlesbarer Form ausgeben. Allerdings zählt <code>olsrd2</code>-Verkehr nicht dazu.

			[https://www.wireshark.org/#download Wireshark] hingegen hat einen passenden ''Dissector'' (siehe [https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-packetbb.c;hb=HEAD Source]). Beachte, dass Wireshark <code>olsrd2</code>-Verkehr als '''PacketBB'''-Protokoll klassifiziert. Die Auswertung der Nachrichteninhalte von <code>olsrd2</code> und <code>NHDP</code> funktioniert aber mit wenigen nicht implementierten Ausnahmen korrekt.

	== Zeitleiste ==		== Zeitleiste ==

Albert: Die Seite wurde neu angelegt: „== Worum geht es? == `olsrd2`-Versionen bis hinunter zu (mindestens) 0.14.0 stürzen unter zu recherchierenden Bedingungen ab, wenn mindestens eine…“

2018-04-04T09:56:19Z

Die Seite wurde neu angelegt: „== Worum geht es? == <code>olsrd2</code>-Versionen bis hinunter zu (mindestens) 0.14.0 stürzen unter zu recherchierenden Bedingungen ab, wenn mindestens eine…“

Neue Seite

== Worum geht es? ==

<code>olsrd2</code>-Versionen bis hinunter zu (mindestens) 0.14.0 stürzen unter zu recherchierenden Bedingungen ab, wenn mindestens eine Instanz mit Version 0.15.x im Netz läuft.

v0.14 und v0.15 dürften beide einen Bug haben, den aber nur v0.15 "aktiv erzeugen" kann, um dann selbst abzustürzen und v0.14 mitzureißen.

Um das Problem einzugrenzen, zeichnet @Pocki aktuell auf einem seiner EdgeRouter den <code>olsrd2</code>-Verkehr mit <code>tcpdump</code> auf.

== Wie wird Netzwerkverkehr aufgezeichnet? ==

<code>tcpdump</code> [https://www.tcpdump.org/] ist das Mittel der Wahl. @Pocki macht konkret

nohup tcpdump -C 1 -W 10 -w /tmp/olsr2dump -i br0 "udp port 269" &>/dev/null &

# nohup damit tcpdump nach dem Ausloggen weiterläuft
# -C 1 um die Dateigröße auf 1 MB zu begrenzen
# -W 10 um höchstens 10 solcher Dateien aufzuheben ("Log Rotation")
# -w DATEINAME um den Verkehr in eine Datei zu schreiben
# -i SCHNITTSTELLE für das Netzwerkinterface, das verwendet werden soll
# "udp port 269" als Paketfilter, hier für OLSRd2
# &>/dev/null um Ausgaben auf stdout und stderr zu unterdrücken
# & um den Prozess in den Hintergund zu schicken

== Zeitleiste ==

Details siehe den v642-Matrix-Chat!

* vor 23.02.2018: <code>olsrd2</code>-Version 0.14.0-16 läuft im Netz.
* 23.02.2018: Version 0.15.0 wird ausgerollt.
* 28.02.2018: Alle Instanzen stürzen ab, inklusive der des Tunnelservers.
** Das ist nicht der erste Absturz von v2, aber der erste netzweite.
* 03.03.2018: Weiterer netzweiter Absturz.
** "Henning hat gemeint es sei eine TCP Verbindung, die den Logfile-Eintrag verursacht. Der daemon stürzt aber erst etwas später danach ab."
* 04.03.2018: Nächster Absturz.
** Bis dato finde ich in den Logs unserer EdgeRouter 4 Absturzzeitpunkte, die sich BTW auf die Sekunde genau decken: Feb 19 20:17:10, Feb 27 23:05:46, Mar 3 12:06:39, Mar 4 11:40:58."
** Spekulation über mögliche Ursachen:
*** Broadcasts auf UDP-Port 269
*** <del>Telnet/HTTP-Plugin auf TCP-Port 8000</del>. Das wird wieder ausgeschlossen, als der Daemon am Metalab-v642-EdgeRouter abstürzt. Hier ist Port 8000 nicht offen.
* 03.04.2018: Absturz um 05:05. Es wird wieder eine problematische Version in Betrieb gefunden: v0.15.0-9.
* 04.04.2018: Start eines <code>tcdump</code>s auf einem EdgeRouter.

Projekte/v642/olsrd2-Debug-Party - Versionsgeschichte

Albert: Details für 04.04.2018 ausformuliert

Albert: Hennings Erklärung zu PacketBB / RFC5444 / olsrd2 / NHDP hinzugefügt

Albert: /* Wie wird Netzwerkverkehr aufgezeichnet? */ Abschnitt umbenannt und neu strukturiert, um auf Wireshark und PacketBB-dekodiert-olsrd2 hinzuweisen

Albert: Die Seite wurde neu angelegt: „== Worum geht es? == olsrd2-Versionen bis hinunter zu (mindestens) 0.14.0 stürzen unter zu recherchierenden Bedingungen ab, wenn mindestens eine…“

Albert: Die Seite wurde neu angelegt: „== Worum geht es? == `olsrd2`-Versionen bis hinunter zu (mindestens) 0.14.0 stürzen unter zu recherchierenden Bedingungen ab, wenn mindestens eine…“