[RFC] wireless: improve dfs-region intersection.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 23, 2014 at 7:35 PM, Ben Greear <greearb at candelatech.com> wrote:
>
>>> Maybe just use time-zone or user hints in this case since NICs cannot
>>> be fully trusted.
>>
>>
>> WTF no, the regulatory hint stuff should all be automated and user input
>> should really only come from trusted sources, see the cell base station
>> hint as a good example use case. The NICs are trusted as that's what
>> regulatory bodies like folks to do. Hell even the country IEs are only
>> trusted for the alpha2, the actual contents are disregarded. Regular
>> user input should only help compliance further, that's it.
>
>
> NICs just aren't that reliable, seems you can buy NICs with any number
> of regulatory domains on the interweb, and then you can hop on a plane
> and go other interesting places.

You can also reverse engineer firmware, also design RW support on OTPs
and EEPROMs, so there's tons of ways one can circumvent regulatory,
its not meant to be perfect, specially since tons of software is
required for hugely complex regulatory compliance rules such as in
DFS. We however do the best to enable all types of devices to be
compliant, we do the very best, and its also why we get vendor support
upstream even with open firmware designs. Location information is also
important for a device that get calibrated for a specific region --
the architecture on some devices mandates that you can only fit
certain things into hardware / OTP / EEPOM and some folks optimize
functionality of a card so that that very specific tuning applies only
to a specific region it got certified for, so the ideal operation of a
device is for what area it was designed for. If folks repuropose them
it may not work as well.What ends up in the market will vary and what
folks do in their basement or lab is up to them -- enable onus kernel
flag stuff and go to town.

There's tons of good resources an operating system can rely on to
guarantee the region other than a stupid EEPROM / OTP / Country IE,
the ideal solution folks should strive for would be a series of
heuristics that can guarantee this and only use the OTP / whatever for
when the location cannot be known for sure.

An easy start up idea would be to find a really cheap way to ensure
this for hardware other than GPS. The resolution would suffice to be
ISO3166 specific to the most popular countries.

> If you ever have a system with NICs with two different regulatory domains,

Folks should not be selling these and if they end up with them the
intersection is taken, and additionally user input is welcomed.

> I assume it is very likely that it was not certified in that configuration.

A device *sold* under that configuration would need to be certified.

> Maybe the user's input (and AP's beacons and such) are more reliable in this
> case.

Location information should use a series of heuristics, and a degree
of trust should be used to quality them. Userespace input for hints
coming from cell base stations are of a good source, as an example and
some folks ship products using it. Users should only be allowed to
help compliance further, that's it. The default stuff should be done
without any user input.

> But, not worth arguing about at this point.  As long as the basic regulatory
> bugs are fixed (as per the other thread), then my problems should be
> solveable.

Yes, lets use our time effectively please.

 Luis



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux