Linux: RPi4: Wifi não pode se conectar ao ponto de acesso ac (sem recursos VHT)

Criado em 16 dez. 2019  ·  60Comentários  ·  Fonte: raspberrypi/linux

O Raspberry Pi 4 não é capaz de se conectar a pontos de acesso wi-fi com padrão wi-fi "ac".
Isso ocorre porque o Raspberry PI 4 não está enviando nenhum recurso VHT.
Meu roteador wi-fi está funcionando com ponto de acesso padrão misto "n + ac" (WI-Fi 5) de 5 GHz e o Raspberry PI 4 está sempre se conectando com o padrão n.

Reproduzir
Use a seguinte configuração wpa_supplicant e conecte-se ao ponto de acesso.

wpa_supplicant.config:

ctrl_interface = / run / wpa_supplicant
p2p_disabled = 1

rede = {
ssid = "MySSID"
psk = "MySecurePsk"
proto = RSN
key_mgmt = WPA-PSK
emparelhados = CCMP
auth_alg = ABRIR
pbss = 2
}

Comportamento esperado
O Raspberry PI 4 deve enviar recursos VHT e se conectar com wi-fi padrão ac

Comportamento real
O Raspberry PI 4 não envia recursos VHT e se conecta com o padrão wi-fi n

  • Qual modelo de Raspberry Pi? por exemplo, Pi3B +, PiZeroW
    Raspberry Pi 4 4 GB de RAM

  • Qual sistema operacional e versão ( cat /etc/rpi-issue )?
    Referência do Raspberry Pi 08/06/2019
    Gerado usando pi-gen, https://github.com/RPi-Distro/pi-gen , d942d5487c035ecd568c1a3049d8b00b14132678, stage5

  • Qual versão de firmware ( vcgencmd version )?
    24 de setembro de 2019 17:34:30
    Copyright (c) 2012 Broadcom
    versão cd3add54955f8fa065b414d8fc07c525e7ddffc8 (limpo) (lançamento) (início)

  • Qual versão do kernel ( uname -a )?
    Linux hostname 4.19.75-v7l + # 1270 SMP Ter. Set 24 18:51:41 BST 2019 armv7l GNU / Linux

Histórico
Encontre em anexo uma captura do Wireshark da solicitação de associação com recursos VHT ausentes ...
wirehark_capture.zip

dmesg:
dmesg.txt

Wifi Issue

Todos 60 comentários

Em que país / domínio regulatório você está? Seu wpa_supplicant.conf parece não ter a linha "country = XX".

Esta é a saída de "iw reg get":
global
país DE: DFS-ETSI
(2400-2483 @ 40), (N / A, 20), (N / A)
(5150 - 5250 @ 80), (N / A, 20), (N / A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N / A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N / A, 26), (0 ms), DFS
(5725-5875 @ 80), (N / A, 13), (N / A)
(57000-66000 @ 2160), (N / A, 40), (N / A)

O ponto de acesso wi-fi também está configurado para a Alemanha.

Meu 4B não tem dificuldade para se conectar a um AP "ac" e suspeito que milhões de outros usuários 4B e 3B + (ambos usam o mesmo controlador WiFi) estão na mesma posição. Posso pensar em quatro possíveis explicações para a diferença:

  1. A maioria dos APs ac não exige recursos VHT, mas o seu exige.
  2. Nenhum AP AC requer capacidades VHT - a falha ao conectar ao seu AP é causada por outra coisa.
  3. A maioria dos Pis equipados com 43455 geram capacidades VHT, mas seu 4B com sua configuração não.
  4. Todos os Pis equipados com 43455 geram recursos VHT, mas eles não estão sendo capturados e o problema não está relacionado.

Por favor, tente conectar ao seu AP usando o assistente de pós-instalação WiFi em um novo download do Raspbian. Se o seu AP estiver configurado para exigir configurações fora do padrão, explique exatamente quais configurações em seu wpa_supplicant.conf são absolutamente necessárias.

De acordo com minha pesquisa no Google, VHT é outro nome para IEEE 802.11ac. Por https://www.electronicdesign.com/technologies/communications/article/21798297/understanding-ieee-80211ac-vht-wireless :

Também conhecido como Very High Throughput (VHT), o 802.11ac está posicionado como o sucessor do 802.11n, conhecido como High Throughput (HT).

