Re: Changes from OpenAP

From: Eric Enockson (
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 ap
will 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

This archive was generated by hypermail 2.1.4.