d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ec671f4980
freebsd-dev/lib/lib80211/regdomain.xml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2184 lines
60 KiB
XML
Raw Normal View History

802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<!--
Copyright (c) 2007-2008 Sam Leffler, Errno Consulting
All rights reserved.
Remove trailing white space. No functional changes.
2010-05-14 04:53:57 +00:00
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
Remove trailing white space. No functional changes.
2010-05-14 04:53:57 +00:00
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Remove trailing white space. No functional changes.
2010-05-14 04:53:57 +00:00
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
$FreeBSD$
-->
<regulatory-data>
<!-- Regdomain/SKU definitions -->
<regulatory-domains>
<!--
DEBUG holds all available channels; the driver/device
defines what the capabilities and tx power caps are.
Regdomain code gets this information with the
IEEE80211_IOC_DRIVERCAPS ioctl.
-->
<rd id="debug">
<name>DEBUG</name>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<sku>0x1ff</sku>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</rd>
<rd id="fcc">
<name>FCC</name>
<sku>0x10</sku>
<defcc ref="US"/>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
</band>
<band>
<freqband ref="F1_5825_5825"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
Fix an incorrect frequency band for HT/40 in the FCC SKU. Noticed by: bschmidt@
2011-06-24 12:31:36 +00:00
<freqband ref="H4_2412_2462"/>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
More incorrect HT/40 setups in FCC. Noticed-by: bschmidt@
2011-06-24 12:50:18 +00:00
<freqband ref="H4_5180_5240"/>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
More incorrect HT/40 setups in FCC. Noticed-by: bschmidt@
2011-06-24 12:50:18 +00:00
<freqband ref="H4_5745_5805"/>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
[lib80211] add initial VHT (11ac) channel ranges for FCC. This is a simple set of VHT channels and flags for the FCC (US) regulatory domain. This needs to be researched and done for the rest of the regulatory domains, but this should at least unblock some more ath10k testing.
2019-09-05 15:55:24 +00:00
<netband mode="11ac">
<band>
<freqband ref="AC1_5180_5240_20"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_VHT20</flags>
</band>
<band>
<freqband ref="AC1_5180_5240_40"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT40</flags>
</band>
<band>
<freqband ref="AC1_5180_5240_80"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT80</flags>
</band>
<band>
<freqband ref="AC1_5745_5805_20"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_VHT20</flags>
</band>
<band>
<freqband ref="AC1_5745_5805_40"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT40</flags>
</band>
<band>
<freqband ref="AC1_5745_5805_80"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT80</flags>
</band>
</netband>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</rd>
<!-- FCC3 is FCC w/ DFS on Upper-UNI -->
<rd id="fcc3">
<name>FCC3</name>
<sku>0x3a</sku>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
</band>
Import one of the two missing US FCC DFS bands to FCC3. The FCC opened up this band sometime in 2009 (and ath was updated); but regdomain.xml wasn't updated.
2011-06-24 12:30:43 +00:00
<band>
<freqband ref="F1_5260_5320"/>
I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna gain; I believe net80211 doesn't take antenna gain into account and leaves it up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
<maxpower>23</maxpower>
Import one of the two missing US FCC DFS bands to FCC3. The FCC opened up this band sometime in 2009 (and ath was updated); but regdomain.xml wasn't updated.
2011-06-24 12:30:43 +00:00
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<band>
<freqband ref="F1_5500_5580"/>
I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna gain; I believe net80211 doesn't take antenna gain into account and leaves it up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
<maxpower>23</maxpower>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5660_5700"/>
I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna gain; I believe net80211 doesn't take antenna gain into account and leaves it up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
<maxpower>23</maxpower>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5825_5825"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
Import one of the two missing US FCC DFS bands to FCC3. The FCC opened up this band sometime in 2009 (and ath was updated); but regdomain.xml wasn't updated.
2011-06-24 12:30:43 +00:00
<band>
<freqband ref="F1_5260_5320"/>
I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna gain; I believe net80211 doesn't take antenna gain into account and leaves it up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
<maxpower>23</maxpower>
Import one of the two missing US FCC DFS bands to FCC3. The FCC opened up this band sometime in 2009 (and ath was updated); but regdomain.xml wasn't updated.
2011-06-24 12:30:43 +00:00
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5260_5320"/>
I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna gain; I believe net80211 doesn't take antenna gain into account and leaves it up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
<maxpower>23</maxpower>
Import one of the two missing US FCC DFS bands to FCC3. The FCC opened up this band sometime in 2009 (and ath was updated); but regdomain.xml wasn't updated.
2011-06-24 12:30:43 +00:00
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<band>
<freqband ref="F1_5500_5580"/>
I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna gain; I believe net80211 doesn't take antenna gain into account and leaves it up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
<maxpower>23</maxpower>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5500_5580"/>
I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna gain; I believe net80211 doesn't take antenna gain into account and leaves it up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
<maxpower>23</maxpower>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5660_5700"/>
I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna gain; I believe net80211 doesn't take antenna gain into account and leaves it up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
<maxpower>23</maxpower>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5660_5700"/>
I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max antenna gain; I believe net80211 doesn't take antenna gain into account and leaves it up to the driver to enforce. (ath_hal(4) certainly tries to do this.)
2011-06-26 10:34:01 +00:00
<maxpower>23</maxpower>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
</netband>
</rd>
add FCC4 SKU to expose Public Safety Band (PSB) frequencies; this is modeled after the Atheros SKU of the same name
2009-01-16 20:40:50 +00:00
<!-- FCC4 is 2.4GHz FCC w/ Public Safety Band (PSB) -->
<rd id="fcc4">
<name>FCC4</name>
<sku>0x12</sku>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_4950_4980"/>
<maxpower>23</maxpower>
</band>
<band>
<freqband ref="F1_4945_4985_10"/>
<maxpower>27</maxpower>
</band>
<band>
<freqband ref="F1_4942_4987_5"/>
<maxpower>30</maxpower>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
Fix another broken HT40 channel band reference.
2011-06-24 14:31:30 +00:00
<freqband ref="H4_2412_2462"/>
add FCC4 SKU to expose Public Safety Band (PSB) frequencies; this is modeled after the Atheros SKU of the same name
2009-01-16 20:40:50 +00:00
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
</rd>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<rd id="japan">
<name>JAPAN</name>
<sku>0x40</sku>
<defcc ref="JP"/>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
<band>
<freqband ref="F1_2484_2484"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
Japan regulatory domain update #1 - sync with CRDA entries. Specifics: * add 4920MHz-4980MHz for 11a and 11n/HT20 * add 5040MHz-5080MHz for 11a and 11n/HT20 * add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed) * add 5500MHz-5680MHz for 11n/HT40 (DFS needed) TODO: * add correct HT40 bands for 4920-4980 and 5040-5080 For the curious: There's been many revisions to the Japan regulatory rules. Apparently, the requirements require old cards certified on a previous version of the rules to obey the older rules, not the newer rules. The regdomain.xml outlines the -current- restrictions. The card driver (eg the ath_hal regulatory domain code) may include previous revisions of the Japan rules. The ath_hal regdomain code populates the initial channel list based on what the EEPROM indicates is possible. The regdomain.xml database imposes further restrictions on this. So regdomain.xml only needs to have the -current- rules. If the card was certified on an earlier set of JP rules, it may only support a subset of those channels - these are calculated at device attach and this restricted list is kicked to net80211. regdomain.xml operates on -this- list of channels. And thus, the correct regulatory behaviour for Japan is handled with only one regdomain.xml Japan database entry. (phew.) Obtained from: Linux wireless-regdb
2011-07-14 05:19:28 +00:00
<band>
<freqband ref="F1_4920_4980"/>
<maxpower>23</maxpower>
</band>
<band>
<freqband ref="F1_5040_5080"/>
<maxpower>23</maxpower>
</band>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>23</maxpower>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
Japan regulatory domain update #1 - sync with CRDA entries. Specifics: * add 4920MHz-4980MHz for 11a and 11n/HT20 * add 5040MHz-5080MHz for 11a and 11n/HT20 * add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed) * add 5500MHz-5680MHz for 11n/HT40 (DFS needed) TODO: * add correct HT40 bands for 4920-4980 and 5040-5080 For the curious: There's been many revisions to the Japan regulatory rules. Apparently, the requirements require old cards certified on a previous version of the rules to obey the older rules, not the newer rules. The regdomain.xml outlines the -current- restrictions. The card driver (eg the ath_hal regulatory domain code) may include previous revisions of the Japan rules. The ath_hal regdomain code populates the initial channel list based on what the EEPROM indicates is possible. The regdomain.xml database imposes further restrictions on this. So regdomain.xml only needs to have the -current- rules. If the card was certified on an earlier set of JP rules, it may only support a subset of those channels - these are calculated at device attach and this restricted list is kicked to net80211. regdomain.xml operates on -this- list of channels. And thus, the correct regulatory behaviour for Japan is handled with only one regdomain.xml Japan database entry. (phew.) Obtained from: Linux wireless-regdb
2011-07-14 05:19:28 +00:00
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_2412_2472"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
<netband mode="11na">
Japan regulatory domain update #1 - sync with CRDA entries. Specifics: * add 4920MHz-4980MHz for 11a and 11n/HT20 * add 5040MHz-5080MHz for 11a and 11n/HT20 * add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed) * add 5500MHz-5680MHz for 11n/HT40 (DFS needed) TODO: * add correct HT40 bands for 4920-4980 and 5040-5080 For the curious: There's been many revisions to the Japan regulatory rules. Apparently, the requirements require old cards certified on a previous version of the rules to obey the older rules, not the newer rules. The regdomain.xml outlines the -current- restrictions. The card driver (eg the ath_hal regulatory domain code) may include previous revisions of the Japan rules. The ath_hal regdomain code populates the initial channel list based on what the EEPROM indicates is possible. The regdomain.xml database imposes further restrictions on this. So regdomain.xml only needs to have the -current- rules. If the card was certified on an earlier set of JP rules, it may only support a subset of those channels - these are calculated at device attach and this restricted list is kicked to net80211. regdomain.xml operates on -this- list of channels. And thus, the correct regulatory behaviour for Japan is handled with only one regdomain.xml Japan database entry. (phew.) Obtained from: Linux wireless-regdb
2011-07-14 05:19:28 +00:00
<band>
<freqband ref="F1_4920_4980"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
More Japan regulatory domain fixes: * Add HT40 entries for the two new Japan bands * Fix a channel separation bug in one of the new bands I introduced in a previous commit.
2011-07-14 05:49:35 +00:00
<band>
<freqband ref="H4_4920_4980"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
Japan regulatory domain update #1 - sync with CRDA entries. Specifics: * add 4920MHz-4980MHz for 11a and 11n/HT20 * add 5040MHz-5080MHz for 11a and 11n/HT20 * add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed) * add 5500MHz-5680MHz for 11n/HT40 (DFS needed) TODO: * add correct HT40 bands for 4920-4980 and 5040-5080 For the curious: There's been many revisions to the Japan regulatory rules. Apparently, the requirements require old cards certified on a previous version of the rules to obey the older rules, not the newer rules. The regdomain.xml outlines the -current- restrictions. The card driver (eg the ath_hal regulatory domain code) may include previous revisions of the Japan rules. The ath_hal regdomain code populates the initial channel list based on what the EEPROM indicates is possible. The regdomain.xml database imposes further restrictions on this. So regdomain.xml only needs to have the -current- rules. If the card was certified on an earlier set of JP rules, it may only support a subset of those channels - these are calculated at device attach and this restricted list is kicked to net80211. regdomain.xml operates on -this- list of channels. And thus, the correct regulatory behaviour for Japan is handled with only one regdomain.xml Japan database entry. (phew.) Obtained from: Linux wireless-regdb
2011-07-14 05:19:28 +00:00
<band>
<freqband ref="F1_5040_5080"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
More Japan regulatory domain fixes: * Add HT40 entries for the two new Japan bands * Fix a channel separation bug in one of the new bands I introduced in a previous commit.
2011-07-14 05:49:35 +00:00
<band>
<freqband ref="H4_5040_5080"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5180_5240"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
Japan regulatory domain update #1 - sync with CRDA entries. Specifics: * add 4920MHz-4980MHz for 11a and 11n/HT20 * add 5040MHz-5080MHz for 11a and 11n/HT20 * add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed) * add 5500MHz-5680MHz for 11n/HT40 (DFS needed) TODO: * add correct HT40 bands for 4920-4980 and 5040-5080 For the curious: There's been many revisions to the Japan regulatory rules. Apparently, the requirements require old cards certified on a previous version of the rules to obey the older rules, not the newer rules. The regdomain.xml outlines the -current- restrictions. The card driver (eg the ath_hal regulatory domain code) may include previous revisions of the Japan rules. The ath_hal regdomain code populates the initial channel list based on what the EEPROM indicates is possible. The regdomain.xml database imposes further restrictions on this. So regdomain.xml only needs to have the -current- rules. If the card was certified on an earlier set of JP rules, it may only support a subset of those channels - these are calculated at device attach and this restricted list is kicked to net80211. regdomain.xml operates on -this- list of channels. And thus, the correct regulatory behaviour for Japan is handled with only one regdomain.xml Japan database entry. (phew.) Obtained from: Linux wireless-regdb
2011-07-14 05:19:28 +00:00
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5500_5680"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</netband>
</rd>
<rd id="etsi">
<name>ETSI</name>
<sku>0x30</sku>
<netband mode="11b">
<band>
Replace tab with 8 spaces, bringing it in line with the rest of the file.
2011-06-26 09:32:46 +00:00
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5260_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5500_5680"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
</netband>
lib80211: Start adding 11ac ETSI bits to regdomain.xml Summary: This change currently (partially) duplicates AC1 freqbands as AC2 as they are not fully overlapping. It then adds the 11ac netband to the "etsi" domain including "indoor" and "dfs" flags, which we can deal with, as well as appropriate (round down) maxpower values. Comments are left for the actual frequency bands as we do use the centerfreq for the first/last (chansep sized) channel in the freqband and their "id" name, which can be confusing. Sponsored-by: Rubicon Communications, LLC ("Netgate") Reviewed-by: philip, adrian MFC-after: 2 weeks Differential Revision: https://reviews.freebsd.org/D25999
2021-03-18 11:08:47 +00:00
<netband mode="11ac">
<!-- 5150-5250/80, 200 mW, indoor -->
<band>
<freqband ref="AC2_5160_5240_20"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_VHT20</flags>
<flags>INDOOR</flags>
</band>
<band>
<freqband ref="AC2_5180_5240_40"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT40</flags>
<flags>INDOOR</flags>
</band>
<band>
<freqband ref="AC2_5180_5240_80"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT80</flags>
<flags>INDOOR</flags>
</band>
<!-- 5250-5350/80, 100 mW, indoor, DFS -->
<band>
<freqband ref="AC2_5260_5340_20"/>
<maxpower>20</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_VHT20</flags>
<flags>IEEE80211_CHAN_DFS</flags>
<flags>INDOOR</flags>
</band>
<band>
<freqband ref="AC2_5260_5320_40"/>
<maxpower>20</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT40</flags>
<flags>IEEE80211_CHAN_DFS</flags>
<flags>INDOOR</flags>
</band>
<band>
<freqband ref="AC2_5260_5320_80"/>
<maxpower>20</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT80</flags>
<flags>IEEE80211_CHAN_DFS</flags>
<flags>INDOOR</flags>
</band>
<!-- 5470-5725/160, 500 mW, DFS -->
<band>
<freqband ref="AC2_5480_5700_20"/>
<maxpower>26</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_VHT20</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="AC2_5500_5680_40"/>
<maxpower>26</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT40</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="AC2_5500_5640_80"/>
<maxpower>26</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT80</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="AC2_5500_5640_160"/>
<maxpower>26</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT160</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<!-- 5725-5875/80, 25 mW "short range" -->
<band>
<freqband ref="AC2_5745_5865_20"/>
<maxpower>13</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_VHT20</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="AC2_5745_5805_40"/>
<maxpower>13</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT40</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="AC2_5745_5805_80"/>
<maxpower>13</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_VHT80</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
</netband>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</rd>
lib80211: Start adding 11ac ETSI bits to regdomain.xml Summary: This change currently (partially) duplicates AC1 freqbands as AC2 as they are not fully overlapping. It then adds the 11ac netband to the "etsi" domain including "indoor" and "dfs" flags, which we can deal with, as well as appropriate (round down) maxpower values. Comments are left for the actual frequency bands as we do use the centerfreq for the first/last (chansep sized) channel in the freqband and their "id" name, which can be confusing. Sponsored-by: Rubicon Communications, LLC ("Netgate") Reviewed-by: philip, adrian MFC-after: 2 weeks Differential Revision: https://reviews.freebsd.org/D25999
2021-03-18 11:08:47 +00:00
<!-- ETSI w/o HT40/VHT in 5GHz -->
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<rd id="etsi2">
<name>ETSI2</name>
<sku>0x32</sku>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5120_5240"/>
<maxpower>17</maxpower>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5120_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
</netband>
</rd>
<!-- ETSI - channel 36 -->
<rd id="etsi3">
<name>ETSI3</name>
<sku>0x33</sku>
<defcc ref="RO"/>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5200_5240"/>
<maxpower>17</maxpower>
</band>
<band>
<freqband ref="F1_5280_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5200_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5200_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
<band>
<freqband ref="F1_5280_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5280_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5500_5680"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
</netband>
</rd>
<rd id="apac">
<name>APAC</name>
<sku>0x50</sku>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
</band>
<band>
<freqband ref="F1_5825_5825"/>
<maxpower>23</maxpower>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="H4_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
</rd>
<!-- APAC w/ DFS on Mid-band -->
<rd id="apac2">
<name>APAC2</name>
<sku>0x51</sku>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5120_5240"/>
<maxpower>17</maxpower>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
</band>
<band>
<freqband ref="F1_5825_5825"/>
<maxpower>23</maxpower>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5120_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5120_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="H4_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
</rd>
<!-- APAC w/o ISM band -->
<rd id="apac3">
<name>APAC3</name>
<sku>0x5d</sku>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
<flags>IEEE80211_CHAN_DFS</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="H4_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
</rd>
<rd id="korea">
<name>KOREA</name>
<sku>0x45</sku>
<defcc ref="KR"/>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
<band>
<freqband ref="F1_2467_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
<freqband ref="F1_2467_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5500_5620"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="F1_2467_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5180_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5500_5620"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
</rd>
<!-- Rest Of World -->
<rd id="row">
<name>ROW</name>
<sku>0x8a</sku>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="H4_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
</rd>
<rd id="none">
<name>NONE</name>
<sku>0xf0</sku>
<netband mode="11b">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
</band>
<band>
<freqband ref="F1_2467_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_B</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11g">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
<freqband ref="F1_2467_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11a">
<band>
<freqband ref="F1_5120_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5825_5825"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11ng">
<band>
<freqband ref="F1_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
</band>
<band>
<freqband ref="H4_2412_2462"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
</band>
<band>
<freqband ref="F1_2467_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="H4_2467_2472"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
<netband mode="11na">
<band>
<freqband ref="F1_5120_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="H4_5120_5240"/>
<maxpower>17</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5260_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="H4_5260_5320"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5500_5700"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="H4_5500_5680"/>
<maxpower>24</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="H4_5745_5805"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="F1_5825_5825"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT20</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
<band>
<freqband ref="H4_5825_5825"/>
<maxpower>23</maxpower>
<flags>IEEE80211_CHAN_HT40</flags>
<flags>IEEE80211_CHAN_PASSIVE</flags>
</band>
</netband>
</rd>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<rd id="sr9">
<name>SR9</name>
<sku>0x0298</sku>
<netband mode="11g">
<band>
<freqband ref="S1_907_922_5"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
<freqband ref="S1_907_922_10"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
<freqband ref="S1_912_917"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
</rd>
<rd id="xr9">
<name>XR9</name>
<sku>0x299</sku>
<netband mode="11g">
<band>
Remove gsm hacks now that we can do this "right": o no need for special country codes; it's sufficient to use the sku o no need to specify bands w/ 2.4G frequencies, use the real values o remove duplicate band specs
2009-01-28 19:25:51 +00:00
<freqband ref="S1_907_922_5"/>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
Remove gsm hacks now that we can do this "right": o no need for special country codes; it's sufficient to use the sku o no need to specify bands w/ 2.4G frequencies, use the real values o remove duplicate band specs
2009-01-28 19:25:51 +00:00
<freqband ref="S1_907_922_10"/>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
Remove gsm hacks now that we can do this "right": o no need for special country codes; it's sufficient to use the sku o no need to specify bands w/ 2.4G frequencies, use the real values o remove duplicate band specs
2009-01-28 19:25:51 +00:00
<freqband ref="S1_912_917"/>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
</rd>
<rd id="gz901">
<name>GZ901</name>
<sku>0x29a</sku>
<netband mode="11g">
<band>
<freqband ref="S1_908_923_5"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
<freqband ref="S1_913_918_10"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
<freqband ref="S1_913_918"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
</rd>
Add a new 900MHz GSM regulatory SKU for the Xagyl Communications XC900M. The XC900M acts as a Ubiquiti XR9 (and I _think_ SR9) by default; it uses the same 900MHz<->2.4GHz downconverter mapping. However it has an alternative frequency mapping which squeezes in a couple more half/quarter rate channels. Since the default HAL doesn't support fractional tuning (sub-1MHz) in 2.4GHz mode on the AR5413/AR5414, they implement it using a jumper. Datasheet: http://www.xagyl.com/download/XC900M_Datasheet.pdf Thankyou to Xagyl Communications for the XC900M NICs and Edgar Martinez for organising the donation. Tested: * XC900M <-> XC900M * Ubiquiti XR9 <-> XC900M TODO: * Test against SR9 and GZ901 if possible (the IEEE channel<->frequency mapping may not match up, thanks to the slightly different channels involved)
2012-12-07 06:34:46 +00:00
<rd id="xc900m">
<name>XC900M</name>
<sku>0x29b</sku>
<netband mode="11g">
<band>
<freqband ref="S1_905_925_5"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
<freqband ref="S1_910_920_10"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
<band>
<freqband ref="S1_915_915"/>
<maxpower>30</maxpower>
<flags>IEEE80211_CHAN_G</flags>
</band>
</netband>
</rd>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</regulatory-domains>
<country-codes>
<!--
ISO 3166 Country/Region codes and regdomain mapping.
Remove trailing white space. No functional changes.
2010-05-14 04:53:57 +00:00
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt
has the list of codes.
XXX this table is incomplete
-->
<country id="AL">
<isocc>8</isocc> <name>Albania</name> <rd ref="none"/>
</country>
<country id="DZ">
<isocc>12</isocc> <name>Algeria</name> <rd ref="none"/>
</country>
<country id="AR">
<isocc>32</isocc> <name>Argentina</name> <rd ref="none"/>
</country>
<country id="AM">
<isocc>51</isocc> <name>Armenia</name> <rd ref="etsi"/>
</country>
<country id="AU">
<isocc>36</isocc> <name>Australia</name> <rd ref="row"/>
</country>
<country id="AT">
<isocc>40</isocc> <name>Austria</name> <rd ref="etsi2"/>
</country>
<country id="AZ">
<isocc>31</isocc> <name>Azerbaijan</name> <rd ref="etsi"/>
</country>
<country id="BH">
<isocc>48</isocc> <name>Bahrain</name> <rd ref="none"/>
</country>
<country id="BD">
<isocc>50</isocc> <name>Bangladesh</name> <rd ref="row"/>
</country>
<country id="BY">
<isocc>112</isocc> <name>Belarus</name> <rd ref="none"/>
</country>
<country id="BE">
<isocc>56</isocc> <name>Belgium</name> <rd ref="etsi"/>
</country>
<country id="BZ">
<isocc>84</isocc> <name>Belize</name> <rd ref="none"/>
</country>
<country id="BO">
<isocc>68</isocc> <name>Bolivia</name> <rd ref="none"/>
</country>
<country id="BR">
<isocc>76</isocc> <name>Brazil</name> <rd ref="fcc"/>
</country>
<country id="BN">
<isocc>96</isocc> <name>Brunei</name> <rd ref="apac"/>
</country>
<country id="BG">
<isocc>100</isocc> <name>Bulgaria</name> <rd ref="etsi"/>
</country>
<country id="CA">
<isocc>124</isocc> <name>Canada</name> <rd ref="fcc"/>
</country>
<country id="CL">
<isocc>152</isocc> <name>Chile</name> <rd ref="row"/>
</country>
<country id="CN">
<isocc>156</isocc> <name>China</name> <rd ref="row"/>
</country>
<country id="CO">
<isocc>170</isocc> <name>Colombia</name> <rd ref="fcc"/>
</country>
<country id="CR">
<isocc>188</isocc> <name>Costa Rica</name> <rd ref="none"/>
</country>
<country id="HR">
<isocc>191</isocc> <name>Croatia</name> <rd ref="etsi"/>
</country>
<country id="CY">
<isocc>196</isocc> <name>Cyprus</name> <rd ref="etsi"/>
</country>
<country id="CZ">
<isocc>203</isocc> <name>Czech Republic</name> <rd ref="etsi"/>
</country>
<country id="DK">
<isocc>208</isocc> <name>Denmark</name> <rd ref="etsi"/>
</country>
<country id="DO">
<isocc>214</isocc> <name>Dominican Republic</name> <rd ref="none"/>
</country>
<country id="EC">
<isocc>218</isocc> <name>Ecuador</name> <rd ref="none"/>
</country>
<country id="EG">
<isocc>818</isocc> <name>Egypt</name> <rd ref="none"/>
</country>
<country id="SV">
<isocc>222</isocc> <name>El Salvador</name> <rd ref="none"/>
Remove trailing white space. No functional changes.
2010-05-14 04:53:57 +00:00
</country>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<country id="EE">
<isocc>233</isocc> <name>Estonia</name> <rd ref="etsi"/>
</country>
<country id="FI">
<isocc>246</isocc> <name>Finland</name> <rd ref="etsi"/>
</country>
<country id="FR">
<isocc>250</isocc> <name>France</name> <rd ref="etsi"/>
</country>
<country id="F2">
<isocc>255</isocc> <name>France2</name> <rd ref="etsi"/>
</country>
<country id="GE">
<isocc>268</isocc> <name>Georgia</name> <rd ref="etsi"/>
</country>
<country id="DE">
<isocc>276</isocc> <name>Germany</name> <rd ref="etsi"/>
</country>
<country id="GR">
<isocc>300</isocc> <name>Greece</name> <rd ref="etsi"/>
</country>
<country id="GT">
<isocc>320</isocc> <name>Guatemala</name> <rd ref="none"/>
</country>
<country id="HN">
<isocc>340</isocc> <name>Honduras</name> <rd ref="none"/>
</country>
<country id="HK">
<isocc>344</isocc> <name>Hong Kong</name> <rd ref="apac"/>
</country>
<country id="HU">
<isocc>348</isocc> <name>Hungary</name> <rd ref="etsi"/>
</country>
<country id="IS">
<isocc>352</isocc> <name>Iceland</name> <rd ref="etsi"/>
</country>
<country id="IN">
<isocc>356</isocc> <name>India</name> <rd ref="apac"/>
</country>
<country id="ID">
<isocc>360</isocc> <name>Indonesia</name> <rd ref="none"/>
</country>
<country id="IR">
<isocc>364</isocc> <name>Iran</name> <rd ref="none"/>
</country>
<country id="IE">
<isocc>372</isocc> <name>Ireland</name> <rd ref="etsi"/>
</country>
<country id="IL">
<isocc>376</isocc> <name>Israel</name> <rd ref="none"/>
</country>
<country id="IT">
<isocc>380</isocc> <name>Italy</name> <rd ref="etsi"/>
</country>
<country id="JM">
<isocc>388</isocc> <name>Jamaica</name> <rd ref="none"/>
</country>
<country id="JP">
<isocc>392</isocc> <name>Japan</name> <rd ref="japan"/>
</country>
<country id="J1">
<isocc>393</isocc> <name>Japan1</name> <rd ref="japan"/>
</country>
<country id="J2">
<isocc>394</isocc> <name>Japan2</name> <rd ref="japan"/>
Remove trailing white space. No functional changes.
2010-05-14 04:53:57 +00:00
</country>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<country id="J3">
<isocc>395</isocc> <name>Japan3</name> <rd ref="japan"/>
</country>
<country id="J4">
<isocc>396</isocc> <name>Japan4</name> <rd ref="japan"/>
</country>
<country id="J5">
<isocc>397</isocc> <name>Japan5</name> <rd ref="japan"/>
Remove trailing white space. No functional changes.
2010-05-14 04:53:57 +00:00
</country>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<country id="JO">
<isocc>400</isocc> <name>Jordan</name> <rd ref="none"/>
</country>
<country id="KZ">
<isocc>398</isocc> <name>Kazakhstan</name> <rd ref="none"/>
</country>
<country id="KP">
<isocc>408</isocc> <name>North Korea</name> <rd ref="korea"/>
</country>
<country id="KR">
<isocc>410</isocc> <name>Korea Republic</name> <rd ref="korea"/>
</country>
<country id="K2">
<isocc>411</isocc> <name>Korea Republic2</name> <rd ref="none"/>
</country>
<country id="KW">
<isocc>414</isocc> <name>Kuwait</name> <rd ref="none"/>
</country>
<country id="LV">
<isocc>428</isocc> <name>Latvia</name> <rd ref="etsi2"/>
</country>
<country id="LB">
<isocc>422</isocc> <name>Lebanon</name> <rd ref="none"/>
</country>
<country id="LI">
<isocc>438</isocc> <name>Liechtenstein</name> <rd ref="etsi"/>
</country>
<country id="LT">
<isocc>440</isocc> <name>Lithuania</name> <rd ref="etsi"/>
</country>
<country id="LU">
<isocc>442</isocc> <name>Luxemborg</name> <rd ref="etsi"/>
</country>
<country id="MO">
<isocc>446</isocc> <name>Macau</name> <rd ref="none"/>
</country>
<country id="MK">
<isocc>807</isocc> <name>Macedonia</name> <rd ref="none"/>
</country>
<country id="MY">
<isocc>458</isocc> <name>Malaysia</name> <rd ref="apac3"/>
</country>
<country id="MT">
<isocc>470</isocc> <name>Malta</name> <rd ref="etsi"/>
</country>
<country id="MX">
<isocc>484</isocc> <name>Mexico</name> <rd ref="fcc"/>
</country>
<country id="MC">
<isocc>492</isocc> <name>Monaco</name> <rd ref="none"/>
</country>
<country id="MA">
<isocc>504</isocc> <name>Morocco</name> <rd ref="etsi"/>
</country>
<country id="NP">
<isocc>524</isocc> <name>Nepal</name> <rd ref="row"/>
</country>
<country id="NL">
<isocc>528</isocc> <name>Netherlands</name> <rd ref="etsi"/>
</country>
<country id="NZ">
<isocc>554</isocc> <name>New Zealand</name> <rd ref="apac"/>
</country>
<country id="NO">
<isocc>578</isocc> <name>Norway</name> <rd ref="etsi"/>
</country>
<country id="OM">
<isocc>512</isocc> <name>Oman</name> <rd ref="none"/>
</country>
<country id="PK">
<isocc>586</isocc> <name>Pakistan</name> <rd ref="row"/>
</country>
<country id="PA">
<isocc>591</isocc> <name>Panama</name> <rd ref="none"/>
</country>
<country id="PE">
<isocc>604</isocc> <name>Peru</name> <rd ref="none"/>
</country>
<country id="PH">
<isocc>608</isocc> <name>Phillipines</name> <rd ref="apac2"/>
</country>
<country id="PL">
<isocc>616</isocc> <name>Poland</name> <rd ref="etsi"/>
</country>
<country id="PT">
<isocc>620</isocc> <name>Portugal</name> <rd ref="etsi"/>
</country>
<country id="PR">
<isocc>630</isocc> <name>Puerto Rico</name> <rd ref="fcc"/>
</country>
<country id="QA">
<isocc>634</isocc> <name>Quatar</name> <rd ref="none"/>
</country>
<country id="RO">
<isocc>642</isocc> <name>Romania</name> <rd ref="etsi"/>
</country>
<country id="RU">
Correct Russia spelling in regdomain.xml PR: 225658 MFC after: 1 week
2018-02-05 18:45:21 +00:00
<isocc>643</isocc> <name>Russia</name> <rd ref="none"/>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</country>
<country id="SA">
<isocc>682</isocc> <name>Saudi Arabia</name> <rd ref="none"/>
</country>
<country id="SG">
<isocc>702</isocc> <name>Singapore</name> <rd ref="apac2"/>
</country>
<country id="SK">
<isocc>703</isocc> <name>Slovak Republic</name> <rd ref="etsi2"/>
</country>
<country id="SI">
<isocc>705</isocc> <name>Slovenia</name> <rd ref="etsi"/>
</country>
<country id="ZA">
<isocc>710</isocc> <name>South Africa</name> <rd ref="none"/>
</country>
<country id="ES">
<isocc>724</isocc> <name>Spain</name> <rd ref="etsi2"/>
</country>
<country id="LK">
<isocc>144</isocc> <name>Sri Lanka</name> <rd ref="apac2"/>
</country>
<country id="SE">
<isocc>752</isocc> <name>Sweden</name> <rd ref="etsi"/>
</country>
<country id="CH">
<isocc>756</isocc> <name>Switzerland</name> <rd ref="etsi"/>
</country>
<country id="SY">
<isocc>760</isocc> <name>Syria</name> <rd ref="none"/>
</country>
<country id="TW">
<isocc>158</isocc> <name>Taiwan</name> <rd ref="row"/>
</country>
<country id="TH">
<isocc>764</isocc> <name>Thailand</name> <rd ref="none"/>
</country>
<country id="TT">
<isocc>780</isocc> <name>Tobago</name> <rd ref="none"/>
</country>
<country id="TN">
<isocc>788</isocc> <name>Tunisia</name> <rd ref="none"/>
</country>
<country id="TR">
<isocc>792</isocc> <name>Turkey</name> <rd ref="etsi"/>
</country>
<country id="UA">
<isocc>804</isocc> <name>Ukraine</name> <rd ref="none"/>
</country>
<country id="AE">
<isocc>784</isocc> <name>United Arab Emirates</name> <rd ref="none"/>
</country>
<country id="GB">
<isocc>826</isocc> <name>United Kingdom</name> <rd ref="etsi"/>
</country>
<country id="US">
<isocc>840</isocc> <name>United States</name> <rd ref="fcc"/>
</country>
<country id="UY">
<isocc>858</isocc> <name>Uruguay</name> <rd ref="none"/>
</country>
<country id="UZ">
<isocc>860</isocc> <name>Uzbekistan</name> <rd ref="none"/>
Remove trailing white space. No functional changes.
2010-05-14 04:53:57 +00:00
</country>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<country id="VE">
<isocc>862</isocc> <name>Venezuela</name> <rd ref="fcc"/>
</country>
<country id="VN">
<isocc>704</isocc> <name>Viet Nam</name> <rd ref="apac2"/>
</country>
<country id="YE">
<isocc>887</isocc> <name>Yemen</name> <rd ref="none"/>
</country>
<country id="ZW">
<isocc>716</isocc> <name>Zimbabwe</name> <rd ref="none"/>
</country>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<country id="DEBUG">
<isocc>0</isocc> <name>Debug</name> <rd ref="debug"/>
</country>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</country-codes>
<!--
Band specifications referenced above.
Remove trailing white space. No functional changes.
2010-05-14 04:53:57 +00:00
NB: keep sorted by starting frequency, legacy before HT
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
-->
<shared-frequency-bands>
add FCC4 SKU to expose Public Safety Band (PSB) frequencies; this is modeled after the Atheros SKU of the same name
2009-01-16 20:40:50 +00:00
<freqband id="F1_4942_4987_5">
<freqstart>4942</freqstart> <freqend>4987</freqend>
<chanwidth>5</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_A</flags>
<flags>IEEE80211_CHAN_QUARTER</flags>
</freqband>
<freqband id="F1_4945_4985_10">
<freqstart>4945</freqstart> <freqend>4985</freqend>
<chanwidth>10</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_A</flags>
<flags>IEEE80211_CHAN_HALF</flags>
</freqband>
Japan regulatory domain update #1 - sync with CRDA entries. Specifics: * add 4920MHz-4980MHz for 11a and 11n/HT20 * add 5040MHz-5080MHz for 11a and 11n/HT20 * add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed) * add 5500MHz-5680MHz for 11n/HT40 (DFS needed) TODO: * add correct HT40 bands for 4920-4980 and 5040-5080 For the curious: There's been many revisions to the Japan regulatory rules. Apparently, the requirements require old cards certified on a previous version of the rules to obey the older rules, not the newer rules. The regdomain.xml outlines the -current- restrictions. The card driver (eg the ath_hal regulatory domain code) may include previous revisions of the Japan rules. The ath_hal regdomain code populates the initial channel list based on what the EEPROM indicates is possible. The regdomain.xml database imposes further restrictions on this. So regdomain.xml only needs to have the -current- rules. If the card was certified on an earlier set of JP rules, it may only support a subset of those channels - these are calculated at device attach and this restricted list is kicked to net80211. regdomain.xml operates on -this- list of channels. And thus, the correct regulatory behaviour for Japan is handled with only one regdomain.xml Japan database entry. (phew.) Obtained from: Linux wireless-regdb
2011-07-14 05:19:28 +00:00
<freqband id="F1_4920_4980">
<freqstart>4920</freqstart> <freqend>4980</freqend>
More Japan regulatory domain fixes: * Add HT40 entries for the two new Japan bands * Fix a channel separation bug in one of the new bands I introduced in a previous commit.
2011-07-14 05:49:35 +00:00
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_4920_4980">
<freqstart>4920</freqstart> <freqend>4980</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
Japan regulatory domain update #1 - sync with CRDA entries. Specifics: * add 4920MHz-4980MHz for 11a and 11n/HT20 * add 5040MHz-5080MHz for 11a and 11n/HT20 * add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed) * add 5500MHz-5680MHz for 11n/HT40 (DFS needed) TODO: * add correct HT40 bands for 4920-4980 and 5040-5080 For the curious: There's been many revisions to the Japan regulatory rules. Apparently, the requirements require old cards certified on a previous version of the rules to obey the older rules, not the newer rules. The regdomain.xml outlines the -current- restrictions. The card driver (eg the ath_hal regulatory domain code) may include previous revisions of the Japan rules. The ath_hal regdomain code populates the initial channel list based on what the EEPROM indicates is possible. The regdomain.xml database imposes further restrictions on this. So regdomain.xml only needs to have the -current- rules. If the card was certified on an earlier set of JP rules, it may only support a subset of those channels - these are calculated at device attach and this restricted list is kicked to net80211. regdomain.xml operates on -this- list of channels. And thus, the correct regulatory behaviour for Japan is handled with only one regdomain.xml Japan database entry. (phew.) Obtained from: Linux wireless-regdb
2011-07-14 05:19:28 +00:00
<flags>IEEE80211_CHAN_A</flags>
</freqband>
add FCC4 SKU to expose Public Safety Band (PSB) frequencies; this is modeled after the Atheros SKU of the same name
2009-01-16 20:40:50 +00:00
<freqband id="F1_4950_4980">
<freqstart>4950</freqstart> <freqend>4980</freqend>
<chanwidth>20</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
Japan regulatory domain update #1 - sync with CRDA entries. Specifics: * add 4920MHz-4980MHz for 11a and 11n/HT20 * add 5040MHz-5080MHz for 11a and 11n/HT20 * add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed) * add 5500MHz-5680MHz for 11n/HT40 (DFS needed) TODO: * add correct HT40 bands for 4920-4980 and 5040-5080 For the curious: There's been many revisions to the Japan regulatory rules. Apparently, the requirements require old cards certified on a previous version of the rules to obey the older rules, not the newer rules. The regdomain.xml outlines the -current- restrictions. The card driver (eg the ath_hal regulatory domain code) may include previous revisions of the Japan rules. The ath_hal regdomain code populates the initial channel list based on what the EEPROM indicates is possible. The regdomain.xml database imposes further restrictions on this. So regdomain.xml only needs to have the -current- rules. If the card was certified on an earlier set of JP rules, it may only support a subset of those channels - these are calculated at device attach and this restricted list is kicked to net80211. regdomain.xml operates on -this- list of channels. And thus, the correct regulatory behaviour for Japan is handled with only one regdomain.xml Japan database entry. (phew.) Obtained from: Linux wireless-regdb
2011-07-14 05:19:28 +00:00
<freqband id="F1_5040_5080">
<freqstart>5040</freqstart> <freqend>5080</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
More Japan regulatory domain fixes: * Add HT40 entries for the two new Japan bands * Fix a channel separation bug in one of the new bands I introduced in a previous commit.
2011-07-14 05:49:35 +00:00
<freqband id="H4_5040_5080">
<freqstart>5040</freqstart> <freqend>5080</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<freqband id="F1_5120_5240">
<freqstart>5120</freqstart> <freqend>5240</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5120_5240">
<freqstart>5120</freqstart> <freqend>5240</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="F1_5180_5240">
<freqstart>5180</freqstart> <freqend>5240</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
[lib80211] add initial VHT (11ac) channel ranges for FCC. This is a simple set of VHT channels and flags for the FCC (US) regulatory domain. This needs to be researched and done for the rest of the regulatory domains, but this should at least unblock some more ath10k testing.
2019-09-05 15:55:24 +00:00
<freqband id="AC1_5180_5240_20">
<freqstart>5180</freqstart> <freqend>5240</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC1_5180_5240_40">
<freqstart>5180</freqstart> <freqend>5240</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC1_5180_5240_80">
<freqstart>5180</freqstart> <freqend>5240</freqend>
<chanwidth>80</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
lib80211: Start adding 11ac ETSI bits to regdomain.xml Summary: This change currently (partially) duplicates AC1 freqbands as AC2 as they are not fully overlapping. It then adds the 11ac netband to the "etsi" domain including "indoor" and "dfs" flags, which we can deal with, as well as appropriate (round down) maxpower values. Comments are left for the actual frequency bands as we do use the centerfreq for the first/last (chansep sized) channel in the freqband and their "id" name, which can be confusing. Sponsored-by: Rubicon Communications, LLC ("Netgate") Reviewed-by: philip, adrian MFC-after: 2 weeks Differential Revision: https://reviews.freebsd.org/D25999
2021-03-18 11:08:47 +00:00
<!-- 5150-5250/80 -->
<freqband id="AC2_5160_5240_20">
<freqstart>5160</freqstart> <freqend>5240</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC2_5180_5240_40">
<freqstart>5180</freqstart> <freqend>5240</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC2_5180_5240_80">
<freqstart>5180</freqstart> <freqend>5240</freqend>
<chanwidth>80</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<!-- 5250-5350/80 -->
<freqband id="AC2_5260_5340_20">
<freqstart>5260</freqstart> <freqend>5340</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC2_5260_5320_40">
<freqstart>5260</freqstart> <freqend>5320</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC2_5260_5320_80">
<freqstart>5260</freqstart> <freqend>5320</freqend>
<chanwidth>80</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<!-- 5470-5725/160 -->
<freqband id="AC2_5480_5700_20">
<freqstart>5480</freqstart> <freqend>5700</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC2_5500_5680_40">
<freqstart>5500</freqstart> <freqend>5680</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC2_5500_5640_80">
<freqstart>5500</freqstart> <freqend>5640</freqend>
<chanwidth>80</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC2_5500_5640_160">
<freqstart>5500</freqstart> <freqend>5640</freqend>
<chanwidth>160</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<!-- 5725-5875/80 short range -->
<freqband id="AC2_5745_5865_20">
<freqstart>5745</freqstart> <freqend>5865</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC2_5745_5805_40">
<freqstart>5745</freqstart> <freqend>5805</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC2_5745_5805_80">
<freqstart>5745</freqstart> <freqend>5805</freqend>
<chanwidth>80</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<freqband id="H4_5180_5240">
<freqstart>5180</freqstart> <freqend>5240</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="F1_5200_5240">
<freqstart>5200</freqstart> <freqend>5240</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5200_5240">
<freqstart>5200</freqstart> <freqend>5240</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="F1_5260_5320">
<freqstart>5260</freqstart> <freqend>5320</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5260_5320">
<freqstart>5260</freqstart> <freqend>5320</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="F1_5260_5700">
<freqstart>5260</freqstart> <freqend>5700</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="F1_5280_5320">
<freqstart>5280</freqstart> <freqend>5320</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5280_5320">
<freqstart>5280</freqstart> <freqend>5320</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<freqband id="F1_5500_5580">
<freqstart>5500</freqstart> <freqend>5580</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5500_5580">
<freqstart>5500</freqstart> <freqend>5580</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<freqband id="F1_5500_5620">
<freqstart>5500</freqstart> <freqend>5620</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5500_5620">
<freqstart>5500</freqstart> <freqend>5620</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5500_5680">
<freqstart>5500</freqstart> <freqend>5680</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="F1_5500_5700">
<freqstart>5500</freqstart> <freqend>5700</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain. The frequency range 5490MHz -> 5710MHz was opened up sometime in 2009, but regdomain.xml wasn't updated. FCC reference: (Section 15.407): http://louise.hallikainen.org/FCC/FccRules/2009/15/407/ The hole between 5600-5650MHz is due to a request from Airports using a weather radar system which also utilises this range. The GIT commit explaining this hole in more detail can be found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=commit;h=fcbf9225d56e82d9a4e506187d42285e76d81523
2011-06-26 10:32:09 +00:00
<freqband id="F1_5660_5700">
<freqstart>5660</freqstart> <freqend>5700</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5660_5700">
<freqstart>5660</freqstart> <freqend>5700</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<freqband id="H4_5725_5825">
<freqstart>5725</freqstart> <freqend>5825</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="F1_5745_5805">
<freqstart>5745</freqstart> <freqend>5805</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
[lib80211] add initial VHT (11ac) channel ranges for FCC. This is a simple set of VHT channels and flags for the FCC (US) regulatory domain. This needs to be researched and done for the rest of the regulatory domains, but this should at least unblock some more ath10k testing.
2019-09-05 15:55:24 +00:00
<freqband id="AC1_5745_5805_20">
<freqstart>5745</freqstart> <freqend>5805</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC1_5745_5805_40">
<freqstart>5745</freqstart> <freqend>5805</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="AC1_5745_5805_80">
<freqstart>5745</freqstart> <freqend>5805</freqend>
<chanwidth>80</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
<freqband id="H4_5745_5805">
<freqstart>5745</freqstart> <freqend>5805</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5745_5825">
<freqstart>5745</freqstart> <freqend>5825</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="F1_5825_5825">
<freqstart>5825</freqstart> <freqend>5825</freqend>
<chanwidth>20</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="H4_5825_5825">
<freqstart>5825</freqstart> <freqend>5825</freqend>
<chanwidth>40</chanwidth> <chansep>20</chansep>
<flags>IEEE80211_CHAN_A</flags>
</freqband>
<freqband id="F1_2312_2372">
<freqstart>2312</freqstart> <freqend>2372</freqend>
<chanwidth>20</chanwidth> <chansep>5</chansep>
</freqband>
<freqband id="F1_2412_2462">
<freqstart>2412</freqstart> <freqend>2462</freqend>
<chanwidth>20</chanwidth> <chansep>5</chansep>
</freqband>
<freqband id="H4_2412_2462">
<freqstart>2412</freqstart> <freqend>2462</freqend>
<chanwidth>40</chanwidth> <chansep>5</chansep>
</freqband>
<freqband id="F1_2412_2472">
<freqstart>2412</freqstart> <freqend>2472</freqend>
<chanwidth>20</chanwidth> <chansep>5</chansep>
</freqband>
<freqband id="H4_2412_2472">
<freqstart>2412</freqstart> <freqend>2472</freqend>
<chanwidth>40</chanwidth> <chansep>5</chansep>
</freqband>
<freqband id="F1_2467_2472">
<freqstart>2467</freqstart> <freqend>2472</freqend>
<chanwidth>20</chanwidth> <chansep>5</chansep>
</freqband>
<freqband id="H4_2467_2472">
<freqstart>2467</freqstart> <freqend>2472</freqend>
<chanwidth>40</chanwidth> <chansep>5</chansep>
</freqband>
<freqband id="F1_2484_2484">
<freqstart>2484</freqstart> <freqend>2484</freqend>
<chanwidth>20</chanwidth> <chansep>5</chansep>
</freqband>
<freqband id="F1_2512_2732">
<freqstart>2512</freqstart> <freqend>2732</freqend>
<chanwidth>20</chanwidth> <chansep>5</chansep>
</freqband>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<freqband id="S1_907_922_5">
Remove gsm hacks now that we can do this "right": o no need for special country codes; it's sufficient to use the sku o no need to specify bands w/ 2.4G frequencies, use the real values o remove duplicate band specs
2009-01-28 19:25:51 +00:00
<freqstart>907</freqstart> <freqend>922</freqend>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<chanwidth>5</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_GSM</flags>
<flags>IEEE80211_CHAN_QUARTER</flags>
</freqband>
<freqband id="S1_907_922_10">
Remove gsm hacks now that we can do this "right": o no need for special country codes; it's sufficient to use the sku o no need to specify bands w/ 2.4G frequencies, use the real values o remove duplicate band specs
2009-01-28 19:25:51 +00:00
<freqstart>907</freqstart> <freqend>922</freqend>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<chanwidth>10</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_GSM</flags>
<flags>IEEE80211_CHAN_HALF</flags>
</freqband>
<freqband id="S1_912_917">
Remove gsm hacks now that we can do this "right": o no need for special country codes; it's sufficient to use the sku o no need to specify bands w/ 2.4G frequencies, use the real values o remove duplicate band specs
2009-01-28 19:25:51 +00:00
<freqstart>912</freqstart> <freqend>917</freqend>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<chanwidth>20</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_GSM</flags>
</freqband>
<freqband id="S1_908_923_5">
Remove gsm hacks now that we can do this "right": o no need for special country codes; it's sufficient to use the sku o no need to specify bands w/ 2.4G frequencies, use the real values o remove duplicate band specs
2009-01-28 19:25:51 +00:00
<freqstart>908</freqstart> <freqend>923</freqend>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<chanwidth>5</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_GSM</flags>
<flags>IEEE80211_CHAN_QUARTER</flags>
</freqband>
<freqband id="S1_913_918_10">
Remove gsm hacks now that we can do this "right": o no need for special country codes; it's sufficient to use the sku o no need to specify bands w/ 2.4G frequencies, use the real values o remove duplicate band specs
2009-01-28 19:25:51 +00:00
<freqstart>913</freqstart> <freqend>918</freqend>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<chanwidth>10</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_GSM</flags>
<flags>IEEE80211_CHAN_HALF</flags>
</freqband>
<freqband id="S1_913_918">
Remove gsm hacks now that we can do this "right": o no need for special country codes; it's sufficient to use the sku o no need to specify bands w/ 2.4G frequencies, use the real values o remove duplicate band specs
2009-01-28 19:25:51 +00:00
<freqstart>913</freqstart> <freqend>918</freqend>
o fix DEBUG sku definition o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901
2008-12-15 01:18:11 +00:00
<chanwidth>20</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_GSM</flags>
</freqband>
Add a new 900MHz GSM regulatory SKU for the Xagyl Communications XC900M. The XC900M acts as a Ubiquiti XR9 (and I _think_ SR9) by default; it uses the same 900MHz<->2.4GHz downconverter mapping. However it has an alternative frequency mapping which squeezes in a couple more half/quarter rate channels. Since the default HAL doesn't support fractional tuning (sub-1MHz) in 2.4GHz mode on the AR5413/AR5414, they implement it using a jumper. Datasheet: http://www.xagyl.com/download/XC900M_Datasheet.pdf Thankyou to Xagyl Communications for the XC900M NICs and Edgar Martinez for organising the donation. Tested: * XC900M <-> XC900M * Ubiquiti XR9 <-> XC900M TODO: * Test against SR9 and GZ901 if possible (the IEEE channel<->frequency mapping may not match up, thanks to the slightly different channels involved)
2012-12-07 06:34:46 +00:00
<freqband id="S1_905_925_5">
<freqstart>905</freqstart> <freqend>925</freqend>
<chanwidth>5</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_GSM</flags>
<flags>IEEE80211_CHAN_QUARTER</flags>
</freqband>
<freqband id="S1_910_920_10">
<freqstart>910</freqstart> <freqend>920</freqend>
<chanwidth>10</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_GSM</flags>
<flags>IEEE80211_CHAN_HALF</flags>
</freqband>
<freqband id="S1_915_915">
<freqstart>915</freqstart> <freqend>915</freqend>
<chanwidth>20</chanwidth> <chansep>5</chansep>
<flags>IEEE80211_CHAN_GSM</flags>
</freqband>
802.11 regulatory definitions used by ifconfig Support by: Hobnob
2008-04-20 20:37:02 +00:00
</shared-frequency-bands>
</regulatory-data>
Reference in New Issue Copy Permalink