É o que parece, mas isso realmente não nos move para a frente.

@HardResetSolution Como você criou essa captura do Wireshark? Requer um dispositivo em modo monitor?

Tive a oportunidade de verificar a interoperabilidade com mais 2 pontos de acesso wi-fi. Os 3 dispositivos testet mostram o seguinte comportamento:

FRITZ! Box 7590 -> PI não envia recursos VHT
Asus ac68u -> PI não envia recursos VHT
Netgear Nighthawk rax40 -> PI envia capacidades VHT

asus_and_netgear.zip

Para este teste, usei o assistente de pós-instalação de WiFi em um novo download do Raspbian.

wpa_supplicant.config é o seguinte:

ctrl_interface = DIR = / var / run / wpa_supplicant GROUP = netdev
update_config = 1
país = DE

rede = {
ssid = "MySSID"
psk = "MySecurePsk"
key_mgmt = WPA-PSK
}

Para o FRITZ! Box, poderia criar a captura através do próprio ponto de acesso. Para Asus e Netgear, usei um farejador de wi-fi (modo monitor).

@pelwell Qual ponto de acesso você usou e como você se certificou de que o Raspberry PI está usando "ac" e não "n"?

Qual ponto de acesso você usou e como você se certificou de que o Raspberry PI está usando "ac" e não "n"?

Temos uma rede WiFi interna da Ubiquiti, e o Netgear Nighthawk R7000 na minha mesa, e o 4B se conecta a ambos na banda 5G. Ambos são APs com capacidade "ac", mas é possível que essas conexões sejam apenas "n" - está chegando a uma largura de canal de 40 MHz.

Eu poderia verificar mais alguns pontos de acesso, mas não tenho certeza se isso vai nos ajudar.
Alguém tem ideia de como verificar se o PI está conectado via "n" ou "ac". Até agora, a única maneira que conheço é verificar a GUI do ponto de acesso do FRITZ! Box.
Como você mencionou, meus PIs também se conectam com largura de canal de 40 MHz - mas podem ser os dois: "n" ou "ac".

Ubuntu tem https://packages.ubuntu.com/eoan/iw que pode mostrar a largura de banda de uma conexão desta forma (em um dos meus dispositivos rpi4B conectado a um Ubiquiti nano-HD):

<strong i="7">@rpi4</strong>:~$iw dev
phy#0
        Unnamed/non-netdev interface
                wdev 0x2
                addr ******
                type P2P-device
                txpower 31.00 dBm
        Interface wlan0
                ifindex 3
                wdev 0x1
                addr ******
                ssid ******
                type managed
                channel 104 (5520 MHz), width: 80 MHz, center1: 5530 MHz
                txpower 31.00 dBm

(Devo estar conectado por CA, pois estou conectado por meio de um canal de 80 MHz.)

Olá,

Eu tenho o mesmo problema.
Tenho um RPi4 e o roteador Fritz! Box 7590.

Normalmente, meu código de país RPi é definido como DE:
20200412_030416

Eu descobri que se eu definir a região RPi para US, uma conexão CA de 5 GHz é estabelecida:
20200412_021404

A conexão CA fica muito instável e se desconecta com ainda mais frequência.

(RPi4 e SmartDevice estão na mesma sala)

Vejo o mesmo comportamento com o meu roteador FRITZ! Box 7590.
Definir a região PIs para "DE" leva à conexão "n".
Definir a região PIs para "US" leva à conexão "ac".

Na captura anexada você pode ver que no pacote 4 (região "DE") os recursos VHT estão faltando, mas no pacote 15 (região "US") eles estão incluídos. Isso parece uma prova do mau comportamento do PI para mim.
capture.zip

Eu também tive problemas porque meus 4er Pi's não tinham se conectado à rede AC. O problema provavelmente se deve ao desempenho de recepção dos Pi's. Usando o software do roteador DD-WRT, posso definir a potência de transmissão separadamente, se eu reduzir a potência de transmissão na rede N 2,4 GHz em -2 dB, então o Pi escolherá a rede AC em vez da rede N 2,4 GHz. Portanto, basta pensar que os Pi's escolhem a rede mais forte e, portanto, sempre escolhem a rede N 2,4 GHz mais forte.

