[Freifunk Franken Firmware 0000039]: l2tp Traffic overflow
Mantis Bug Tracker
mbt at chrisi01.de
Di Jun 13 13:21:40 CEST 2017
Der folgende Eintrag wurde geschlossen.
======================================================================
https://mantis.freifunk-franken.de/view.php?id=39
======================================================================
Berichtet von: ChristianD
Zugewiesen an:
======================================================================
Projekt: Freifunk Franken Firmware
Eintrag-ID: 39
Kategorie: Freifunk Franken Firmware
Reproduzierbarkeit: nicht getestet
Auswirkung: kleinerer Fehler
Priorität: normal
Status: geschlossen
Lösung: erledigt
Behoben in Version:
======================================================================
Erstellt am: 2017-03-12 15:57 CET
Zuletzt geändert: 2017-06-04 08:37 CEST
======================================================================
Zusammenfassung: l2tp Traffic overflow
Beschreibung:
https://github.com/FreifunkFranken/firmware/commit/fce5b0ceefa9fdddd3f1b690416659785df4e2fc#diff-055d355e728cddb080887618826715a5
Der Bug scheint im LEDE wieder aufzutreten. Vermutlich brauchen wir das Patch
auch im LEDE
======================================================================
----------------------------------------------------------------------
(0000083) ChristianD (Administrator) - 2017-05-26 14:15
https://mantis.freifunk-franken.de/view.php?id=39#c83
----------------------------------------------------------------------
Ich habe versucht den alten Patch
https://github.com/FreifunkFranken/firmware/commit/fce5b0ceefa9fdddd3f1b690416659785df4e2fc#diff-055d355e728cddb080887618826715a5
auf das Verzeichnis
target/linux/ar71xx/patches-4.4/fix-l2tp-stats-couter-on-32-Bit-Systems.patch
umzubiegen damit es für den aktuellen Kernel gebaut wird. Leider bootet dann
der Router nicht mehr, ich gehe mal davon aus, dass das Patch nicht mit dem
4.4er Kernel funktioniert.
Aufgrund mangelnder C-Kenntnisse komm ich da auch nicht weiter.
----------------------------------------------------------------------
(0000084) ChristianD (Administrator) - 2017-05-26 14:24
https://mantis.freifunk-franken.de/view.php?id=39#c84
----------------------------------------------------------------------
B Zeile 109 bis 130. Zumindest das Patch scheint richtig drinnen zu sein. Warum
der Router nicht bootet keine Ahnung.
----------------------------------------------------------------------
(0000085) Adrian Schmutzler (Reporter) - 2017-05-26 15:06
https://mantis.freifunk-franken.de/view.php?id=39#c85
----------------------------------------------------------------------
Hab mir das mal im Code angesehen; was ich nicht verstehe: Die Funktion
atomic_long_read gibt immer long zurück. Die Member im struct rtnl_link_stats64
haben aber immer Typ __u64. Es müsste also eigtl. doch auch _immer_ eine
Conversion von long nach __u64 (ist ja unsigned) stattfinden, oder?
----------------------------------------------------------------------
(0000086) Adrian Schmutzler (Reporter) - 2017-05-26 16:28
https://mantis.freifunk-franken.de/view.php?id=39#c86
----------------------------------------------------------------------
Und während u64 immer die gleiche Größe hat, müsste "unsigned long" ja
compilerspezifisch sein, also unterschiedliche Größen haben können. Das
heißt, gerade wenn z.B. BITS_PER_LONG=32 würde ja dann ggf. eine 32-bit lange
unsigned long in eine 64-bit lange __u64 variable gespeichert?! Aber
wahrscheinlich müsste man dazu mit dem Ersteller des Patches sprechen, vll.
versteh ich da ja auch was falsch.
----------------------------------------------------------------------
(0000087) Adrian Schmutzler (Reporter) - 2017-05-26 17:02
https://mantis.freifunk-franken.de/view.php?id=39#c87
----------------------------------------------------------------------
Was mir gerade auch noch aufgefallen ist: In der Funktion atomic_long_read kann
es unter bestimmten Umständen zu einer Conversion long long nach long kommen,
was auch einen Integer Overflow an der selben Stelle auslösen könnte.
----------------------------------------------------------------------
(0000088) Adrian Schmutzler (Reporter) - 2017-05-27 18:15
https://mantis.freifunk-franken.de/view.php?id=39#c88
----------------------------------------------------------------------
Bei welcher Firmware-Version tritt der Overflow denn definitiv nicht auf? Kann
ich mir einfach den letzten Commit der 20170110 ziehen, bauen und dann die
entsprechenden Stellen mit der LEDE-Variante vergleichen?
----------------------------------------------------------------------
(0000089) ChristianD (Administrator) - 2017-05-27 19:19
https://mantis.freifunk-franken.de/view.php?id=39#c89
----------------------------------------------------------------------
Alles vor LEDE da war bereits ein Patch mit drinnen.
https://github.com/FreifunkFranken/firmware/commit/fce5b0ceefa9fdddd3f1b690416659785df4e2fc#diff-055d355e728cddb080887618826715a5
Das Patch wurde beim Update auf LEDE rausgenommen, ich hab es dann wieder in
LEDE mit eingebaut aber seitdem bootet der Router nicht mehr, warum? Keine
Ahnung
mfg
Christian
----------------------------------------------------------------------
(0000090) Adrian Schmutzler (Reporter) - 2017-05-28 19:54
https://mantis.freifunk-franken.de/view.php?id=39#c90
----------------------------------------------------------------------
Okay, short version:
Bei mir läuft es mit dem alten patch, wenn man nur das Patch-Verzeichnis
ändert (3.3.irgendwas nach 4.4, siehe Anhang).
Long version:
1. Ich hab die Firmware mit dem Stand benutzt, die ich für den v12 committed
habe (also etwas neuer als die alpha, aber LEDE stable branch). Verwendet zum
Testen habe ich einen WR841N v10.
2. Ich hab zur Referenz auch einmal den Overflow mit der standard-alpha
reproduziert. Dabei hatte ich beim Upgraden nen Bootloop und musste mit TFTP
recovern. Danach lief es wieder, aber vll. ist das dasselbe, was ChristianD
passiert ist. (=es war "Zufall")
3. Der Code ist so geschrieben, dass auf 32-bit Geräten auch nur eine 32-bit
int als Zwischenvariable verwendet wird. D.h. der Traffic kann keine Werte
höher als 4 GB (unsigned int) annehmen, danach läuft er wieder von Null.
4. Ich habe den Code von 20170110 und der alpha näher angesehen, die Routinen
sind hier effektiv gleich, sodass der Patch auch den gleichen Effekt haben
sollte.
5. Vor dem Test hab ich jeweils fastd über SSH deaktiviert und dann per
Download genügend Traffic produziert (mir ist keine einfachere Methode
eingefallen)
... Mehr fällt mir grade nicht ein
----------------------------------------------------------------------
(0000091) ChristianD (Administrator) - 2017-05-28 21:06
https://mantis.freifunk-franken.de/view.php?id=39#c91
----------------------------------------------------------------------
ich hab es auf einen wdr3600 geflasht. Leider keine UART dran zum gucken was
passiert. Aber er bootet ein paar Sekunden, dann leuchten alle LEDs auf, dann
wieder nur Power und nach etwa. 10-15Sekunden wieder alle LEDs dann nur Power
usw... in einer Endlosschleife. Sieht mir nach ner bootloop aus.
Ich hab bei mir auch nur das Kernelverzeichnis geändert (wie du sagtest von
3.xirgendwas auf 4.4irgendwas) damit das Problem entstand
tftp&kram hab ich noch nicht probiert.
----------------------------------------------------------------------
(0000092) Adrian Schmutzler (Reporter) - 2017-05-28 21:11
https://mantis.freifunk-franken.de/view.php?id=39#c92
----------------------------------------------------------------------
Genau das Verhalten hatte ich auch, als ich nur die offizielle alpha geflasht
habe (was aber vorher schon mal funktioniert hat). Danach ging es auch wieder
(20170110 factory per TFTP, dann Upgrade auf alpha), k.A. was hier der Grund
war. Entsprechend würde ich es an deiner Stelle auf einen zweiten Versuch
ankommen lassen.
----------------------------------------------------------------------
(0000094) Adrian Schmutzler (Reporter) - 2017-05-29 15:21
https://mantis.freifunk-franken.de/view.php?id=39#c94
----------------------------------------------------------------------
Hab das ganze jetzt mal als Patch geschickt, der nach meinen drei anderen
applied werden kann. Hab gestern auch noch einen Router (WR841N v11) im
"Produktiv-Einsatz" geflasht (WebUI per Remote), der seitdem auch problemlos
läuft:
https://monitoring.freifunk-franken.de/routers/58d662e49369c34df4bd7081
----------------------------------------------------------------------
(0000100) Adrian Schmutzler (Reporter) - 2017-06-03 00:01
https://mantis.freifunk-franken.de/view.php?id=39#c100
----------------------------------------------------------------------
Status -> fixed.
Eintrags-Historie
Änderungsdatum Benutzername Feld Änderung
======================================================================
2017-03-12 15:57 ChristianD Neuer Eintrag
2017-05-26 14:15 ChristianD Notiz hinzugefügt: 0000083
2017-05-26 14:24 ChristianD Datei hinzugefügt: l2tp_eth.c
2017-05-26 14:24 ChristianD Notiz hinzugefügt: 0000084
2017-05-26 15:06 Adrian SchmutzlerNotiz hinzugefügt: 0000085
2017-05-26 16:28 Adrian SchmutzlerNotiz hinzugefügt: 0000086
2017-05-26 17:02 Adrian SchmutzlerNotiz hinzugefügt: 0000087
2017-05-27 18:15 Adrian SchmutzlerNotiz hinzugefügt: 0000088
2017-05-27 19:18 ChristianD Notiz hinzugefügt: 0000089
2017-05-27 19:19 ChristianD Notiz bearbeitet: 0000089
2017-05-28 19:54 Adrian SchmutzlerDatei hinzugefügt:
0004-ar71xx-3.18-l2tp-stats.patch
2017-05-28 19:54 Adrian SchmutzlerNotiz hinzugefügt: 0000090
2017-05-28 21:05 ChristianD Notiz hinzugefügt: 0000091
2017-05-28 21:06 ChristianD Notiz bearbeitet: 0000091
2017-05-28 21:11 Adrian SchmutzlerNotiz hinzugefügt: 0000092
2017-05-29 15:21 Adrian SchmutzlerNotiz hinzugefügt: 0000094
2017-06-03 00:01 Adrian SchmutzlerNotiz hinzugefügt: 0000100
2017-06-04 08:36 ChristianD Status neu => erledigt
2017-06-04 08:36 ChristianD Lösung offen => erledigt
2017-06-04 08:37 ChristianD Status erledigt => geschlossen
======================================================================
Mehr Informationen über die Mailingliste franken-dev