From: Eric Enockson (eric_at_dotconf.org)
Date: 2002-02-12 20:27:32 UTC
On Thu, Jan 24, 2002 at 07:39:12AM +0200, Jouni Malinen wrote:
> On Wed, Jan 23, 2002 at 06:44:36PM +0200, Jouni Malinen wrote:
>
> > It looks like OpenAP changes do not care much about
> > Ad-hoc/Managed mode operations (i.e., they would be broken) etc. I'll
> > need to fix these and also make AP-AP mesh code configurable with a
> > module parameter etc. so that it is not used unless needed.
they probably were trying to save space. With only 2 megs to work with and people no doubt wanting ap mode from their ap's other modes might have been neglected or nixed.
> Hmm.. After reading the code more carefully, I think there are more
> problems with this "AP-AP mesh" implementation. Comments were quite a
> bit misleading in prism2_tx() about the 4-address frame. First, I
> assumed it to be almost compatible with 802.11 standards, but it
> really isn't. Frames use only ToDS (not FromDS) and the fourth address
> is in the end of the data - not in the end of the header.
I don't understand frames must use both ToDS and FromDS.
from 802.11 spec
Table 2 To/From DS combinations in data type frames
To/From DS values Meaning
To DS = 0 From DS = 0 A data frame direct from one
STA to another STA within the same IBSS, as
well as all management and control type frames.
To DS = 1 From DS = 0 Data frame destined for the DS.
To DS = 0 From DS = 1 Data frame exiting the DS.
To DS = 1 From DS = 1 Wireless distribution system (WDS) frame being
distributed from one AP to another AP.
So it seems to me you would just use ToDS = 1 FromDS = 1 to
do ap<->ap mesh routing. Then when forward to finally dest station
you might change the ToDS FromDS again.
Also with the addressing i'm just getting familiar with openap's stuff and your code but it shouldn't be a big deal.
it's just
Frame control:Duration id:address 1:address 2:address 3:seq control:
address 4:frame body: fcs
With Frame control containing the controling ToDS and FromDS fields protocl versoin number: type: subtype: ToDS: FromDS: frag: Retry: power mgmnt: more date: wep: order
it's all in
chapter 7 Frame formate 802.11
and the ToDS and FromDS determine the address fields
Table 4 Address field contents
To DS From DS Address1 Address2 Address3 Address4 0 0 DA SA BSSID N/A 0 1 DA BSSID SA N/A 1 0 BSSID SA DA N/A 1 1 RA TA DA SA So that should give all the info each mesh routing apwill need to route and handle pkts to from it's associated ap's and bss clients.
In other
> words, these AP-AP links would not be compatible with any other
> equipment/software..
>
> I would not like to add incompatible version of the 4-address frames
> for wireless distribution system; at least without first confirming
> that this would really be the only option with Host AP mode. I'll do
> some testing and postpone merging the "AP-AP mesh" to my driver until
> this can be resolved. First, I'll just merge obvious bug fixes from
> OpenAP release.
>
> If someone has any ideas or comments about AP-AP links, they would be
> welcome. My current driver uses kind of pseudo ad-hoc mode (i.e., no
> ToDS or FromDS flags (and only 3 addresses) in frames between
> APs). OpenAP uses four addresses, but in a way that is not compatible
> with 802.11 standards.
>
>
> --
> Jouni Malinen
> SSH Communications Security Corp
> jouni.malinen_at_ssh.com