Talvez deva ser melhorado no firmware que a rede AC tenha prioridade, mesmo que seja minimamente mais fraca do que a rede N

Fiz uma verificação de quais códigos de país resultam em uma conexão CA com o FRITZ! Box 7590.

conexão com ac:
AD, AU, NG, TZ, UG, US

conexão com apenas n:
AR, AT, BE, BA, CH, CY, CZ, DK, DE, EE, ES, FI, FR, GR, GB, HU, IE, IL, IT, HR, LU, LV, ME, MK, NA, NZ, NL, NO, PL, PT, SE, SI, SK, TH, ZA

Você pode baixar um arquivo clm_blob de teste que pode melhorar as opções de conexão - está disponível em https://drive.google.com/file/d/1Qoc90FCTO17d69PbBqUhkJKgqDMmdOui/view?usp=sharing

Faça um backup do seu clm_blob antigo e instale o novo usando:

$ sudo cp /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob{,.orig}
$ sudo cp 43455_raspberry_3p_v1_190515.clm_blob /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob

Reinicialize para usar o novo clm_blob.

NB Este clm_blob não é adequado para uso em um 3B +, então não tente fazer isso em uma placa que pode ser usada em um.

Acabei de testar o arquivo, e nada melhor.

O PI4 se conecta apenas em 2,4 GHz (sinal -32 db; tx: 48 mbit / s; rx: 24 mbit / s)

Thie PI4 não deseja se conectar em 5 Ghz - 80 Mhz (802.11a, 802.11n, 802.11ac).

Pi4 é instalado próximo ao roteador (freebox frança)

deve uma opção ser ativada?

country=fr
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="*****"
psk="******"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
}
iw dev
phy#0
        Unnamed/non-netdev interface
                wdev 0x2
                addr ***
                type P2P-device
                txpower 31.00 dBm
        Interface wlan0
                ifindex 3
                wdev 0x1
                addr ***
                ssid ***
                type managed
                channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
                txpower 31.00 dBm

O que iw phy0 channels reporta?

[atualizado com o código do país: fr]

Band 1:
        * 2412 MHz [1]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+
        * 2417 MHz [2]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+
        * 2422 MHz [3]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+
        * 2427 MHz [4]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+
        * 2432 MHz [5]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+
        * 2437 MHz [6]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+
        * 2442 MHz [7]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+
        * 2447 MHz [8]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+
        * 2452 MHz [9]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+
        * 2457 MHz [10]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40-
        * 2462 MHz [11]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40-
        * 2467 MHz [12]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40-
        * 2472 MHz [13]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40-
        * 2484 MHz [14] (disabled)
Band 2:
        * 5170 MHz [34] (disabled)
        * 5180 MHz [36]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5190 MHz [38]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5200 MHz [40]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+ VHT80
        * 5210 MHz [42]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+ VHT80
        * 5220 MHz [44]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+ VHT80
        * 5230 MHz [46]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5240 MHz [48]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- HT40+ VHT80
        * 5260 MHz [52]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5280 MHz [56]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5300 MHz [60]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5320 MHz [64]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5500 MHz [100]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5520 MHz [104]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5540 MHz [108]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5560 MHz [112]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5580 MHz [116]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5600 MHz [120]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5620 MHz [124]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5640 MHz [128]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5660 MHz [132]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5680 MHz [136]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- HT40+ VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5700 MHz [140]
          Maximum TX power: 20.0 dBm
          Radar detection
          Channel widths: 20MHz HT40- VHT80
          DFS state: usable (for 144 sec)
          DFS CAC time: 60000 ms
        * 5720 MHz [144] (disabled)
        * 5745 MHz [149] (disabled)
        * 5765 MHz [153] (disabled)
        * 5785 MHz [157] (disabled)
        * 5805 MHz [161] (disabled)
        * 5825 MHz [165] (disabled)

E que tal iwconfig wlan0 e iw reg get ?

$ iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"**"
          Mode:Managed  Frequency:2.412 GHz  Access Point: ***
          Bit Rate=54 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=67/70  Signal level=-43 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

$ iw reg get

