Arbeitsgruppe Software AdhocBridge - Versionsgeschichte

HaraldG: /* Memoryleak (Lösung gefunden (wirklich?)) */

2008-11-05T22:55:39Z

‎Memoryleak (Lösung gefunden (wirklich?))

HaraldG: Neue Daten von g4, wo man eigentlich kein Leak sieht

2008-10-25T21:36:00Z

Neue Daten von g4, wo man eigentlich kein Leak sieht

Markit: /* Memoryleak (Lösung gefunden (wirklich?)) */

2008-10-21T15:34:26Z

‎Memoryleak (Lösung gefunden (wirklich?))

Markit: /* Eigene Firmware? */

2008-10-21T14:57:54Z

‎Eigene Firmware?

Markit: /* Memoryleak (Lösung gefunden) */

2008-10-21T14:55:55Z

‎Memoryleak (Lösung gefunden)

Markit: /* MAC rewriting */

2008-10-21T14:53:22Z

‎MAC rewriting

HaraldG: Hinweis auf requeues Statistik zum Debuggen

2008-08-27T18:53:52Z

Hinweis auf requeues Statistik zum Debuggen

HaraldG: Memoryleak, und wifi Probleme

2008-08-21T23:05:12Z

Memoryleak, und wifi Probleme

HaraldG: Daten Memoryleak g4

2008-08-19T17:37:26Z

Daten Memoryleak g4

HaraldG: Memoryleak

2008-08-19T03:30:00Z

Memoryleak

← Nächstältere Version		Version vom 5. November 2008, 22:55 Uhr
Zeile 152:		Zeile 152:
	: rate 0bit 0pps backlog 0b 0p requeues 497		: rate 0bit 0pps backlog 0b 0p requeues 497

		+	::Nach 14 Tagen ist die Fonera jetzt doch rebootet. Ursache war leider nicht feststellbar und die Dauer der downtime davor auch nicht (Grenze 0-2 Stunden). --[[Benutzer:HaraldG\|HaraldG]] 23:55, 5. Nov 2008 (CET)

	Folgender Kernel hat das Problem:		Folgender Kernel hat das Problem:

@@ Zeile 49: / Zeile 49: @@
 ===Memoryleak (Lösung gefunden (wirklich?))===
 Es gibt recht offensichtlich ein Memoryleak, dass aber nichts mit der bridge Konfiguration zu tun hat, sondern anscheinend an bestimmten Kernelversionen liegt:
 Folgender Kernel hat das Problem:

@@ Zeile 58: / Zeile 58: @@
   / # uname -a
   Linux OpenWrt 2.6.26.2 #2 Tue Aug 12 19:47:19 CEST 2008 mips unknown
 Update:
-allerdings mit bridge_nf weisen auch 2.6.26er Kernel noch leaks auf
+allerdings mit bridge_nf weisen auch 2.6.26.5er Kernel noch leaks auf, darum läuft nun auf einer testbridge (garten94-heusued) ein automatischer reboot nach 24h oder bei weniger als 1MB freien Speicher, zwar keine elegante Lösung, aber zumindest kann man nun mal den router einfach laufen lassen und abwarten ob wenigsten die wlan probleme (siehe unten) Geschichte sind,..
 Mit folgendem Skript habe ich getestet:

@@ Zeile 36: / Zeile 36: @@
 =Eigene Firmware?=
