Subject: bridging adhoc mode device and ethernet -> bad ACK handling
Newsgroups: gmane.linux.drivers.madwifi.devel
Date: 2008-07-22 17:45:07 GMT (24 weeks, 3 days, 9 hours and 55 minutes ago)
Hi! I have a router (la fonera) with one atheros card configured in adhoc mode as ath0 and one ethernet port eth0. If I bridge these devices together, it works, but perfomance of connections over the bridge is really poor. I read most of the madwifi wiki and found some mentions of the problem, but no solution... After some sniffing I figured out that the cause is some rather mad ACK handling. Actually the problem has two parts: a) Some frame with a foreign mac address comes in via the bridge and is to be sent via the wireless interface: The atheros drivers/card sends the frame with the correct linklayer headers (i.e. the foreign mac address), BUT it waits for an ACK to it's own mac address! Thus it sends the frame again and again until the retry limit is reached. - I can't think of any case where such behaviour is useful. Is this a problem of the driver or the hal or the hardware? b) Some frame comes in via the wireless interface but its destination is some mac address behind the bridge: In this case the frame is correctly forwarded over the bridge, but since the wireless interface doesn't know if the destination mac address is really behind the bridge it doesn't ACK the frame. Thus the sending device sends the frame over and over again. - Of course in this case there is some point as we shouldn't ACK frames targeted at third parties. I think a) plainly is a bug in whatever component is responsible. I can understand b) but wonder if there is some way to tell the hardware additional mac addresses for which to ACK frames - after all the VAPs seem to be able to handle severals MACs too ... Any hints or pointers to information are welcome... For the curious of you: I think I have a workaround using ebtables and arptables, but I believe improving the driver/hal would be a good idea if possible. I can't use wds as I'm working on devices for an already existing (quite big) mesh network. Actually I only need to forward on mac address over the bridge so it would suffice to divert the hardwares idea of mac address from what the kernel thinks the mac address of the interface is. But I don't consider this a nice solution either... This is what dmesg reports about my router (la fonera/openwrt): wlan: 0.8.4.2 (svn r2568) ath_hal: module license 'Proprietary' taints kernel. ath_hal: 0.9.30.13 (AR5212, AR5312, RF2316, TX_DESC_SWAP) ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (svn r2568) ath_rate_minstrel: look around rate set to 10% ath_rate_minstrel: EWMA rolloff level set to 75% ath_rate_minstrel: max segment size in the mrr set to 6000 us wlan: mac acl policy registered ath_ahb: 0.9.4.5 (svn r2568) ath_pci: switching rfkill capability off ath_pci: switching per-packet transmit power control off wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP wifi0: mac 11.0 phy 4.8 radio 7.0 wifi0: Use hw queue 1 for WME_AC_BE traffic wifi0: Use hw queue 0 for WME_AC_BK traffic wifi0: Use hw queue 2 for WME_AC_VI traffic wifi0: Use hw queue 3 for WME_AC_VO traffic wifi0: Use hw queue 8 for CAB traffic wifi0: Use hw queue 9 for beacons wifi0: Atheros 2315 WiSoC: mem=0xb0000000, irq=3 device ath0 entered promiscuous mode br-lan: port 2(ath0) entering learning state br-lan: topology change detected, propagating br-lan: port 2(ath0) entering forwarding state ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/