Arbeitsgruppe Software AdhocBridge: Unterschied zwischen den Versionen

Aus FunkFeuer Wiki
Wechseln zu: Navigation, Suche
(Daten Memoryleak g4)
(→‎Memoryleak (Lösung gefunden (wirklich?)))
 
(7 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 33: Zeile 33:
 
dies bedeutet für 2.4er kernel einen patch, und für 2.6er eine konfig optinoen beim kompilieren
 
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?=
 
=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==
 
==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:
 +
 
 +
===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:
 +
 
 +
:OK, ich muss zugeben, ich weiß nicht mehr genau, wann ich mit welchem Patch getestet hab', folgendes stammt jedenfalls von g4 mit BRIDGE_NETFILTER und mit ebtables und arptables geladen (also voll funktionsfähige Bridge):
 +
 
 +
: root@FoneraBridge:/tmp# uname -a
 +
: Linux FoneraBridge 2.6.26.5 #1 Tue Oct 21 02:14:29 CEST 2008 mips unknown
 +
 
 +
: root@FoneraBridge:/tmp# cat freelog
 +
: 19700101-02-01  Mem:        13740        11428        2312            0  1112
 +
: 19700101-03-01  Mem:        13740        11092        2648            0  1112
 +
: 19700101-04-01  Mem:        13740        11188        2552            0  1112
 +
: 19700101-05-01  Mem:        13740        11380        2360            0  1112
 +
: 19700101-06-01  Mem:        13740        11140        2600            0  1112
 +
: 19700101-07-01  Mem:        13740        11208        2532            0  1112
 +
: 19700101-08-01  Mem:        13740        11244        2496            0  1112
 +
: 19700101-09-01  Mem:        13740        11200        2540            0  1112
 +
: 19700101-10-01  Mem:        13740        11252        2488            0  1112
 +
: 19700101-11-01  Mem:        13740        11256        2484            0  1112
 +
: 19700101-12-01  Mem:        13740        11352        2388            0  1112
 +
: 19700101-13-01  Mem:        13740        11376        2364            0  1112
 +
: 19700101-14-01  Mem:        13740        11448        2292            0  1112
 +
: 19700101-15-01  Mem:        13740        11568        2172            0  1112
 +
: 19700101-16-01  Mem:        13740        11548        2192            0  1112
 +
: 19700101-17-01  Mem:        13740        11836        1904            0  1112
 +
: 19700101-18-01  Mem:        13740        11520        2220            0  1112
 +
: 19700101-19-01  Mem:        13740        11596        2144            0  1112
 +
: 19700101-20-01  Mem:        13740        11692        2048            0  1112
 +
: 19700101-21-01  Mem:        13740        11932        1808            0  1112
 +
: 19700101-22-01  Mem:        13740        11952        1788            0  1112
 +
: 19700101-23-01  Mem:        13740        12032        1708            0  1112
 +
: 19700102-00-01  Mem:        13740        12032        1708            0  1112
 +
: 19700102-01-01  Mem:        13740        11880        1860            0  1112
 +
: 19700102-02-01  Mem:        13740        11904        1836            0  1112
 +
: 19700102-03-01  Mem:        13740        11872        1868            0  1112
 +
: 19700102-04-01  Mem:        13740        11868        1872            0  1112
 +
: 19700102-05-01  Mem:        13740        11952        1788            0  1112
 +
: 19700102-06-01  Mem:        13740        12144        1596            0  1112
 +
: 19700102-07-01  Mem:        13740        11932        1808            0  1112
 +
: 19700102-08-01  Mem:        13740        11960        1780            0  1112
 +
: 19700102-09-01  Mem:        13740        11956        1784            0  1112
 +
: 19700102-10-01  Mem:        13740        11948        1792            0  1112
 +
: 19700102-11-01  Mem:        13740        11936        1804            0  1112
 +
: 19700102-12-01  Mem:        13740        11964        1776            0  1112
 +
: 19700102-13-01  Mem:        13740        12008        1732            0  1112
 +
: 19700102-14-01  Mem:        13740        12080        1660            0  1112
 +
: 19700102-15-01  Mem:        13740        11996        1744            0  1112
 +
: 19700102-16-01  Mem:        13740        12272        1468            0  1112
 +
: 19700102-17-01  Mem:        13740        12272        1468            0  1112
 +
: 19700102-18-01  Mem:        13740        12272        1468            0  1112
 +
: 19700102-19-01  Mem:        13740        12028        1712            0  1112
 +
: 19700102-20-01  Mem:        13740        11968        1772            0  1112
 +
: 19700102-21-01  Mem:        13740        11968        1772            0  1112
 +
: 19700102-22-01  Mem:        13740        12000        1740            0  1112
 +
: 19700102-23-01  Mem:        13740        12032        1708            0  1112
 +
: 19700103-00-01  Mem:        13740        12032        1708            0  1112
 +
: 19700103-01-01  Mem:        13740        12032        1708            0  1112
 +
: 19700103-02-01  Mem:        13740        12116        1624            0  1112
 +
: 19700103-03-01  Mem:        13740        12064        1676            0  1112
 +
: 19700103-04-01  Mem:        13740        12124        1616            0  1112
 +
: 19700103-05-01  Mem:        13740        12140        1600            0  1112
 +
: 19700103-06-01  Mem:        13740        12152        1588            0  1112
 +
: 19700103-07-01  Mem:        13740        12164        1576            0  1112
 +
: 19700103-08-01  Mem:        13740        12160        1580            0  1112
 +
: 19700103-09-01  Mem:        13740        12192        1548            0  1112
 +
: 19700103-10-01  Mem:        13740        12192        1548            0  1112
 +
: 19700103-11-01  Mem:        13740        12192        1548            0  1112
 +
: 19700103-12-01  Mem:        13740        12236        1504            0  1112
 +
: 19700103-13-01  Mem:        13740        12232        1508            0  1112
 +
: 19700103-14-01  Mem:        13740        12244        1496            0  1112
 +
: 19700103-15-01  Mem:        13740        12220        1520            0  1112
 +
: 19700103-16-01  Mem:        13740        12284        1456            0  1112
 +
: 19700103-17-01  Mem:        13740        12220        1520            0  1112
 +
: 19700103-18-01  Mem:        13740        12256        1484            0  1112
 +
: 19700103-19-01  Mem:        13740        12256        1484            0  1112
 +
: 19700103-20-01  Mem:        13740        12276        1464            0  1112
 +
: 19700103-21-01  Mem:        13740        12332        1408            0  1112
 +
: 19700103-22-01  Mem:        13740        12336        1404            0  1112
 +
: 19700103-23-01  Mem:        13740        12336        1404            0  1112
 +
: 19700104-00-01  Mem:        13740        12292        1448            0  1112
 +
: 19700104-01-01  Mem:        13740        12264        1476            0  1112
 +
: 19700104-02-01  Mem:        13740        12264        1476            0  1112
 +
: 19700104-03-01  Mem:        13740        12344        1396            0  1112
 +
 
 +
:Also wirklich klar erkennbar ist ein Leak da nicht mehr. - Mit dem früheren Kernel hätte der Router nie 3 Tage uptime erreicht, weil er schon nach etwas mehr als einem Tag out of RAM rebooted hätte.
 +
 
 +
:Ein bissi was zu tun gehabt hat er auch in der Zeit:
 +
 
 +
: root@FoneraBridge:/tmp# tc -s qdisc
 +
: qdisc pfifo_fast 0: dev eth0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 +
:  Sent 8380773865 bytes 8282658 pkt (dropped 0, overlimits 0 requeues 0)
 +
:  rate 0bit 0pps backlog 0b 0p requeues 0
 +
: qdisc prio 11: dev wifi0 root bands 3 priomap  2 2 2 2 2 2 1 1 2 2 2 2 2 2 2 2
 +
:  Sent 2176364281 bytes 2584495 pkt (dropped 0, overlimits 0 requeues 534)
 +
:  rate 0bit 0pps backlog 0b 0p requeues 534
 +
: qdisc pfifo 10: dev wifi0 parent 11:1 limit 195p
 +
:  Sent 495379536 bytes 456544 pkt (dropped 0, overlimits 0 requeues 34)
 +
:  rate 0bit 0pps backlog 0b 0p requeues 34
 +
: qdisc pfifo 20: dev wifi0 parent 11:2 limit 195p
 +
:  Sent 52648133 bytes 88524 pkt (dropped 0, overlimits 0 requeues 3)
 +
:  rate 0bit 0pps backlog 0b 0p requeues 3
 +
: qdisc pfifo 30: dev wifi0 parent 11:3 limit 195p
 +
:  Sent 1628336612 bytes 2039427 pkt (dropped 0, overlimits 0 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:
 +
/ # uname -a
 +
Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown
 +
 
 +
während bei diesem Kernel noch kein Leak nachweisbar war (ca.
 +
12 Stunden laufzeit):
 +
/ # uname -a
 +
Linux OpenWrt 2.6.26.2 #2 Tue Aug 12 19:47:19 CEST 2008 mips unknown
 +
 
 +
(allerdings lief dieser kenel ohne bridge_nf ??)
 +
 
 +
Update:
 +
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:
  
 
/etc/freelog.sh:
 
/etc/freelog.sh:
Zeile 60: Zeile 183:
 
BTW, /tmp/freelog liegt in der RAM disk, ist also nach einem Absturz weg - also regelmäßig wegsichern oder regelmäßig nachschauen.
 
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
 
  / # uname -a
 
  Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown
 
  Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown
Zeile 91: Zeile 211:
 
  20000102-01-01  Mem:        13612        12324        1288            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:
+
===Fehlermeldung: no xmit buf===
 +
Dieses Problem scheint unabhängig vom (noch) vorhanden Arbeitsspeicher aufzutreten. Folgendes findet sich in logread, wenn die bridge aufhört, traffic am wifi Interface zu senen. Von g4 mit kernel 2.6.21.5:
 +
 
 
  Jan  2 01:12:08 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 
  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:09 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Zeile 102: Zeile 224:
 
  Jan  2 01:14:22 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
 
  Jan  2 01:14:25 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
−
  / # free
+
 
−
               total        used        free      shared     buffers
+
Und dies stammt von garten94 von der mit der seriellen Konsole überwachten Fonera (Kernel wieder 2.6.21.5):
−
   Mem:        13612       12232         1380           0          768
+
Jan  1 15:53:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 15:54:06 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 15:54:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 15:54:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 15:55:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
.
 +
.
 +
.
 +
Jan  1 16:29:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 16:29:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 16:29:45 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 16:29:54 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 16:30:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 16:30:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
 +
Jan  1 16:30:07 OpenWrt user.info kernel: NETDEV WATCHDOG: wifi0: transmit timed out
 +
  / # date
 +
Sat Jan  1 16:33:36 UTC 2000
 +
root@OpenWrt:/# free
 +
               total        used        free      shared     buffers
 +
   Mem:        13612        9012        4600           0          768
 
   Swap:            0            0            0
 
   Swap:            0            0            0
−
  Total:        13612       12232         1380
+
  Total:        13612        9012        4600
  
−
Anscheinend verliert madwifi einen wichtien Buffer noch bevor der RAM überhaupt ganz weg ist ...
+
Anscheinend hat der WATCHDOG das Problem nach über einer halben Stunde downtime wieder behoben...
  
−
Hab' jedenfalls den Eindruck, dass das Memoryleak im Kernel ist, kann's aber noch nicht beweisen.
+
Im Zusammenhang mit diesem Problem kann auch ein irrsinnig hoher requeues counter beobachtet werden - das kann beim Debuggen nützlich sein

Aktuelle Version vom 5. November 2008, 23:55 Uhr

Achtung dies ist ein WoW (Maintainer: Markus Kitttenberger)

Ansich kann man doch alles bridgen,..

Adhoc Netze zu bridgen endet aber meist enttäuschend,..

es geht gar nicht, bzw. furchtbar schlecht/langsam,..

Warum ist das so?

Im Adhoc modus werden keine ACKs für gebridge pakete versendet (da sie ja nicht die macadresse des in der bridge befindleichen wireless interfaces haben) die folgen sind geringer durchsatz, oder schlimmeres

Kann man das umgehen?

Ja, entweder man schreibt einen nicht adhoc-standardkonformen wlan treiber,..

Oder man versendet nur Pakete mit der richtigen MAC Adresse,..

Will man ein drahtlos Adhoc-netz mit einem einzigen drahtgebundenen gegenüber bridgen, lässt sich das problemlos erreichen,.. Und mit dieser eingeschränkten bridge kann man schon problemlos einen wlan-router an einen zwieten anstekcne, der dann defakto ein zweiteres wireless interface hat,.. prädestiniert dafür sind Router mit nur einem Ethernet port (wie z.B. Foneras)

MAC rewriting

um das problem mit den WLAN-Acks zu lösen reicht es auf der bridge alle pakete vom zu bridgenden ethernet device die MAc adresse des wlan interfaces zu geben, und vice versa,..

die kann man mit ebtables komfortbael tun

allerdings streiken dann die arp-lookups, da bei diesen die mac adressen sowohl im ehternet header als auch im paket vorliegen,..

mit arptables kann man dies ebenso leicht mit 2 Zeilen erledigen

damit arptables allerdings mit bridges funktinoert braucht man einem kernel mit BRIDGE_NF

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_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?

Aufgrund des modifizierten kernels ist es nicht so leicht dies einfach als ipkg zu einer bestehenden openwrt-basierten firmware zu realisieren?

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 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 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

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 (wirklich?))

Es gibt recht offensichtlich ein Memoryleak, dass aber nichts mit der bridge Konfiguration zu tun hat, sondern anscheinend an bestimmten Kernelversionen liegt:

OK, ich muss zugeben, ich weiß nicht mehr genau, wann ich mit welchem Patch getestet hab', folgendes stammt jedenfalls von g4 mit BRIDGE_NETFILTER und mit ebtables und arptables geladen (also voll funktionsfähige Bridge):
root@FoneraBridge:/tmp# uname -a
Linux FoneraBridge 2.6.26.5 #1 Tue Oct 21 02:14:29 CEST 2008 mips unknown
root@FoneraBridge:/tmp# cat freelog
19700101-02-01 Mem: 13740 11428 2312 0 1112
19700101-03-01 Mem: 13740 11092 2648 0 1112
19700101-04-01 Mem: 13740 11188 2552 0 1112
19700101-05-01 Mem: 13740 11380 2360 0 1112
19700101-06-01 Mem: 13740 11140 2600 0 1112
19700101-07-01 Mem: 13740 11208 2532 0 1112
19700101-08-01 Mem: 13740 11244 2496 0 1112
19700101-09-01 Mem: 13740 11200 2540 0 1112
19700101-10-01 Mem: 13740 11252 2488 0 1112
19700101-11-01 Mem: 13740 11256 2484 0 1112
19700101-12-01 Mem: 13740 11352 2388 0 1112
19700101-13-01 Mem: 13740 11376 2364 0 1112
19700101-14-01 Mem: 13740 11448 2292 0 1112
19700101-15-01 Mem: 13740 11568 2172 0 1112
19700101-16-01 Mem: 13740 11548 2192 0 1112
19700101-17-01 Mem: 13740 11836 1904 0 1112
19700101-18-01 Mem: 13740 11520 2220 0 1112
19700101-19-01 Mem: 13740 11596 2144 0 1112
19700101-20-01 Mem: 13740 11692 2048 0 1112
19700101-21-01 Mem: 13740 11932 1808 0 1112
19700101-22-01 Mem: 13740 11952 1788 0 1112
19700101-23-01 Mem: 13740 12032 1708 0 1112
19700102-00-01 Mem: 13740 12032 1708 0 1112
19700102-01-01 Mem: 13740 11880 1860 0 1112
19700102-02-01 Mem: 13740 11904 1836 0 1112
19700102-03-01 Mem: 13740 11872 1868 0 1112
19700102-04-01 Mem: 13740 11868 1872 0 1112
19700102-05-01 Mem: 13740 11952 1788 0 1112
19700102-06-01 Mem: 13740 12144 1596 0 1112
19700102-07-01 Mem: 13740 11932 1808 0 1112
19700102-08-01 Mem: 13740 11960 1780 0 1112
19700102-09-01 Mem: 13740 11956 1784 0 1112
19700102-10-01 Mem: 13740 11948 1792 0 1112
19700102-11-01 Mem: 13740 11936 1804 0 1112
19700102-12-01 Mem: 13740 11964 1776 0 1112
19700102-13-01 Mem: 13740 12008 1732 0 1112
19700102-14-01 Mem: 13740 12080 1660 0 1112
19700102-15-01 Mem: 13740 11996 1744 0 1112
19700102-16-01 Mem: 13740 12272 1468 0 1112
19700102-17-01 Mem: 13740 12272 1468 0 1112
19700102-18-01 Mem: 13740 12272 1468 0 1112
19700102-19-01 Mem: 13740 12028 1712 0 1112
19700102-20-01 Mem: 13740 11968 1772 0 1112
19700102-21-01 Mem: 13740 11968 1772 0 1112
19700102-22-01 Mem: 13740 12000 1740 0 1112
19700102-23-01 Mem: 13740 12032 1708 0 1112
19700103-00-01 Mem: 13740 12032 1708 0 1112
19700103-01-01 Mem: 13740 12032 1708 0 1112
19700103-02-01 Mem: 13740 12116 1624 0 1112
19700103-03-01 Mem: 13740 12064 1676 0 1112
19700103-04-01 Mem: 13740 12124 1616 0 1112
19700103-05-01 Mem: 13740 12140 1600 0 1112
19700103-06-01 Mem: 13740 12152 1588 0 1112
19700103-07-01 Mem: 13740 12164 1576 0 1112
19700103-08-01 Mem: 13740 12160 1580 0 1112
19700103-09-01 Mem: 13740 12192 1548 0 1112
19700103-10-01 Mem: 13740 12192 1548 0 1112
19700103-11-01 Mem: 13740 12192 1548 0 1112
19700103-12-01 Mem: 13740 12236 1504 0 1112
19700103-13-01 Mem: 13740 12232 1508 0 1112
19700103-14-01 Mem: 13740 12244 1496 0 1112
19700103-15-01 Mem: 13740 12220 1520 0 1112
19700103-16-01 Mem: 13740 12284 1456 0 1112
19700103-17-01 Mem: 13740 12220 1520 0 1112
19700103-18-01 Mem: 13740 12256 1484 0 1112
19700103-19-01 Mem: 13740 12256 1484 0 1112
19700103-20-01 Mem: 13740 12276 1464 0 1112
19700103-21-01 Mem: 13740 12332 1408 0 1112
19700103-22-01 Mem: 13740 12336 1404 0 1112
19700103-23-01 Mem: 13740 12336 1404 0 1112
19700104-00-01 Mem: 13740 12292 1448 0 1112
19700104-01-01 Mem: 13740 12264 1476 0 1112
19700104-02-01 Mem: 13740 12264 1476 0 1112
19700104-03-01 Mem: 13740 12344 1396 0 1112
Also wirklich klar erkennbar ist ein Leak da nicht mehr. - Mit dem früheren Kernel hätte der Router nie 3 Tage uptime erreicht, weil er schon nach etwas mehr als einem Tag out of RAM rebooted hätte.
Ein bissi was zu tun gehabt hat er auch in der Zeit:
root@FoneraBridge:/tmp# tc -s qdisc
qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 8380773865 bytes 8282658 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc prio 11: dev wifi0 root bands 3 priomap 2 2 2 2 2 2 1 1 2 2 2 2 2 2 2 2
Sent 2176364281 bytes 2584495 pkt (dropped 0, overlimits 0 requeues 534)
rate 0bit 0pps backlog 0b 0p requeues 534
qdisc pfifo 10: dev wifi0 parent 11:1 limit 195p
Sent 495379536 bytes 456544 pkt (dropped 0, overlimits 0 requeues 34)
rate 0bit 0pps backlog 0b 0p requeues 34
qdisc pfifo 20: dev wifi0 parent 11:2 limit 195p
Sent 52648133 bytes 88524 pkt (dropped 0, overlimits 0 requeues 3)
rate 0bit 0pps backlog 0b 0p requeues 3
qdisc pfifo 30: dev wifi0 parent 11:3 limit 195p
Sent 1628336612 bytes 2039427 pkt (dropped 0, overlimits 0 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). --HaraldG 23:55, 5. Nov 2008 (CET)

Folgender Kernel hat das Problem: 

/ # uname -a
Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown

während bei diesem Kernel noch kein Leak nachweisbar war (ca. 12 Stunden laufzeit): 

/ # uname -a
Linux OpenWrt 2.6.26.2 #2 Tue Aug 12 19:47:19 CEST 2008 mips unknown

(allerdings lief dieser kenel ohne bridge_nf ??)

Update: 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:

/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.

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

Fehlermeldung: no xmit buf

Dieses Problem scheint unabhängig vom (noch) vorhanden Arbeitsspeicher aufzutreten. Folgendes findet sich in logread, wenn die bridge aufhört, traffic am wifi Interface zu senen. Von g4 mit kernel 2.6.21.5: 

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

Und dies stammt von garten94 von der mit der seriellen Konsole überwachten Fonera (Kernel wieder 2.6.21.5): 

Jan  1 15:53:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 15:54:06 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 15:54:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 15:54:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 15:55:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
.
.
.
Jan  1 16:29:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 16:29:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 16:29:45 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 16:29:54 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 16:30:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 16:30:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan  1 16:30:07 OpenWrt user.info kernel: NETDEV WATCHDOG: wifi0: transmit timed out
/ # date
Sat Jan  1 16:33:36 UTC 2000
root@OpenWrt:/# free
              total         used         free       shared      buffers
  Mem:        13612         9012         4600            0          768
 Swap:            0            0            0
Total:        13612         9012         4600

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

Von „https://oldwiki.funkfeuer.at/index.php?title=Arbeitsgruppe_Software_AdhocBridge&oldid=8639“