-Aufgrund des modifizierten kenrels ist es nciht so leicht dies einfach als ipkg zu einer bestehenden openwrt-basierten firmware zu realisieren?
+Aufgrund des modifizierten kernels ist es nicht so leicht dies einfach als ipkg zu einer bestehenden openwrt-basierten firmware zu realisieren?
-Weiss er wie man kmod packages macht (d.h. rausfindet was sich alles an einem kernel durch BRIDGE_NF ändert)
+Weiss wer wie man kmod packages macht (d.h. rausfindet was sich alles an einem kernel durch BRIDGE_NF ändert)
-Die andere variante sich eine eingene komplett zu flaschende firmware zu ersparen ist das ARP-Packet-rewriting nicht mit arptables zu machen sonderm mittels einem selbst gemachten/modifizierten arp-proxies oder ähnlichem zu ersetzen
+Die andere variante sich eine eingene komplett zu flashende firmware zu ersparen ist das ARP-Packet-rewriting nicht mit arptables zu machen sonderm mittels einem selbst gemachten/modifizierten arp-proxies oder ähnlichem zu ersetzen
-andererseits ist eine funktinoerende Adhocbridge ein gerät das man eher einmal und nie wieder flasht,.. weil es dann ohne updates problemlos weiterhin seinen dienst tun wird (denn oslr ist ja keiner drauf (-;)
+andererseits ist eine funktionierende Adhocbridge ein gerät das man eher einmal und nie wieder flasht,.. weil es dann ohne updates problemlos weiterhin seinen dienst tun wird (denn oslr ist ja z.B.: keiner drauf (-;)
 ==Probleme mit der eigenen Firmware==

@@ Zeile 47: / Zeile 47: @@
 Derzeit gibt es das Problem, dass unsere eigene Firware alle paar Tage abstürzt/rebootet oder alle Links verliert. Anscheinend gibt es mindestens zwei Probleme:
-===Memoryleak (Lösung gefunden)===
+===Memoryleak (Lösung gefunden (wirklich?))===
 Es gibt recht offensichtlich ein Memoryleak, dass aber nichts mit der bridge Konfiguration zu tun hat, sondern anscheinend an bestimmten Kernelversionen liegt:
@@ Zeile 58: / Zeile 58: @@
   / # uname -a
   Linux OpenWrt 2.6.26.2 #2 Tue Aug 12 19:47:19 CEST 2008 mips unknown
 Mit folgendem Skript habe ich getestet:
@@ Zeile 101: / Zeile 104: @@
   20000102-00-01  Mem:        13612        11160         2452            0          768
   20000102-01-01  Mem:        13612        12324         1288            0          768
 ===Fehlermeldung: no xmit buf===

@@ Zeile 33: / Zeile 33: @@
 dies bedeutet für 2.4er kernel einen patch, und für 2.6er eine konfig optinoen beim kompilieren
-weiters emfpiehlt es sich nachher BRIDGE_NR nur für arptables aktivert zu lassen und für iptables wieder anzuschalten, da dies sonst merklich (ergibt eine xfach höhere cpu load) performance kostet, wenn alle gebridgten pakete durch iptables/netfilter durch mnüssen, (selbet wenn es gar keine iptable rules gibt)
+weiters emfpiehlt es sich nachher BRIDGE_NF nur für arptables aktivert zu lassen und für iptables wieder abzuschalten, da dies sonst merklich (ergibt eine xfach höhere cpu load) performance kostet, wenn alle gebridgten pakete durch iptables/netfilter durch müssen, (selbet wenn es dort gar keine iptable rules gibt)
 =Eigene Firmware?=

← Nächstältere Version		Version vom 27. August 2008, 18:53 Uhr
Zeile 142:		Zeile 142:

	Anscheinend hat der WATCHDOG das Problem nach über einer halben Stunde downtime wieder behoben...		Anscheinend hat der WATCHDOG das Problem nach über einer halben Stunde downtime wieder behoben...
		+
		+	Im Zusammenhang mit diesem Problem kann auch ein irrsinnig hoher requeues counter beobachtet werden - das kann beim Debuggen nützlich sein

@@ Zeile 45: / Zeile 45: @@
 ==Probleme mit der eigenen Firmware==
-Derzeit gibt es das Problem, dass unsere eigene Firware alle paar Tage abstürzt/rebootet. Ich hab' bei meiner Bridge (auf g4) jetzt ziemlich deutlich ein Memoryleak feststellen können. Hab' daher einmal ein kleines script geschrieben, dass den freien Speicher monitored:
+Derzeit gibt es das Problem, dass unsere eigene Firware alle paar Tage abstürzt/rebootet oder alle Links verliert. Anscheinend gibt es mindestens zwei Probleme:
 /etc/freelog.sh:
@@ Zeile 60: / Zeile 74: @@
 BTW, /tmp/freelog liegt in der RAM disk, ist also nach einem Absturz weg - also regelmäßig wegsichern oder regelmäßig nachschauen.
-Mehr tests mit verschiedener Firmwareversion auf Foneras mit und ohne bridge wären nützlich. - Auffinden des Leaks natürlch noch mehr... :)
+====Daten von g4====
-−
-−
 ===Daten von g4===
   / # uname -a
   Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown
@@ Zeile 91: / Zeile 102: @@
   20000102-01-01  Mem:        13612        12324         1288            0          768
-Der Anfang eines Absturzes (Pakete werden noch empfangen, aber nicht mehr gesendet) in logread:
   Jan  2 01:12:08 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
   Jan  2 01:12:09 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
@@ Zeile 102: / Zeile 116: @@
   Jan  2 01:14:22 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
   Jan  2 01:14:25 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
-Anscheinend verliert madwifi einen wichtien Buffer noch bevor der RAM überhaupt ganz weg ist ...
+Und dies stammt von garten94 von der mit der seriellen Konsole überwachten Fonera (Kernel wieder 2.6.21.5):
-Hab' jedenfalls den Eindruck, dass das Memoryleak im Kernel ist, kann's aber noch nicht beweisen.
+Anscheinend hat der WATCHDOG das Problem nach über einer halben Stunde downtime wieder behoben...

← Nächstältere Version		Version vom 19. August 2008, 17:37 Uhr
Zeile 61:		Zeile 61:

	Mehr tests mit verschiedener Firmwareversion auf Foneras mit und ohne bridge wären nützlich. - Auffinden des Leaks natürlch noch mehr... :)		Mehr tests mit verschiedener Firmwareversion auf Foneras mit und ohne bridge wären nützlich. - Auffinden des Leaks natürlch noch mehr... :)
		+
		+
		+	===Daten von g4===
		+	/ # uname -a
		+	Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown
		+
		+	Kurz nach dem reboot der bridge sagt free:
		+	total used free shared buffers
		+	Mem: 13612 8332 5280 0 768
		+	Swap: 0 0 0
		+	Total: 13612 8332 5280
		+
		+	/tmp/freelog bis kurz vorm Absturz:
		+	20000101-10-12 Mem: 13612 10028 3584 0 768
		+	20000101-11-01 Mem: 13612 10160 3452 0 768
		+	20000101-12-01 Mem: 13612 10196 3416 0 768
		+	20000101-13-01 Mem: 13612 10020 3592 0 768
		+	20000101-14-01 Mem: 13612 10024 3588 0 768
		+	20000101-15-01 Mem: 13612 10156 3456 0 768
		+	20000101-16-01 Mem: 13612 10184 3428 0 768
		+	20000101-17-01 Mem: 13612 10220 3392 0 768
		+	20000101-18-01 Mem: 13612 10268 3344 0 768
		+	20000101-19-01 Mem: 13612 10388 3224 0 768
		+	20000101-20-01 Mem: 13612 10508 3104 0 768
		+	20000101-21-01 Mem: 13612 10588 3024 0 768
		+	20000101-22-01 Mem: 13612 10624 2988 0 768
		+	20000101-23-01 Mem: 13612 10832 2780 0 768
		+	20000102-00-01 Mem: 13612 11160 2452 0 768
		+	20000102-01-01 Mem: 13612 12324 1288 0 768
		+
		+	Der Anfang eines Absturzes (Pakete werden noch empfangen, aber nicht mehr gesendet) in logread:
		+	Jan 2 01:12:08 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	Jan 2 01:12:09 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	Jan 2 01:12:20 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	Jan 2 01:12:24 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	Jan 2 01:12:28 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	Jan 2 01:12:40 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	Jan 2 01:13:43 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	Jan 2 01:13:55 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	Jan 2 01:14:22 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	Jan 2 01:14:25 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
		+	/ # free
		+	total used free shared buffers
		+	Mem: 13612 12232 1380 0 768
		+	Swap: 0 0 0
		+	Total: 13612 12232 1380
		+
		+	Anscheinend verliert madwifi einen wichtien Buffer noch bevor der RAM überhaupt ganz weg ist ...
		+
		+	Hab' jedenfalls den Eindruck, dass das Memoryleak im Kernel ist, kann's aber noch nicht beweisen.

