802.11h Support (was STA IE Channels wrong)

For the need of Lintrack project, this has been implemented both in STA mode (sending SC IE) and AP mode (association decision based on received SC IE). For AP mode, four different behaviors have been made available for the user to choose. See comments in the source code and/or Lintrack documentation in its configuration system (fcc) for more details. The code is relatively fresh, some of the implemented options are quite expreimental and by some means not complete yet. However, as far as my tests are concerned it seems to work well. Anyway, any comments/suggestions (especially along with some test results!) are welcome.

http: //dev.lintrack.org/browser/trunk/packages/madwifi/patches/013-supported_channels.diff.bz2?format=raw

It is important to add that the patch linked in #962 (or any other solution of this problem) is necessary for this one to work properly in tight and strict mode.

One more thing... This patch is quite huge, since it combines a few modifications concerning the same topic. Some parts of the code has been structurized to improve its readability, some other parts have their functionality changed. See e.g.

http: //dev.lintrack.org/ticket/100

Replying to mrenzmann:

Has there been any movement on this issue? Can anyone confirm this patch worked for them? I'm about to try it on trunk today or tomorrow and I'd appreciate any tips. I'll post an updated patch if possible, but it's tricky since I'm working from the refcount branch and keeping in sync with trunk periodically.

- M

This looks fairly correct. It will need reviewing, and I should probably merge refcount first.

Updated to apply cleanly against trunk (revision 2361)

We shouldn't be importing code from Linux in ieee80211_scan_ap.c; include linux/sort.h instead.

Also, as an aentirely functinoless comment, it would be nice if we had spaces around binary operators (i.e., +, -, >, etc) and if the comments came before the constants in the enums.

Turbo modes aren't defined in any standard... so maybe we are being careful about using them for interoperability reasons...

We should take care not to forget a review of the related ticket #962 (see above).

I agree. I only reformatted the patch originally submitted by Mike Wrobel and I didn't review the formatting.

Can you explain why you said "Turbo modes aren't defined in any standard... so maybe we are being careful about using them for interoperability reasons..." as I may have missed something in his patch.

I thought his patch would still use turbo modes.

I am going to subsume this patch into a larger patch for DFS work shortly.

Updated patch includes more of the functionality. Current status:

This patch is a work in progress for regulatory testing and compliance.

Included: * Updated channel and power IE values (from previous patch contributed by Mike Wrobel) * Uniform channel spreading algorithms (from previous patch contributed by Mike Wrobel) * Client association restrictions / channel changing algorithms for DFS

(how many common channels needed to associate, tradeoffs in dropped clients for RSSI gained, etc.)

* Radar pulse detection * DFS / channel availability check * DFS / co-channel interference avoidance (Radar detection / reaction)

• change channels
• stay off channel for channel non-occupancy limit
• restore channel to service after timeout
• return to channel if it was the 'preferred channel'

* Continuous transmission mode (for testing) * Radar event injection (for testing) * DFS radar detection testing (detection without channel switching) (for testing) * DFS radar detection timing tweaks (for testing)

Still remaining: * ALL pulses are all treated as radar right now. The algorithm must be implemented that checks events over time to detect

periodicity of pulses and bursts (to filter out non-priority signals) from consideration.

* After the first pulses, and during analysis just mentioned, reduce duty cycle to increase chances of detection. * The channel chosen when radar is detected probably isn't using uniform channel spreading.

Won't do: * Station DFS can notify the AP of a radar detection with an unsolicited IE indicating the interference.

I am not adding this for security reasons as a DoS is possible without proper consideration.

Sorry about formatting above.

This patch is a work in progress for regulatory testing and compliance.

Included:
*  Updated channel and power IE values (from previous patch contributed by Mike Wrobel)
*  Uniform channel spreading algorithms (from previous patch contributed by Mike Wrobel)
*  Client association restrictions / channel changing algorithms for DFS
   (how many common channels needed to associate, tradeoffs in dropped clients for RSSI gained, etc.)
*  Radar pulse detection
*  DFS / channel availability check
*  DFS / co-channel interference avoidance (Radar detection / reaction)
   - change channels
   - stay off channel for channel non-occupancy limit
   - restore channel to service after timeout
   - return to channel if it was the 'preferred channel'
*  Continuous transmission mode (for testing)
*  Radar event injection (for testing)
*  DFS radar detection testing (detection without channel switching) (for testing)
*  DFS radar detection timing tweaks (for testing)

Still remaining:
*  ALL pulses are all treated as radar right now.  The algorithm must be implemented that checks events over time to detect
   periodicity of pulses and bursts (to filter out non-priority signals) from consideration.
*  After the first pulses, and during analysis just mentioned, reduce duty cycle to increase chances of detection.
*  The channel chosen when radar is detected probably isn't using uniform channel spreading.

Won't do:
*  Station DFS can notify the AP of a radar detection with an unsolicited IE indicating the interference.  
   I am not adding this for security reasons as a DoS is possible without proper consideration.

updated patch

for trunk r2394

Use this patch on r2404.

Better yet, use r2405.

Cool!!!!!!! I will try It as soon as possible. We are using about 50 atheros cards with madwifi drivers in Czech republic, lack of 802.11h support in madwifi has resulted to remove all those cards from PC and use it on routerboard with mikrotik OS.

All,

The patches have been merged into branches/madwifi-dfs and are under active development. For the latest DFS related code please check out the branch and give us feedback. Feel free to post patch requests here to this ticket.

Please see the madwifi-devel mailing list archives for announcement and credits for work included so far.