lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <AANLkTikP+jMHvDgkGTXfq58M7TEBthzuvEFoENXvxyqJ@mail.gmail.com>
Date:	Tue, 14 Dec 2010 10:39:12 -0800
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	linux-wireless <linux-wireless@...r.kernel.org>
Cc:	linux-kernel@...r.kernel.org,
	Vipin Mehta <Vipin.Mehta@...eros.com>,
	Gery Kahn <geryk@...com>,
	Michael Green <Michael.Green@...eros.com>,
	wireless-regdb@...ts.infradead.org,
	Tevfik Yucek <Tevfik.Yucek@...eros.com>,
	Susinder Gulasekaran <Susinder.Gulasekaran@...eros.com>,
	Rich Mosko <Rich.Mosko@...eros.com>,
	Mahboob Alem <Mahboob.Alem@...eros.com>,
	Madhan Jaganathan <Madhan.Jaganathan@...eros.com>,
	Sundar Sankaran <Sundar.Sankaran@...eros.com>
Subject: DFS development roadmap 2010-12-14

Note: this is a public e-mail

We had a good IRC session, and were able to at least come up with a
development roadmap to focus on:

http://wireless.kernel.org/en/developers/DFS#Development_roadmap

Some good news is we have a raise in hands by TI to participate in the
development. Things we need to iron out for each development step:

1) Map countries to a DFS region bit

The plan is to map each country in db.txt from wireless-regdb to a DFS
region. There are only 3 known DFS regions:

  * FCC
  * ETSI
  * JP/Telco

Michael, David, do you guys expect this to change any time soon (say
10 years or so)? Anyone else know?

I can work on this.

2) Get DFS region to the driver through cfg80211

This is pretty straight forward once we have 1) done, and I can work on it.

3) Where do we stuff DFS parameters for each region

One idea is to use the request_firmware() API as it is expected these
parameters will be region and chipset specific. This requires a good
review of all chipsets and with priority on the ones who have vendors
or we have documentation for that we want to support in existing
drivers. Today this means Atheros hardware and TI hardware.

Vipin, I am curios how you intend on programming DFS with ath6kl (if
this gets added, we should if TI is doing it ;) ), do you stuff all
DFS parameters in firmware?

Gery, how does TI do it?Most of the work here will involve hooking
things up for mac80211 / cfg80211 / nl80211. This will consists of
receiving DFS events from the driver for radar detection, keeping the
NOL list, sending it to hostapd, choosing a random channel, and
sending CSA to STAs.

4) Program hw DFS parameters

ath9k_hw already has some knobs for this, Felix already submitted some
of these changes upstream. Most of the work required here will take
place on ath9k.

5) DFS events

Most of the work here will involve hooking things up for mac80211 /
cfg80211 / nl80211. This will consists of receiving DFS events from
the driver for radar detection, keeping the NOL list, sending it to
hostapd, choosing a random channel, and sending CSA to STAs. We can
worry about this eventually, once we get the above 4 steps done.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