[Berlin-wireless] nochmals, fuer fonera-betreiber und alle, die ff-nodes/laptops mit atheros-chipset benutzen

[Marco Tidow]

On Mon, May.14. 16:29 +0200, Felix Fietkau wrote:
> ich würd gerne beim fixen dieses Bugs mithelfen. Werden die großen
> Pakete in dieser Konfiguration auf madwifi in einem Monitor-VAP
> empfangen? Oder kommt nix davon an?

meine Beobachtung + Rückschluß bzgl. des 2. fragments resultiert aus
einem monitoring der TACKs in der Luft (mit einem 3.device, bcm im
monitor-mode):  das vom fonera auf das 2. vom bcm versandte
packet/fragment kam nicht.

und wegen des zusammenhangs ~ "geht bis brcm-FRAG + 64 byte".

monitor-VAP probiere ich nochmal.


Zum Gegen-check, vielleicht habe ich was übersehen/mißverstanden:
situ/setup  WRT <-ad-hoc-> fonera

nvram setup des WRT
  - setzt nur auf CSMA/CA
  - soll auch mit b-only-devices noch sprechen
  - Ziel ist, die rate Steuerung später aus der aktuellen routing-decision
    rückzukoppeln, bis dahin rate = vorerst (fast) kgN

  #wl0_phytype=g
  nram set wl0_bcn=100
  nram set wl0_closed=0
  nram set wl0_dtim=1
  nram set wl0_frag=384
  nram set wl0_frameburst=off
  nram set wl0_gmode=1               # mixed b+g
  nram set wl0_gmode_protection=off
  nram set wl0_lazywds=1
  nram set wl0_net_mode=mixed
  nram set wl0_plcphdr=long
  nram set wl0_rate=2000000
  nram set wl0_rateset=default       # 1,2,5.5,11 als b-raten
  nram set wl0_rts=2347



erst passiert "ifup wifi", ein init-script macht danach noch folgendes:
(Ergebnis nächtelanger try-n-error sessions in Umgebung mit ~ 20 wlans,
 daß die ff-router sich nicht von managed-mode nets unterbuttern lassen)

# verwendet wird das wl aus dem wl-adv
# d.h. auch tx-power wird beim start fest eingestellt

/usr/bin/wl lazywds 0     # wirkung unklar, wds<>ad-hoc ???, aber stabiler so

R="$(exec /usr/sbin/nvram get wl0_rate)"
R="${R%%0*}"; if [ "$R" = '55' ]; then R='5.5'; fi
/usr/bin/wl mrate $R      # fixe broadcast (+ preamble?) rate
/usr/bin/wl rate  $R      # fixe unicast rate (eigentlich durch wifi util schon drin)

                          # b-device protection off
/usr/bin/wl gmode_protection_control 0
/usr/bin/wl gmode_protection_override 0
/usr/bin/wl gmode_protection_cts 0

/usr/bin/wl interference 0  # ?nicht alles undekodierbare für Küchenmicrowellen halten?



fonera:

  mode 3
  egal ob rts + frag
    analog per iwconfig geändert
    oder auf ff-defaults (250/off)




> Noch was, das man ausprobieren könnte:
> In net80211/ieee80211.h wird IEEE80211_MAX_LEN als 2300 + ... definiert.
> Änder das doch mal auf 2364 + ...

o.k., passiert.

meine Vermutungen gingen bislang noch eine Ebene tiefer, in Richtung
Demodulation, e.g.
daß der atheros/HAL ab dem 2. fragment die payload als OFDM "erwartet";
mit dem auf fixed b-rate weiter-sendenden b+g-fähigen Nachbarn nicht "rechnet"?
(sollte die Mod. nicht in der preamble signalisiert sein, resp. diese bits
 im HAL berücksichtigt?)

preamble auf auto beim WRT (im Betrieb oder mit reboot) bringt keine Änderung.

über die Details der atheros-chips, was in hardware und was im HAL passiert
habe ich leider viel zu wenig plan, doku.


checkout Deiner fixes am madwifi im kamikaze von gestern läuft grad,
hab Dank!

Gruß, marco