Discussion:
CSA action frame support
(too old to reply)
Josef Kriegl
2007-11-13 03:55:00 UTC
Permalink
My question relates to the support of channel switch announcement (csa)
action frames in madwifi-dfs/ and whether support for csa action frames is
imminent. If not I wanted to know where in the code would be a good place to
start adding support for action frames (ieee80211_output.c, modeled after
existing management frame creation routines).

Thanks,
Josef
Josef Kriegl
2007-11-15 19:15:21 UTC
Permalink
My question relates to the support of channel switch announcement (csa)
action frames in madwifi-dfs/ and whether support for csa action frames is
imminent. If not, I wanted to know where in the code would be a good place
to start adding support for action frames.

Thanks,
Josef
Michael Taylor
2007-11-15 20:47:29 UTC
Permalink
Answer:

CSA in IE is supported on beacons currently, and most accurately in
madwifi-dfs branch.
Action frames are probably not supported correctly in either madwifi-dfs
or madwifi trunk.

Benoit and I are actively working on madwifi-dfs branch, and would
welcome any help testing/adding CSA IE support for action frames there.

Cheers,

Mike
Post by Josef Kriegl
My question relates to the support of channel switch announcement (csa)
action frames in madwifi-dfs/ and whether support for csa action frames is
imminent. If not, I wanted to know where in the code would be a good place
to start adding support for action frames.
Thanks,
Josef
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Madwifi-devel mailing list
https://lists.sourceforge.net/lists/listinfo/madwifi-devel
Michael Taylor
2007-11-15 20:49:35 UTC
Permalink
By the way, why do you want to use action frames? We use CSA in beacons
for channel changes today in both trunk and madwifi-dfs and that works
well enough. We even support a switch tbtt time of zero, for switch on
the very next beacon in madwifi-dfs (which is good enough to pass
FCC/ETSI timing requirements).

I'm curious as to why you want this...

Cheers,

Mike
Post by Michael Taylor
CSA in IE is supported on beacons currently, and most accurately in
madwifi-dfs branch.
Action frames are probably not supported correctly in either madwifi-dfs
or madwifi trunk.
Benoit and I are actively working on madwifi-dfs branch, and would
welcome any help testing/adding CSA IE support for action frames there.
Cheers,
Mike
Post by Josef Kriegl
My question relates to the support of channel switch announcement (csa)
action frames in madwifi-dfs/ and whether support for csa action frames is
imminent. If not, I wanted to know where in the code would be a good place
to start adding support for action frames.
Thanks,
Josef
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Madwifi-devel mailing list
https://lists.sourceforge.net/lists/listinfo/madwifi-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Madwifi-devel mailing list
https://lists.sourceforge.net/lists/listinfo/madwifi-devel
Derek Smithies
2007-11-15 21:32:22 UTC
Permalink
Hi,
because beacon frames are not reliably sent.

The big issue for me with csa is how do you avoid network partitioning?
Some of the nodes in the network hear the CSA, and move, but not all.
This is not a problem for an in office network, but what about a city wide
network?

The announcement on csa has to be reliably sent to all nodes in the
network.

One could argue that in the case where the network partitions (some nodes
on one channel, others on a different channel) the background scanning
will eventually "bring them back to the same channel".

However, background scanning has a detrimental effect on network
throughput. - as it means a node is on a different channel listening for
packets (and is not available for carrying data packets).

Further, background scanning (on a different channel) causes a hal reset,
which resets calibration data, and impacts on the data rates achieved.

Derek.
Post by Michael Taylor
By the way, why do you want to use action frames? We use CSA in beacons
for channel changes today in both trunk and madwifi-dfs and that works
well enough. We even support a switch tbtt time of zero, for switch on
the very next beacon in madwifi-dfs (which is good enough to pass
FCC/ETSI timing requirements).
I'm curious as to why you want this...
Cheers,
Mike
Post by Michael Taylor
CSA in IE is supported on beacons currently, and most accurately in
madwifi-dfs branch.
Action frames are probably not supported correctly in either madwifi-dfs
or madwifi trunk.
Benoit and I are actively working on madwifi-dfs branch, and would
welcome any help testing/adding CSA IE support for action frames there.
Cheers,
Mike
Post by Josef Kriegl
My question relates to the support of channel switch announcement (csa)
action frames in madwifi-dfs/ and whether support for csa action frames is
imminent. If not, I wanted to know where in the code would be a good place
to start adding support for action frames.
Thanks,
Josef
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Madwifi-devel mailing list
https://lists.sourceforge.net/lists/listinfo/madwifi-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Madwifi-devel mailing list
https://lists.sourceforge.net/lists/listinfo/madwifi-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Madwifi-devel mailing list
https://lists.sourceforge.net/lists/listinfo/madwifi-devel
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: ***@indranet.co.nz
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
Michael Taylor
2007-11-15 23:08:38 UTC
Permalink
Hi,
because beacon frames are not reliably sent. The big issue for me with csa is how do you avoid network partitioning?
I infer that you are talking about an IBSS mesh where not all nodes an
hear all others because your questions don't seem to make sense for
managed mode. In a managed mode, stations get the CSA countdown just
fine from either beacon or action type management frames. If you have a
node that cannot hear the AP, it's going to actively scan and
re-associate anyway. If a node misses a beacon and doesn't switch, it
will lose the association, actively rescan and re-associate (assuming
roaming is on).

