Hi Ronald.
> >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!
Yes, that's about as far as I got. However I think that a forth
address field wasn't strictly necessary if the interface remembered
which hwaddr it used for the SA of the last frame sent when waiting
for an ACK. I think this should work as we never send more then one
frame when waiting for an ACK. - Now I wonder if it would be possible
to implement the above remember-SA-behaviour ...
But if this "fix" directly violates the spec then perhaps this is
not such a good idea to have it in the default driver and then
perhaps it is easier to devise one of the workarounds you mention ...
> 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
Are you sure that this works in the case of a bridge (as oposed to
Layer-3 routing) - I expect the Layer-2 routing to go nuts, as we
would have to identical addresses in the same Layer-2 segment.
> - 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.
Yes, that's what I'm currently doing via ebtables and arptables. (I don't
care about the higher level protocols as the bridge is intended to be
completely transparent there.)
> 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...
Unfortunately not: As I've written at the bottom of the mail, the
devices are to be deployed in a rather big mesh network with
diverse hardware and operating in 3-address mode.
> 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.
Thanks for the interessting pointer. Even if it doesn't solve what
I want, I think I can learn something from your patch ...
Harald
> >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 one 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 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=/
| 
