The documentation portion seems like the first step, is there a wiki for
proposed changes where we could start?
To get started, is there any existing documentation we can refer to? I
think the answer is no, and it's down to someone who understand it going
through the code to find answers ...
On 8/9/2020 11:37 AM, Bjoern A. Zeeb wrote:
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
_______________________________________________
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to
"freebsd-wireless-unsubscr...@freebsd.org"
_______________________________________________
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
