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?):
* 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
* 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.
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().
From: Michael Taylor [mailto:***@apprion.com]
Sent: Thursday, November 15, 2007 3:09 PM
To: Derek Smithies
Cc: Josef Kriegl; email@example.com
Subject: Re: [Madwifi-devel] CSA action frame support
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.
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
bgscan is a red herring here. An active scan is performed when hostroaming
is enabled (whether controlled by supplicant or madwifi).