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

[Felix Fietkau]

Marco Tidow wrote:
> nach ein paar drolligen situationen wiederhole ich hiermit einen
> schon vor wochen geäußerten hinweis zum zusammenspiel zwischen atheros-
> und broadcom-bestückten(vulgo: WRT, Siemens, allnet, ...) ff-nodes.
> 
> 
> wenn broadcom-router mit kleinerer fragmentierung auf der funk-ebene, als
> der
> "grüner-haken"-freifunk-firmware-default + "ich-bin-ja-so-freifunk-konform"
> -vorgabe von
> 
>    FRAG = 2346 unter einstellungen->drahtlos betrieben werden
> 
>   (2346 heißt: ohne fragmentierung von IP-packets auf der funk-ebene)
> 
> macht sich ein bug im madwifi-treiber (also auf allen laptops, foneras,
>  geräten mit atheros chipset etc.) bemerkbar, beim zweiten unicast-fragment,
> das er von einem broadcom-router empfängt, "taub" zu werden, auf diesen
> unicast nicht zu antworten.
> 
> verifizierbar dadurch, das zwar arping´s und std-ping´s (mit 56byte) zwischen
> ath-node und brcm-router sauber funktionieren, aber ping´s ab der packet-size
> (brcm-FRAG - 64) nicht, mit total packet-loss antworten.
> 
> broadcast-packets sind hiervon nicht betroffen, weshalb die routing-
> entscheidung leider solche "atheros-blackholes" einschließt...
> 
> 
> ein (schlechter) workaround kann derzeit sein, die brcm-nodes mit einer
> MTU=(brcm-FRAG - 64) auf funk-level zu betreiben oder routen zu atheros-nodes
> per
> 
>   ip route add ATHEROS_IP/32 via LOCAL_WIFI_IP mtu $((FRAG - 64))
> 
> manuell funktionsfähig zu machen, bis der bug im madwifi gefixt ist.

Moin,

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?

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

- Felix