Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #113 (new defect)

Opened 12 years ago

Last modified 10 years ago

802.11h Support (was STA IE Channels wrong)

Reported by: br1 Assigned to: mtaylor
Priority: major Milestone: version 0.9.x - progressive release candidate phase
Component: madwifi: 802.11 stack Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:

Description

the information element "Supported Channels" sent by STAtions in the associaction requests is wrong. it should not contain a bitmap of channels, but first_channel_number / number_of_channels pairs for each subband (low/middle/high). this is defined in 802.11h chapter 7.3.2.19.

i have removed sending the wrong information, but unfortunately i don't know how to calculate the needed information concerning the subbands.

as a related problem: in AP mode we have to check this information in order to decide if we can accept a STA.

Attachments

013-supported_channels.diff (59.2 kB) - added by xmxwx@asn.pl on 10/19/06 01:54:41.
madwifi-0.9.3-supported-channels.diff (62.1 kB) - added by mtaylor on 05/22/07 00:11:40.
Updated to apply cleanly against trunk (revision 2361)
madwifi-0.9.3-fcc.diff.gz (50.0 kB) - added by mtaylor on 05/24/07 00:10:43.
updated patch
madwifi-0.9.3-fcc.diff.2.gz (39.3 kB) - added by mtaylor on 05/30/07 05:29:39.
for trunk r2394

Change History

09/04/06 04:32:25 changed by mentor

  • status changed from new to assigned.
  • owner set to mentor.
  • patch_attached changed.

10/18/06 18:43:31 changed by xmxwx@asn.pl

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

10/18/06 18:52:33 changed by xmxwx@asn.pl

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.

10/18/06 20:31:08 changed by xmxwx@asn.pl

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

10/19/06 01:54:41 changed by xmxwx@asn.pl

  • attachment 013-supported_channels.diff added.

(follow-up: ↓ 6 ) 10/19/06 12:49:26 changed by mrenzmann

  • patch_attached set to 1.
  • milestone changed from version 1.0.0 - first stable release to version 0.9.x - progressive release candidate phase.

(in reply to: ↑ 5 ) 03/29/07 18:57:33 changed by mike.taylor@apprion.com

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

04/03/07 04:41:58 changed by mentor

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

05/22/07 00:11:40 changed by mtaylor

  • attachment madwifi-0.9.3-supported-channels.diff added.

Updated to apply cleanly against trunk (revision 2361)

05/22/07 01:11:04 changed by mentor

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.

05/22/07 01:26:42 changed by mentor

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

05/22/07 06:26:30 changed by mrenzmann

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

05/22/07 16:33:29 changed by mentor

  • status changed from assigned to new.
  • owner deleted.

05/22/07 22:46:11 changed by mtaylor

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.

05/22/07 22:46:37 changed by mtaylor

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

05/22/07 22:52:14 changed by mtaylor

  • owner set to mtaylor.

05/22/07 23:25:02 changed by mtaylor

  • summary changed from 802.11h STA IE Supported Channels wrong to 802.11h Support (was STA IE Channels wrong).

05/23/07 23:38:08 changed by mtaylor

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.

05/23/07 23:41:27 changed by mtaylor

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.

05/24/07 00:10:43 changed by mtaylor

  • attachment madwifi-0.9.3-fcc.diff.gz added.

updated patch

05/30/07 05:29:39 changed by mtaylor

  • attachment madwifi-0.9.3-fcc.diff.2.gz added.

for trunk r2394

05/30/07 21:43:28 changed by mtaylor

Use this patch on r2404.

05/30/07 23:14:43 changed by mtaylor

Better yet, use r2405.

06/08/07 00:14:40 changed by thunder.m

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.

06/14/07 06:36:05 changed by mtaylor

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.