CSA IE in either type of management frame will be exactly the same for
what you are trying to do. The action frames are not passed to the OS
like IP broadcast packets, and regardless of your routing and topology -
only those radios that receive those management frames over RF will know
about the CSA.

I suggest that for what you are trying to do, if my inferences are
correct, you will need to use a UDP broadcast that is bridged across a
tree topology constructed from your mesh (i.e. use STP).

The important points are that management frames are not relayed and that
CSA IE in beacon or action frame is the same thing in a different
encapsulation, with exactly the same behavior.

Cheers,

Mike
The announcement on csa has to be reliably sent to all nodes in the
network. One could argue that in the case where the network partitions (some nodes
on one channel, others on a different channel) the background scanning
will eventually "bring them back to the same channel".
However, background scanning has a detrimental effect on network
throughput. - as it means a node is on a different channel listening for
packets (and is not available for carrying data packets).
Background scanning is not needed for roaming to happen, as I have
described above. If the STA has an affinity for a particular BSSID then
it will scan and acquire the other AP as soon as it realizes it has lost
it. With madwifi, for example, this scan is *very* fast. The time
delays have to do with detecting when you are no longer receiving beacons.
Further, background scanning (on a different channel) causes a hal reset,
which resets calibration data, and impacts on the data rates achieved.
bgscan is a red herring here. An active scan is performed when
hostroaming is enabled (whether controlled by supplicant or madwifi).

Cheers,

Mike
Josef Kriegl
2007-11-16 01:38:05 UTC
Permalink
Hi Mike,

Thanks for your feedback, I take your point about CSA IE's achieving the
same goal in a BSS. Also, since action frames would be broadcast like beacon
frames there is no advantage of action frames over beacon-embedded CSA IE's.
however, here are a couple reasons why you might want to support both types
of CSA's, although this is second hand information and I cannot vouch for
the validity of those concerns:

1. STAs may only support either one or the other type

2. depending on the beacon interval, the BSS may be eating into the Channel
Closing Transmission time CCTT (i.e. the 260 msec of tranmission allowed
within the 10 second period following radar detection), although with a
standard beacon interval of 100 msec this ought not to be of too much
concern, although I may want to refer to the commit log for rev 2714 that
expresses concerns about the use of CSA IE's (can you explain?):


Remaining Issues:

* Should use CSA Frame instead of CSA IE to eliminate the requirement for
50ms beacons to squeek under FCC channel move time requirements.
* Should better protect against channel scans during DFS channel
availability
check
* After channel switch from CSA, we get node index errors when attempting to

update station stats
* Want to support 'aggressive mode' DFS where we avoid CAC for a longer
period of time, per ETSI rulings...


Btw, I have been working with the DFS branch for a while, up until now
mainly to evaluate the DFS state machine (i.e. trigger radar events via the
iwpriv command) and have some feedback on that I will describe in a follow
up email. I also have access to high-end test equipment to generate ETSI and
FCC radar pulses and plan to evaluate the radar detection code. I'll keep
you posted on the results as they become available.

-Josef

P.s. not all of my posts seem to be getting through to the list, for example
my initial post that started this thread, as well as a patch to fix a null
pointer reference in net80211/ieee80211_input.c:ieee80211_saveie().