country FR: DFS-ETSI
        (2402 - 2482 @ 40), (N/A, 20), (N/A)
        (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
        (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

Obrigado. Estou examinando essa área no momento, então tentarei sua configuração também.

obrigado. Eu atualizei o comentário para os canais iw phy0.
Eu não estava no código fr quando percebi a primeira resposta

Não consigo ver uma razão óbvia pela qual ele não conectou. O AP aparece nos resultados da varredura na banda 5G?

Você pode tentar adicionar brcmfmac.debug=0x100000 ao cmdline.txt (mantê-lo em uma única linha) e tentar se conectar. Se o seu AP permite que as duas bandas recebam nomes diferentes ou que a banda 2.4G seja desligada, tente isso também.

Não, o Ap aparece apenas para 2g Band

$ iw wlan0 scan | grep -A5 'freq: 5'

voltar vazio

a configuração do ap:
canal wi-fi principal: 120
canal wi-fi secundário: 116

image

image

No comando 'iw reg get', quais são os parâmetros?
DFS, AUTO-BW

Não entendi como usar cmdline.txt

DFS é a seleção dinâmica de frequência (detecção e prevenção de radar) e AUTO-BW é a largura de banda automática (escolha uma largura de canal sensível - 20, 40, 80).

Edite o cmdline.txt com seu editor favorito - sudo nano /boot/cmdline.txt , sudo vi /boot/cmdline.txt ; acrescente brcmfmac.debug=0x100000 ao final da linha e reinicie.

Não consigo desativar uma banda, mas posso mudar o SSID. Acabei de testar e o pi4 ainda conecta na banda de 2,4Ghz e não detecta o AP na banda de 5Ghz.

eu adicionei brcmfmac.debug=0x100000 , reinicie e voila

$ dmesg | grep brcm
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 cma=64M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:62:C5:BF vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=PARTUUID=0c282079-02 rootfstype=ext4 cgroup_enable=cpuset cgroup_enable=memory swapaccount=1 elevator=deadline fsck.repair=yes rootwait brcmfmac.debug=0x100000
[    0.267006] brcm-pcie fd500000.pcie: dmabounce: initialised - 32768 kB, threshold 0x00000000c0000000
[    0.267053] brcm-pcie fd500000.pcie: could not get clock
[    0.267130] brcm-pcie fd500000.pcie: host bridge /scb/pcie<strong i="8">@7d500000</strong> ranges:
[    0.267182] brcm-pcie fd500000.pcie:   MEM 0x600000000..0x603ffffff -> 0xf8000000
[    0.318050] brcm-pcie fd500000.pcie: link up, 5.0 Gbps x1 (!SSC)
[    0.318335] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[    0.510242] brcmstb_thermal fd5d2200.thermal: registered AVS TMON of-sensor driver
[    4.258353] brcmfmac: F1 signature read @0x18000000=0x15264345
[    4.275921] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    4.276607] usbcore: registered new interface driver brcmfmac
[    4.511445] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    4.515272] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2
[    4.578457] brcmfmac: CONSOLE: d 0
[    4.578472] brcmfmac: CONSOLE: 000000.063 wl0: Broadcom BCM4345 802.11 Wireless Controller 7.45.202 (r724630 CY)
[    4.578483] brcmfmac: CONSOLE: 000000.064 TCAM: 256 used: 252 exceed:0
[    4.578494] brcmfmac: CONSOLE: 000000.065 reclaim section 1: Returned 122844 bytes to the heap
[    4.578504] brcmfmac: CONSOLE: 000000.065 reclaim section 4: Returned 44 bytes to the heap
[    4.578514] brcmfmac: CONSOLE: 000000.065 sdpcmd_dpc: Enable
[    4.578524] brcmfmac: CONSOLE:
[    4.578534] brcmfmac: CONSOLE: 000000.079 wl0: unable to find iovar "rsdb_mode"
[    4.578545] brcmfmac: CONSOLE: 000000.079 wl0: wlc_iovar_op: rsdb_mode BCME -23 (Unsupported)
[    6.818566] brcmfmac: CONSOLE: 000002.356 wl0: unable to find iovar "toe_ol"
[    6.818579] brcmfmac: CONSOLE: 000002.356 wl0: wlc_iovar_op: toe_ol BCME -23 (Unsupported)
[    6.818589] brcmfmac: CONSOLE: 000002.356 wl0: wl_open
[    6.818600] brcmfmac: CONSOLE: 000002.365 wl0: wlc_phy_set_regtbl_on_femctrl: FIXME bt_coex
[    6.826553] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[    6.970542] brcmfmac: brcmf_cfg80211_reg_notifier: Firmware rejected country setting
[    6.988385] brcmfmac: CONSOLE: 000002.526 wl0: wlc_iovar_op: country BCME -2 (Bad Argument)
[    9.578379] brcmfmac: CONSOLE: 000005.110 wl0: wl_open
[    9.578392] brcmfmac: CONSOLE: 000005.119 wl0: wlc_phy_set_regtbl_on_femctrl: FIXME bt_coex
[   15.828373] brcmfmac: CONSOLE: 000011.330 wl0: link up (wl0)
[   15.878370] brcmfmac: CONSOLE: 000011.378 wl0: unable to find iovar "nd_hostip_clear"
[   15.878383] brcmfmac: CONSOLE: 000011.378 wl0: wlc_iovar_op: nd_hostip_clear BCME -23 (Unsupported)
[   17.248369] brcmfmac: CONSOLE: 000012.745 wl0: unable to find iovar "nd_hostip_clear"
[   17.248382] brcmfmac: CONSOLE: 000012.745 wl0: wlc_iovar_op: nd_hostip_clear BCME -23 (Unsupported)

