Hi Harald,
>-----Original Message-----
>From: madwifi-devel-bounces <at> lists.sourceforge.net
>[mailto:madwifi-devel-bounces <at> lists.sourceforge.net] On Behalf
>Of Harald Geyer
>Sent: dinsdag 22 juli 2008 19:45
>To: madwifi-devel <at> lists.sourceforge.net
>Subject: [Madwifi-devel] bridging adhoc mode device and
>ethernet -> bad ACKhandling
>
>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?
It's a problem of the IEEE 802.11 design  And to cover it up, IEEE
802.1D-2004, clause 6.5.4 says that what you are trying to do (i.e.
bridge between wired ethernet and ad hoc WLAN) is not allowed...
Normally, there are only three address fields in an 802.11 data frame.
In ad hoc mode, these are: Destination Address (DA), Source Address
(SA), and BSSID. In your case a), the problem is what SA should be: the
MAC address of the wireless interface, so that the frame can be
correctly acknowledged OR the MAC address of the originating system on
the wired ethernet, so that the bridge will learn about its presence?
There isn't room for both!
Work arounds have been devised:
- address cloning, where the wireless interface is configured with the
MAC adress of a system on the wired side. This has the disadvantage that
there can only be one system on the wired side of the bridge
- some form of MAC address translation (MAT?) in the bridging device.
This has the disadvantage that it must also deal with protocols above
the MAC layer, such as ARP. Basically, you need a separate solution for
each network layer protocol you use: IPv4, IPv6, etc.
An example of a device that can do address cloning or MAT (IPv4 only) is
Linksys WET54G.
Another option is the use of 4-address mode as defined by IEEE 802.11.
This was originally intended for Wireless Distribution System (i.e. AP
to AP traffic) only. However, it can be tweaked to achieve what you want
to do, perhaps...
Have a look at http://madwifi.org/ticket/1131 . My patch might work for
you, if the other nodes in your ad hoc network can deal with 4-address
mode. If these are under your control, and run Madwifi as well, they can
be made to. I should add, that my patch was intended for the symmetrical
case, where there is bridging on both (or: all) sides. I have a further
fix, which also deals with an asymmetrical setup like yours. I will add
this shortly.
>
>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.
My patch makes Madwifi learn which wired MAC addresss are "hiding"
behind wich wireless nodes.
>
>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...
Let me know whether my patch does or doesn't work for you.
Regards,
Ronald
>
>
>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=/
>_______________________________________________
>Madwifi-devel mailing list
>Madwifi-devel <at> lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/madwifi-devel
>
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
-------------------------------------------------------------------------
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=/
| 
