Date: Sun, 09 Aug 2020 15:37:58 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: freebsd-wireless <freebsd-wireless@freebsd.org> Subject: Re: regdomain.xml [was also: - Linux wireless-regdb] Message-ID: <083B7D36-2175-46DC-9C9A-FEA8673482E8@lists.zabbadoz.net> In-Reply-To: <c49d1f38-2fe3-46f0-8330-c472de16a9da@gmail.com> References: <b1404b90-87a5-8f78-aeb4-cf31bc1a704b@gmail.com> <adef735d-c3a1-1723-936d-1cf3e4b819c9@gmail.com> <CAJ-VmokM4Kxi%2BDKOGVJp6B4y7dOm8=Rm81eZQYYSHUcmNY2bDA@mail.gmail.com> <c49d1f38-2fe3-46f0-8330-c472de16a9da@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I’ll just join in on the last email in the thread not replying to anything specific. Having gone through some of the stuff lately myself in order to put [1] out (which is also includes a few things to discuss) I’ll try to summarise a few things I’ve learnt and thought of, which confused me over the time: - SKU - what does it actually stand for? Does it really belong into our regdomain? - why are the freqbands prefixes with “H”, “F”, .. and what do these magic letters stand for? - We have netbands, freqbands, and bands. None of these are actually describing the actual frequency ranges (as the linux-db does). - The freqbands seems to start and end on the center frequency of the first/last chansep spaced channel. In the old days that was less confusing I guess as to now with 4x20 for VHT80. - I am still unclear as to where we should map channels to frequency because we are half-hearted doing that partially for upper and lower bounds of freqbands currently. As such I have different freqbands for VHT20 vs. VHT40/80/160 as there are cases where there is an extra 20 channel not part of 80s. - I’d love to have the freqbands actually describe the frequency limits and have the mappings of channels within them elsewhere; I have no idea how/where Linux is doing that. - I’d love to have general freqbands and groups of them independent of the netbands. - I do not actually understand what netbands are for given we have the IEEE80211_CHAN_ set appropriately. It’s for simplicity later but there is a lot of duplication. That said, some of these IEEE80211_CHAN_* flags do not actually belong to the regulatory limits either but are an 802.11 channel description. - This all leads to confusion currently as to how we setup bands/channels/.. I made a mistake by accident and the list of combinations we checked in ifconfig exploded to 350.000 for whether a channel was valid. Clearly told me that the organisation does not seem to be right. - I was wondering if for clarity we can break up regdomain.xml into multiple files? - One thing I don’t like on the Linux version is that for, say ETSI, the information is basically copied per EU member state. I love our reference model there. I don’t mind having etsi, etsi1, etsi2 if I can then say 20 countries it’s etsi2 and be done. I think that is something essential and good we have. - I do like our more structured format a lot more than the Linux one. - We are lacking a few things, DFS and INDOORS and maxpower are not the only things which matter these days. You may notice “wmmrule=ETSI” in the Linux reg-db, for example. - I wonder if what we actually want is a multi-layer thingy inheriting one from another or if we want a pure-regdomain (not knowing about channels) and more logic elsewhere which deals with putting WiFi things into that)? - I think it’ll need a bit more than simply restructuring regdomain.xml; I think doing it will probably also need a bit more (a) documentation on what each bit means and tries to accomplish) and (b) a more clear separation between frequencies and restrictions and 802.11 channels and with that a bit more downward code changes. - I would really love to see some of these things sorted and I’d love if the thread would stay alive. Just my 5cts, Bjoern [1] https://reviews.freebsd.org/D25999
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?083B7D36-2175-46DC-9C9A-FEA8673482E8>