[6.970542] brcmfmac: brcmf_cfg80211_reg_notifier: Firmware rejeitou configuração de país

Isso era esperado com o blob de 813 bytes. Você deve obter resultados diferentes com o blob de 14036 bytes original.

com o original: +1:

$ dmesg | grep brcm
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 cma=64M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:62:C5:BF vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=PARTUUID=0c282079-02 rootfstype=ext4 cgroup_enable=cpuset cgroup_enable=memory swapaccount=1 elevator=deadline fsck.repair=yes rootwait brcmfmac.debug=0x100000
[    0.269420] brcm-pcie fd500000.pcie: dmabounce: initialised - 32768 kB, threshold 0x00000000c0000000
[    0.269468] brcm-pcie fd500000.pcie: could not get clock
[    0.269542] brcm-pcie fd500000.pcie: host bridge /scb/pcie<strong i="6">@7d500000</strong> ranges:
[    0.269594] brcm-pcie fd500000.pcie:   MEM 0x600000000..0x603ffffff -> 0xf8000000
[    0.328156] brcm-pcie fd500000.pcie: link up, 5.0 Gbps x1 (!SSC)
[    0.328439] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[    0.521831] brcmstb_thermal fd5d2200.thermal: registered AVS TMON of-sensor driver
[    4.221393] brcmfmac: F1 signature read @0x18000000=0x15264345
[    4.229180] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    4.229548] usbcore: registered new interface driver brcmfmac
[    4.464346] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    4.480291] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2
[    4.549788] brcmfmac: CONSOLE: d 0
[    4.549802] brcmfmac: CONSOLE: 000000.063 wl0: Broadcom BCM4345 802.11 Wireless Controller 7.45.202 (r724630 CY)
[    4.549813] brcmfmac: CONSOLE: 000000.064 TCAM: 256 used: 252 exceed:0
[    4.549824] brcmfmac: CONSOLE: 000000.065 reclaim section 1: Returned 122844 bytes to the heap
[    4.549835] brcmfmac: CONSOLE: 000000.065 reclaim section 4: Returned 44 bytes to the heap
[    4.549845] brcmfmac: CONSOLE: 000000.065 sdpcmd_dpc: Enable
[    4.549855] brcmfmac: CONSOLE:
[    4.549865] brcmfmac: CONSOLE: 000000.091 wl0: unable to find iovar "rsdb_mode"
[    4.549875] brcmfmac: CONSOLE: 000000.091 wl0: wlc_iovar_op: rsdb_mode BCME -23 (Unsupported)
[    6.818814] brcmfmac: CONSOLE: 000002.402 wl0: unable to find iovar "toe_ol"
[    6.818828] brcmfmac: CONSOLE: 000002.403 wl0: wlc_iovar_op: toe_ol BCME -23 (Unsupported)
[    6.818838] brcmfmac: CONSOLE: 000002.403 wl0: wl_open
[    6.818849] brcmfmac: CONSOLE: 000002.412 wl0: wlc_phy_set_regtbl_on_femctrl: FIXME bt_coex
[    6.825101] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[    9.228528] brcmfmac: CONSOLE: 000004.808 wl0: wl_open
[    9.228541] brcmfmac: CONSOLE: 000004.817 wl0: wlc_phy_set_regtbl_on_femctrl: FIXME bt_coex
[   14.448487] brcmfmac: CONSOLE: 000010.004 wl0: link up (wl0)
[   14.588470] brcmfmac: CONSOLE: 000010.140 wl0: unable to find iovar "nd_hostip_clear"
[   14.588484] brcmfmac: CONSOLE: 000010.141 wl0: wlc_iovar_op: nd_hostip_clear BCME -23 (Unsupported)
[   14.608519] brcmfmac: CONSOLE: 000010.160 wl0.0: wlc_send_bar: seq 0x1 tid 7
[   15.468485] brcmfmac: CONSOLE: 000011.015 wl0.0: wlc_send_bar: seq 0x3 tid 0
[   16.608490] brcmfmac: CONSOLE: 000012.159 wl0: unable to find iovar "nd_hostip_clear"
[   16.608503] brcmfmac: CONSOLE: 000012.159 wl0: wlc_iovar_op: nd_hostip_clear BCME -23 (Unsupported)
[   72.698478] brcmfmac: CONSOLE: 000068.116 wl0.0: wlc_send_bar: seq 0x1 tid 4
[   74.818403] brcmfmac: CONSOLE: 000070.217 wl0.0: wlc_send_bar: seq 0x1 tid 5
[   87.078567] brcmfmac: CONSOLE: 000082.416 wl0.0: wlc_send_bar: seq 0x1 tid 2
[   87.518720] brcmfmac: CONSOLE: 000082.847 wl0.0: wlc_send_bar: seq 0x1 tid 6

