aboutsummaryrefslogtreecommitdiff
path: root/etc/regdomain.xml
Commit message (Collapse)AuthorAgeFilesLines
* Move regdomain.xml to lib/lib80211/Brad Davis2018-09-191-1943/+0
| | | | | | | | | | | This leverages CONFS to handle the install. lib80211 was picked because it is where this file is actually used from. Approved by: re (blanket, pkgbase), will (mentor) Differential Revision: https://reviews.freebsd.org/D17229 Notes: svn path=/head/; revision=338794
* Correct Russia spelling in regdomain.xmlEd Maste2018-02-051-1/+1
| | | | | | | | PR: 225658 MFC after: 1 week Notes: svn path=/head/; revision=328895
* Add a new 900MHz GSM regulatory SKU for the Xagyl Communications XC900M.Adrian Chadd2012-12-071-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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) Notes: svn path=/head/; revision=243974
* More Japan regulatory domain fixes:Adrian Chadd2011-07-141-1/+21
| | | | | | | | | * 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. Notes: svn path=/head/; revision=223998
* Japan regulatory domain update #1 - sync with CRDA entries.Adrian Chadd2011-07-141-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=223996
* I think 23dBm is the correct value to use here. CRDA uses 20dBm + 3dB max ↵Adrian Chadd2011-06-261-9/+9
| | | | | | | | | | 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.) Notes: svn path=/head/; revision=223564
* Add a couple more frequency ranges to the FCC3 (FCC + DFS) regulatory domain.Adrian Chadd2011-06-261-0/+60
| | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=223563
* Replace tab with 8 spaces, bringing it in line with the rest of the file.Adrian Chadd2011-06-261-3/+3
| | | | Notes: svn path=/head/; revision=223561
* Fix another broken HT40 channel band reference.Adrian Chadd2011-06-241-1/+1
| | | | Notes: svn path=/head/; revision=223504
* More incorrect HT/40 setups in FCC.Adrian Chadd2011-06-241-2/+2
| | | | | | | Noticed-by: bschmidt@ Notes: svn path=/head/; revision=223498
* Fix an incorrect frequency band for HT/40 in the FCC SKU.Adrian Chadd2011-06-241-1/+1
| | | | | | | Noticed by: bschmidt@ Notes: svn path=/head/; revision=223497
* Import one of the two missing US FCC DFS bands to FCC3.Adrian Chadd2011-06-241-0/+20
| | | | | | | | The FCC opened up this band sometime in 2009 (and ath was updated); but regdomain.xml wasn't updated. Notes: svn path=/head/; revision=223496
* Remove trailing white space. No functional changes.Doug Barton2010-05-141-9/+9
| | | | Notes: svn path=/head/; revision=208060
* Remove gsm hacks now that we can do this "right":Sam Leffler2009-01-281-39/+9
| | | | | | | | | 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 Notes: svn path=/head/; revision=187846
* add FCC4 SKU to expose Public Safety Band (PSB) frequencies; this isSam Leffler2009-01-161-0/+66
| | | | | | | modeled after the Atheros SKU of the same name Notes: svn path=/head/; revision=187343
* o fix DEBUG sku definitionSam Leffler2008-12-151-1/+138
| | | | | | | o add definitions for 900MHz radios: Ubiquiti SR9 and XR9, and ZComax GZ-901 Notes: svn path=/head/; revision=186106
* 802.11 regulatory definitions used by ifconfigSam Leffler2008-04-201-0/+1580
Support by: Hobnob Notes: svn path=/head/; revision=178355
generated by cgit v1.3 (git 2.53.0) at 2026-04-01 17:19:08 +0000