[Prism54-devel] RFC: wifi_modes.txt v0.1

[Jean-Baptiste Note]

Hello Denis,

> This is a gray area. See the (somewhat long) thread pasted below my sig,
> especially grep for '(since client does not specify basic rates)' in
> Jouni Malinen post.

You're not the only one to think this is a gray area, for 802.11b then
802.11g all amend the paragraph 7.3.2.2. I rely on the 802.11g version,
which seems clear enough :

(7.3.2.2)

for Beacon, Probe Response, Association Response, Reassociation Response
management frames, the basic rate bit makes sense. Those frames are
*all* emitted by the "master" of the BSS. The information you find there
forms the rateset and BasicRateSet of the BSS.

for other frames, in particular for frames sent by stations, the "basic
bit" should be discarded.

In order to be conservative, (liberal about what you accept but tight in
what you emit), it would be wise to scrap this basic rate bit from all
packets when in client mode.

Section 9.6 of the 802.11g standard, "multirate support", helps
understanding what the Raseset emitted by the clients mean.

(9.6)

* STA rateset inform other STAs in the BSS about what rate you can
  receive packets at;

* when talking directly to another STA, you can use its highest
  advertised rate *which is less than the highest rate (basic or not) of
  the BSS (the ones advertised by the beacons of the BSS)*. This makes
  sense as the master must track all that is happening in its BSS.

So, here, in order to be conservative, i'd say that when you receive the
beacons from the BSS you're trying to join, you should scrap from your
advertised rateset the rates that are higher than the advertised BSS
rateset (both basic and operational), so that a deficient STA
implementation won't use a rate outside the BSS rateset when talking to
you.

* It also says that you must limit yourself to the BSS basic rate set
  for CTS / ACK packets. This means that when Master, you should not
  limit the basic rateset too much, otherwise you'll limit the speed on
  your network (to what extent, i don't know...)

Let's try to sum it up.

1/ Basic RateSet / operational RateSet in master frames define the
rateset of the BSS. It limits *all* data transmission rate inside the
bss to the highest RateSet (basic and operational), and it limits *some*
(ACK, CTS) data transmission rate to the basic RateSet. It also makes
sure that all stations in the BSS can accept packets sent at a rate in
the Basic RateSet.

2/ the Basic RateSet / operational RateSet distinction has no meaning
for the packets emitted by a STA. implementations *should* scrap this
bit, but to be on the safe side, maybe we shouldn't set it at all. It
limits data transmission rate when talking to this precise station, but
one may notice that this set shall always include the BSS Basic Rates.

I'm sorry i don't express myself properly at all times, but if you can
make sense out of this, can you tell me if i have missed something, and
does it answer your questions ?

While I'm at it, i need to decode rate information for prism54 softmac
chipset protocol. In order to do this, i'd like to be able to set up a
BSS with only one basic rate in the rateset, so that the windows driver
will be forced to use one fixed rate, then switch this rate, and see
what the difference in the USB packets will be. You seem to have a
device with a driver capable of doing this, can you tell me what it is ?

JB

-- 
Jean-Baptiste Note
+33 (0)6 83 03 42 38
jean-baptiste.note at wanadoo.fr