Eu vejo o 👍 - isso significa que ele se conecta à banda AC?

com o brcm original, pi4 (pássaro-vermelho) está conectado na banda de 5 GHz, mas em N, não em AC

image

$  iw wlan0 scan | grep -A5 'freq: 5'
        freq: 5600
        beacon interval: 96 TUs
        capability: ESS Privacy SpectrumMgmt (0x0111)
        signal: -52.00 dBm
        last seen: 0 ms ago
        SSID: *** //ap on 5G

Obrigado - eu entendo.

eu reinicio e examino as duas frequências do meu AP

5600 MHz [120]
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40-
          DFS state: usable (for 940 sec)
          DFS CAC time: 60000 ms
        * 5620 MHz [124]
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40+
          DFS state: usable (for 940 sec)
          DFS CAC time: 60000 ms

o canal com configuração de 80Mhz (VHT80) não está presente !! Apenas 20 MHz um HT40 +.
Poderia vir de lá? Como adicioná-lo à configuração?

O blob antigo não declara nenhum canal VHT-80 e causa outros problemas para algumas regiões (KR, por exemplo). O novo mini-blob deve ajudar com muitos desses problemas, mas por algum motivo não está funcionando para você.

o código do canal 'fr' pode ser a causa (com o novo mini blob)? devo testar com outro código?

Pelo que entendi, o mini-blob deve rejeitar todos os códigos de país e aprender com o meio ambiente. Você pode tentar um CC diferente, mas não deve fazer diferença.

[6.970542] brcmfmac: brcmf_cfg80211_reg_notifier: Firmware rejeitou configuração de país

country = fr

dentro de wpa_supplicant.conf , não deveria ser capitalizado como country=FR vez de country=fr ?

country = fr ou country = FR minério country = US são o mesmo reg