← Nächstältere Version		Version vom 19. August 2008, 03:30 Uhr
Zeile 43:		Zeile 43:

	andererseits ist eine funktinoerende Adhocbridge ein gerät das man eher einmal und nie wieder flasht,.. weil es dann ohne updates problemlos weiterhin seinen dienst tun wird (denn oslr ist ja keiner drauf (-;)		andererseits ist eine funktinoerende Adhocbridge ein gerät das man eher einmal und nie wieder flasht,.. weil es dann ohne updates problemlos weiterhin seinen dienst tun wird (denn oslr ist ja keiner drauf (-;)
		+
		+	==Probleme mit der eigenen Firmware==
		+	Derzeit gibt es das Problem, dass unsere eigene Firware alle paar Tage abstürzt/rebootet. Ich hab' bei meiner Bridge (auf g4) jetzt ziemlich deutlich ein Memoryleak feststellen können. Hab' daher einmal ein kleines script geschrieben, dass den freien Speicher monitored:
		+
		+	/etc/freelog.sh:
		+	#!/bin/sh
		+
		+	echo -n $(date '+%Y%m%d-%H-%M') >>/tmp/freelog
		+	free \| grep Mem: >>/tmp/freelog
		+
		+	/etc/crontabs/root:
		+	01 * * * * /etc/freelog.sh
		+
		+	Das ist natürlich nur eine sehr grobe Messmethode und cron hat auch selber einiges an RAM-Verbrauch, aber nach einiger Zeit sieht man trotzdem ob eine Firware betroffen ist oder nicht, ohne einen Absturz abwarten zu müssen...
		+
		+	BTW, /tmp/freelog liegt in der RAM disk, ist also nach einem Absturz weg - also regelmäßig wegsichern oder regelmäßig nachschauen.
		+
		+	Mehr tests mit verschiedener Firmwareversion auf Foneras mit und ohne bridge wären nützlich. - Auffinden des Leaks natürlch noch mehr... :)