| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Various changes in the commit mentioned below broke
compatibility with python2. Restore it in a way that
makes it worth with both versions.
Fixes: f3c4969c2485 ("wireless-regdb: make scripts compatible with Python 3")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 8607edfdb6568 ("wireless-regdb: Parse wmm rule data") introduced
a dependency to the python module attr which is not included by default
in all python installations. Replace the code with manually coding the
constructor instead of using attr. This makes the code also work on
systems without attr.
I would like to avoid an additional dependency in OpenWrt where we
compile the regulatory database inside of the build system.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Python 3 gives errors as a result of the changes to add wmm
rules since Permission.wmmrule can be set to None:
TypeError: '<' not supported between instances of 'WmmRule' and 'NoneType'
To fix this, supply compairson methods for WmmRule instead of
using the ones provided by attrs. Doing this means we also need
to supply a __hash__ method.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
|
| |
|
|
|
|
|
|
| |
Add code to parse wmm rule data.
Also write it to the the regulatory.db fw file
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When playing with the generation scripts for OpenWrt development, I noticed
that these scripts still required Python 2. Future-proof them by replacing
deprecated functions with new Python 3 compatible variants. The result
works with both Python 2.7 and Python 3.x; older Python 2.x releases are
not supported anymore.
regulatory.db and regulatory.bin are unchanged and reproducible across
Python versions. Note that there is no stable release of m2crypto for
Python 3 yet; I used the current development branch for testing.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
|
| |
|
|
|
|
| |
This reverts commit ff459d77110ce4b9d08589e1d0b12484f5c0a961.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Sync with latest nl80211.h and add AUTO-BW flag.
If this flag set, maximum available bandwidth should
be calculated base on contiguous rules and wider channels
will be allowed to cross multiple contiguous/overlapping
frequency ranges.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow max bandwidth to be AUTO calculated, base
on contiguous rules. This AUTO ( bw = 0) parameter will be
send to the kernel mode (cfg80211/nl80211) and next maximum
allowed bandwidth will be calculated base on contiguous rules.
Eg.
country PL: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ AUTO), (N/A, 20)
(5250 - 5330 @ AUTO), (N/A, 20), DFS
(5490 - 5710 @ 80), (N/A, 27), DFS
This mean we will calculate maximum bw for rules where
AUTO were set, 160MHz (5330 - 5170) in example above.
So we will get:
(5170 - 5250 @ 160), (N/A, 20)
(5250 - 5330 @ 160), (N/A, 20), DFS
In other case:
country FR: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ AUTO), (N/A, 20)
(5250 - 5330 @ 80), (N/A, 20), DFS
(5490 - 5710 @ 80), (N/A, 27), DFS
We will get 80MHz (5250 - 5170):
(5170 - 5250 @ 80), (N/A, 20)
(5250 - 5330 @ 80), (N/A, 20), DFS
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
|
|
|
|
|
|
|
|
| |
This data is not accurate, cannot be relied upon given
that antenna gain is very specific to the device being
manufactured, and we never used it. Just kill it to
simplify the database.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
|
|
|
|
|
|
| |
These are used interchangeably so just do away
with the redundancy.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The kernel uses the bandwidth this way: any frequency
rule that is required for any of the 20 MHz subchannels
of a given channel must allow the total bandwidth.
Therefore, this check is wrong -- a frequency rule may
need to be specified with higher bandwidth than it has
to allow to form e.g. HT40 out of subchannels.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support master DFS we add the three known DFS regions which
countries are known to support. In order to modify the regulatory
database schema in a backward compatible way we use one of
the two pad bytes which were unused. By using one of the two pad
bytes we end up keeping new regulatory databases with DFS region
support compatible with older verions of CRDA, the DFS region would
just not be sent to the kernel when using an old version of CRDA.
DFS master is only required for modes of operation which iniate
radiation on DFS channels, we will start supporting DFS with AP
mode of operation. Without DFS master support you cannot intiate
radiation on those channels (AP, Mesh, IBSS, P2P). Apart from support
from wireless-regd, crda and the 802.11 stack you'll also need proper
DFS support on your device driver.
A country can only map to one DFS region at a time for all frequency
regions. After this patch countries can start being mapped to their
own DFS region.
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
|
|
|
|
| |
<julian.calaby@gmail.com> in email to linux-wireless on 6 March 2009.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
|
|
|
|
|
|
|
| |
Do sanity checks on the frequency range before building upon it.
The kernel will reject these so we want to know if we goofed up
first.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
|
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
