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

[Marco Tidow]

moin,

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.

derart statische host-routen sind natürlich nicht kompatibel mit olsrd/
batmensch, führen über kurz oder lang zu routing-loops.  deshalb bitte auch
nur temp. verwenden, in probe-setup´s, beim basteln !!!


da ich aus gutem grund empfehle, die wifi-ebene ohne RTS und mit sehr kleiner
fragmentierung zu betreiben, und dieser bug _nur_ mit madwifi-zeug unter
linux auftritt, nicht mal mit atheros-laptops unter m$-windows,
und die ganze palette anderer wifi-hardware auch unter linux einwandfrei
(und besser als mit firmware-defaults) mit so konfigurierten broadcom-nodes
zusammenspielt, und nur des bastelns willige freifunker betroffen sind,
sehe ich keinen grund, von meiner empfehlung beim betrieb von
"production-level"-links abstand zu nehmen.


gruß, marco