Am 30.10.20 um 14:23 schrieb Alvin Sipraga:
Hi,
On 10/30/20 8:20 AM, Jouni Malinen wrote:
So the issue is in not being able to operate an AP on the 5 GHz band?
That sounds like the expected behavior for any device that has not
been calibrated and provisioned for a specific country where
regulatory rules allow operation on the 5 GHz band. I understand that
this may look like a regression since the commit removed
functionality, but it feels like a bug fix to me since that
functionality should not have been enabled by default in the first
place. The goal here is to avoid inappropriate operation on the band
without explicit configuration to enable such operation. In AP
devices, the device should have been provisioned for a specific
country to be able to enforce the correct frequency range
restrictions. The safe default for a device that does not have such
explicit configuration within the WLAN component itself is to use the
world roaming mode which prevents initialization of radiation (i.e.,
does not allow AP mode to be started but allows station mode operation
to connect to an already started AP) on the 5 GHz band.
This explanation makes perfect sense, but are you sure that that is what
the 0x0 regulatory domain means? For example the pages [1][2] state
unequivocally that 0x0 means US.
If we assume 0x0 = US, do you agree that an EEPROM programmed with 0x0
should imply that the device is suitably calibrated for operation in the
United States, and as such should permit initiating radiation on the 5
GHz band (etc.)? Or have I missed something?
I also tried to get the patch in question reverted based on this
rationale, see [3] for more info. I hope somebody can help clear up this
misunderstanding, since it seems to me that the main issue is: what is
the true meaning of 0x0?
Btw, the hardware that Félix is referring to does have an FCC ID[4] and
seems to be suitably certified for the US.
Kind regards,
Alvin
[1]
https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain
[2]
https://web.archive.org/web/20150117040022/http://article.gmane.org/gmane.linux.kernel.wireless.general/38410
[3]
https://patchwork.kernel.org/project/ath10k/patch/20200730124923.271429-1-a...@bang-olufsen.dk/
[4] https://fccid.io/TK4WLE900VX
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Hello, this is not correct...
I have such a card with 0x0 in the eeprom
due to the patch the complete midband in station mode is missing
So the card can't see AP's in midband or connect to AP's either....
why are the cards mapped to 0x64 and not 0x6c?
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1895333
https://www.mail-archive.com/ath10k@lists.infradead.org/msg13040.html
the patch has made the card unusable for me and I had to deal
extensively with the thematics ...
and yes my card also has a FCC ID and it would be new to me that there
is no midband in the USA...
best regards
(sorry for breaking the list)
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