-----Original Message-----
From: Michael Taylor [mailto:***@apprion.com]
Sent: Thursday, November 15, 2007 3:09 PM
To: Derek Smithies
Cc: Josef Kriegl; madwifi-***@lists.sourceforge.net
Subject: Re: [Madwifi-devel] CSA action frame support
Hi,
because beacon frames are not reliably sent. The big issue for me with
csa is how do you avoid network partitioning?
I infer that you are talking about an IBSS mesh where not all nodes an hear
all others because your questions don't seem to make sense for managed mode.
In a managed mode, stations get the CSA countdown just fine from either
beacon or action type management frames. If you have a node that cannot
hear the AP, it's going to actively scan and re-associate anyway. If a node
misses a beacon and doesn't switch, it will lose the association, actively
rescan and re-associate (assuming roaming is on).

CSA IE in either type of management frame will be exactly the same for what
you are trying to do. The action frames are not passed to the OS like IP
broadcast packets, and regardless of your routing and topology - only those
radios that receive those management frames over RF will know about the CSA.

I suggest that for what you are trying to do, if my inferences are correct,
you will need to use a UDP broadcast that is bridged across a tree topology
constructed from your mesh (i.e. use STP).

The important points are that management frames are not relayed and that CSA
IE in beacon or action frame is the same thing in a different encapsulation,
with exactly the same behavior.

Cheers,

Mike
The announcement on csa has to be reliably sent to all nodes in the
network. One could argue that in the case where the network partitions
(some nodes on one channel, others on a different channel) the
background scanning will eventually "bring them back to the same channel".
However, background scanning has a detrimental effect on network
throughput. - as it means a node is on a different channel listening
for packets (and is not available for carrying data packets).
Background scanning is not needed for roaming to happen, as I have described
above. If the STA has an affinity for a particular BSSID then it will scan
and acquire the other AP as soon as it realizes it has lost it. With
madwifi, for example, this scan is *very* fast. The time delays have to do
with detecting when you are no longer receiving beacons.
Further, background scanning (on a different channel) causes a hal
reset, which resets calibration data, and impacts on the data rates
achieved.
bgscan is a red herring here. An active scan is performed when hostroaming
is enabled (whether controlled by supplicant or madwifi).

Cheers,

Mike
Michael Renzmann
2007-11-16 05:13:01 UTC
Permalink
Hi.
Post by Josef Kriegl
P.s. not all of my posts seem to be getting through to the list,
Don't worry, they do, as you can check in the gmane.org archives, for
Post by Josef Kriegl
for example my initial post that started this thread,
http://article.gmane.org/gmane.linux.drivers.madwifi.devel/5364
http://article.gmane.org/gmane.linux.drivers.madwifi.devel/5389
Post by Josef Kriegl
as well as a patch to fix a null
pointer reference in net80211/ieee80211_input.c:ieee80211_saveie().
http://article.gmane.org/gmane.linux.drivers.madwifi.devel/5388

Bye, Mike
Michael Taylor
2007-11-16 05:41:54 UTC
Permalink
Post by Josef Kriegl
Btw, I have been working with the DFS branch for a while, up until now
mainly to evaluate the DFS state machine (i.e. trigger radar events via the
iwpriv command) and have some feedback on that I will describe in a follow
up email. I also have access to high-end test equipment to generate ETSI and
FCC radar pulses and plan to evaluate the radar detection code. I'll keep
you posted on the results as they become available.
-Josef
Josef,

I'm glad to hear it.

The latest code in madwifi-dfs uses a CSA IE with tbtt of zero, meaning
that it emits the CSA IE immediately and blocks all outbound traffic.
Stations get the CSA IE within 100ms and stop transmitting if they are
DFS capable. Depending on what the station is doing and what quality of
DFS support it has you may find that the station doesn't shut up fast
enough. You can pass ETSI and FCC requirements with madwifi-dfs as the
master and station, but non-DFS stations won't work for obvious
reasons. Beacon intervals of <= 100ms should pass at this point. Since
the station awaits ACK and re-transmits on timeout if the AP has gone
dark, you can get a couple of retries from a station that has obtained
the media during or just after detection. Because the AP no longer
replies, the station controlling the media will possibly chirp small
amounts of data before the beacon gets through to squelch all stations.
The only danger would be with a no-ack bursting with block ack, or
something, but is not really a problem for the duty cycle requirements
specified by ETSI and FCC.

Switching to a CSA IE in an action frame might allow us to bypass the
priority queue and inject the CSA IE in a frame directly, possibly
helping quell station traffic a little bit faster. It won't affect the AP.

We have algorithms that properly match all ETSI and FCC patterns, but we
are still getting the noise filtering right.

Cheers,

Mike

Loading...