Arbeitsgruppe Software AdhocBridge: Unterschied zwischen den Versionen
(Memoryleak, und wifi Probleme) |
(Hinweis auf requeues Statistik zum Debuggen) |
||
| 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 | ||
Version vom 27. August 2008, 20:53 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)
Inhaltsverzeichnis
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_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)
Eigene Firmware?
Aufgrund des modifizierten kenrels ist es nciht 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)
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
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 oder alle Links verliert. Anscheinend gibt es mindestens zwei Probleme:
Memoryleak (Lösung gefunden)
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:
/ # 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
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
