Version vom 19. August 2008, 19:37 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_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. 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... :)

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.