$ iw reg get
global
country FR: DFS-ETSI
        (2402 - 2482 @ 40), (N/A, 20), (N/A)
        (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
        (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

MAS com country = US, funciona no modo 5Ghz AC !!!!! Com o mesmo SSID para duas bandas ..

image

a configuração final

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
wireless-power off
iface default inet dhcp

country=US
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
ssid="matrice"
psk="*********"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
}

$ iwconfig
eth0      no wireless extensions.

wlan0     IEEE 802.11  ESSID:"matrice"
          Mode:Managed  Frequency:5.6 GHz  Access Point: *****
          Bit Rate=433.3 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=70/70  Signal level=-23 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

$ iw dev
phy#0
        Unnamed/non-netdev interface
                wdev 0x2
                addr ***
                type P2P-device
                txpower 31.00 dBm
        Interface wlan0
                ifindex 3
                wdev 0x1
                addr ***
                ssid *****
                type managed
                channel 120 (5600 MHz), width: 80 MHz, center1: 5610 MHz
                txpower 31.00 dBm

Embora country=US torne capaz de se conectar ao AP em modo "CA" e iw mostre width: 80MHz , a velocidade real não é nada mais rápida (bem, talvez no máximo 5 %). Ainda está limitado a ~ 100Mbps, enquanto meu receptor USB 2.0 buffalo / realtek 1x1 / 433 ac é 2,5 vezes mais rápido.

Não posso deixar de notar a diferença:

[tom<strong i="10">@alarmpi</strong> tmp]$ iw phy phy0 info | grep highest
        VHT RX highest supported: 0 Mbps
        VHT TX highest supported: 0 Mbps
[tom<strong i="11">@alarmpi</strong> tmp]$ iw phy phy1 info | grep highest
        VHT RX highest supported: 434 Mbps
        VHT TX highest supported: 434 Mbps

O 43455 é conectado por meio de um link SDIO de 4 bits, geralmente rodando a ~ 42MHz. Isso dá um limite de taxa de transferência teórico de 168 Mbps, mas isso é half-duplex e assumindo nenhum comando e nenhuma pausa. Dado isso, ~ 100Mbps é o que eu esperaria.

O 43455 é conectado por meio de um link SDIO de 4 bits, geralmente rodando a ~ 42MHz. Isso dá um limite de taxa de transferência teórico de 168 Mbps, mas isso é half-duplex e assumindo nenhum comando e nenhuma pausa. Dado isso, ~ 100Mbps é o que eu esperaria.

lol, então ac ou não não deveria importar de qualquer maneira? (diferente de "compatibilidade"), mas a fundação deve estabelecer que o limite: P

Um Pi individual pode não ser capaz de maximizar a largura de banda AC, mas cada pacote será enviado a uma taxa total, o que deixará lacunas maiores para outros transmitirem - há uma vantagem.

Agora existe um clm_blob atualizado que deve dar acesso aos canais de 80 MHz: https://drive.google.com/file/d/1AN7lC_kMJGGg5AJLhSRtlTRgIh9qJlaI/view?usp=sharing
Este é o resultado usando o código do país FR :

pi<strong i="9">@raspberrypi</strong>:~$ iw phy0 channels
Band 1:
        * 2412 MHz [1]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2417 MHz [2]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2422 MHz [3]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2427 MHz [4]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2432 MHz [5]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2437 MHz [6]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2442 MHz [7]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2447 MHz [8]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2452 MHz [9]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2457 MHz [10]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2462 MHz [11]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2467 MHz [12]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2472 MHz [13]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz
        * 2484 MHz [14] (disabled)
Band 2:
        * 5170 MHz [34] (disabled)
        * 5180 MHz [36]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5190 MHz [38] (disabled)
        * 5200 MHz [40]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5210 MHz [42] (disabled)
        * 5220 MHz [44]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5230 MHz [46] (disabled)
        * 5240 MHz [48]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5260 MHz [52] (disabled)
        * 5280 MHz [56] (disabled)
        * 5300 MHz [60] (disabled)
        * 5320 MHz [64] (disabled)
        * 5500 MHz [100] (disabled)
        * 5520 MHz [104] (disabled)
        * 5540 MHz [108] (disabled)
        * 5560 MHz [112] (disabled)
        * 5580 MHz [116] (disabled)
        * 5600 MHz [120] (disabled)
        * 5620 MHz [124] (disabled)
        * 5640 MHz [128] (disabled)
        * 5660 MHz [132] (disabled)
        * 5680 MHz [136] (disabled)
        * 5700 MHz [140] (disabled)
        * 5720 MHz [144] (disabled)
        * 5745 MHz [149]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5765 MHz [153]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5785 MHz [157]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5805 MHz [161]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5825 MHz [165]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz

Pode valer a pena anunciar isso no fórum.

@ tomty89 - Não sei o quão sábio é enviar estes não testados. Além disso, incluí-los depende de @kmihelich

@pelwell Você pode me dar uma dica de como instalar o blob?
Em https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=291609 vejo instruções para copiar brcmfmac43455-sdio.clm_blob para / lib / firmware / brcm /.
Mas o link de download fornecido aponta para brcmfmac43455-sdio.bin. De onde obtenho o arquivo .clm_blob?

Não entendo - o link de download (https://drive.google.com/file/d/1AN7lC_kMJGGg5AJLhSRtlTRgIh9qJlaI/view?usp=sharing) é para brcmfmac43455-sdio.clm_blob.

OK, minha culpa. O FireFox para Android substituiu a extensão do arquivo de clm_blob para bin por algum motivo.

Obrigado pela dica para o blob de firmware!
Num teste rápido, o Raspberry Pi conseguiu estabelecer uma ligação ao meu FRITZ! Box com a região DE e WIFI padrão AC e HT80.
Vou tentar fazer alguns testes de estabilidade.

Neste ponto, é muito provável que o blob atualizado esteja na próxima imagem.

Eu torci muito cedo. O Raspberry PI agora só pode se conectar a APs que usam canais inferiores a 52, que são apenas os canais 36, 40, 44 e 48. APs em canais diferentes não são vistos / encontrados pelo Raspberry PI.

iw reg get:
global
país DE: DFS-ETSI
(2400-2483 @ 40), (N / A, 20), (N / A)
(5150 - 5250 @ 80), (N / A, 20), (N / A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N / A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N / A, 26), (0 ms), DFS
(5725-5875 @ 80), (N / A, 13), (N / A)
(57000-66000 @ 2160), (N / A, 40), (N / A)

Não importa qual país eu configuro em wpa_supplicant.conf. Tentei DE, US e UG.

Tente este: https://drive.google.com/file/d/1J8DdbsrZcSkDYKUPsdy2RvncttSwQdBH/view?usp=sharing

Observe que você precisará renomeá-lo de brcmfmac43456-sdio.clm_blob para brcmfmac43455-sdio.clm_blob antes (ou quando) copiá-lo para / lib / firmware / brcm.

Obrigado pelwell. Fiz alguns testes e configurei uma comparação entre o blob original, 43455 e 34456.
Coloquei os pontos negativos em negrito.

blob original:

  • ac e HT80 não é possível
  • a conexão a todos os canais de 5 GHz é possível
  • a conexão a todos os canais de 2,4 GHz é possível

brcmfmac43455-sdio.clm_blob:

  • conexão ac com HT80 é possível
  • A conexão de 5 GHz só é possível com os canais 36, 40, 44 e 48
  • A conexão de 2,4 GHz é possível com todos os canais 1 a 13

brcmfmac43456-sdio.clm_blob:

  • conexão ac com HT80 é possível
  • A conexão de 5 GHz parece ser possível com todos os canais (testei alguns canais aleatórios como 36, 52, 64, 100, 116, 128)
  • A conexão de 2,4 GHz só é possível com os canais 1 e 2
  • A conexão de 2,4 GHz só é possível com os canais 1 e 2

Eu tenho um Pi 4 aqui rodando com o renomeado 43455 clm_blob, configurado para estar na região WiFi "DE", e felizmente está conectado no canal 11.

Estranho, coloquei um segundo Pi 4 no meu testsetup e este pode se conectar com todos os canais de 2,4 GHz.
Embora eu esteja um pouco confuso quanto ao motivo do primeiro Pi estar tendo problemas, o brcmfmac43456-sdio.clm_blob corrige o problema de CA.

Você disse que o blob atualizado estará na próxima imagem. Você tem uma ideia de quando será lançado? Ou você pode dizer quando o blob fará parte das atualizações regulares via apt?

A próxima imagem deve ser entregue em questão de semanas, em vez de meses. O pacote apt relevante pode ser atualizado antes disso, mas provavelmente não.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

incyi picture incyi  ·  9Comentários

thomasklingbeil picture thomasklingbeil  ·  4Comentários

dkerr64 picture dkerr64  ·  7Comentários

kucharskim picture kucharskim  ·  7Comentários

wudo94 picture wudo94  ·  5Comentários