Perguntas[wifi](unix)

Às vezes, na inicialização, leio essas mensagens

Jan 17 10:06:02 slack64 udevd[209]:  worker [219] /devices/pci0000:00/0000:00:08.1/0000:08:00.3/usb3/3-4/3-4.4/3-4.4:1.0/host8/target8:0:0/8:0:0:0/block/sr0 timeout; kill it
Jan 17 10:06:02 slack64 udevd[209]:  seq 1878 '/devices/pci0000:00/0000:00:08.1/0000:08:00.3/usb3/3-4/3-4.4/3-4.4:1.0/host8/target8:0:0/8:0:0:0/block/sr0' killed
Jan 17 10:06:46 slack64 udevd[209]:  worker [219] failed while handling '/devices/pci0000:00/0000:00:08.1/0000:08:00.3/usb3/3-4/3-4.4/3-4.4:1.0/host8/target8:0:0/8:0:0:0/block/sr0'

O boot está congelado e pode ficar mais de 5 minutos sem inicializar. A única solução é esta: remover o cabo USB da minha placa wifi (usar o driver 8852bu) e reconectá-lo (!) após a inicialização.

Minha pergunta é: como esse driver USB pode interferir em um dispositivo de bloco? sr0 não é uma unidade real, é um driver falso criado pelo pacote vhba-module.

O sistema é o Slackware 15.0, o hardware não é importante porque você faz a mesma coisa em três PCs diferentes.

Eu tentei esse método , mas não funciona.

Eu tive esse problema com meu mini-pc Geekom também, e agora estou vendo isso na minha placa-mãe MSI MAG Tomahawk x870 com placa Qualcomm PCI. Eu instalei o PopOS! e tudo funcionou muito bem, até que depois de cerca de 20 minutos a 1 hora, o Wifi parou de funcionar de repente.

Detalhes do sistema:

• Pop!_OS 22.04 LTS "jammy"
• Núcleo: 6.9
• Chipset Qualcomm Wifi: NCM865
• Driver: ath12k_pci

Coisas que tentei:

1. Modificado /etc/NetworkManager/conf.d/default-wifi-powersave-on.confpara desabilitar o powersave
2. Desabilitarufw
3. Desabilitarwireguard
4. Desabilitartailscale
5. Desligar o Bluetooth
6. Atualizar ath12k_pcidrivers: https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath12k/installation.html

Nada disso funcionou e estou sem ideias.

Quero adicionar um sistema Linux à lista branca de um hotspot móvel WiFi em execução no Android. Fazendo hostnamectlretornos, entre outras informações, um Static hostname, um Icon name, um Machine IDe um Boot ID. Qual destes é o correto?

Eu obtive o endereço MAC da wlan0interface fazendo isso ip addrno terminal e adicionei, junto com o Static hostname, à lista branca, mas a conexão falha. A intensidade do sinal é muito boa e a senha WPA2 está correta.

PS.: Em uma máquina com Windows 10, você obtém o nome correspondente hostnamena linha de comando ou pesquisando em Settings > System > About"Nome do dispositivo".

Depois que meu laptop (82EY IdeaPad Gaming 3 15ARH05) travou, reiniciei-o, mas nem meu bluetooth nem meu wifi estavam funcionando. Depois de copiar e colar comandos do stackoverflow (um clássico: P), consegui fazer meu bluetooth funcionar novamente, mas no processo, excluí os drivers da placa de rede

lshw -C network

*-network UNCLAIMED
       description: Network controller
       product: RTL8822CE 802.11ac PCIe Wireless Network Adapter
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:04:00.0
       version: 00
       width: 64 bits
       clock: 33MHz
       capabilities: cap_list
       configuration: latency=0
       resources: ioport:2000(size=256)
       memory:d1600000-d160ffff

Embora eu tenha encontrado os drivers necessários no github ( https://github.com/juanro49/rtl88x2ce-dkms ), todos os métodos de instalação listados não funcionam para mim.

Ambas as instalações através da construção e instalação de .deb resultam em erro anexado.

full error: https://pastebin.com/4jrSXq46
make[2]: *** [/usr/src/linux-headers-6.9.3-76060903-generic/Makefile:1925: /var/lib/dkms/rtl88x2ce/35403/build] Error 2
make[1]: *** [Makefile:240: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.9.3-76060903-generic'
make: *** [Makefile:2296: modules] Error 2

Eu sou um pouco novo no Linux, então toda a ajuda seria apreciada.

Além disso, não é um problema de hardware, o laptop tem inicialização dupla e o controlador de rede funciona bem no Windows.

Gostaria de instalar um switch Ethernet na garagem que fornecerá conexões ao mesmo segmento LAN do prédio principal. No entanto, não há cabo de rede entre o prédio principal e a garagem, mas há cobertura WiFi na garagem.

Já consegui o que quero com um roteador TP-Link Archer A7 que suporta modo de ponte sem fio. No entanto, eu realmente gostaria de fazer isso com um Raspberry Pi simples e um switch ethernet básico.

Usando interfaces/túneis GRE TAP, quase consegui, mas ele tem dificuldades com pacotes longos (por causa de algum problema irritante de MTU), então muitos pacotes são perdidos. Também encontrei algumas maneiras online de resolver isso usando NAT, mas isso não é aceitável no meu caso de uso. Os dispositivos que se conectam ao switch precisam estar no mesmo segmento de LAN que todos os outros dispositivos no prédio principal.

Alguém pode me dar uma resposta sobre a melhor maneira de fazer isso?

Em um arquivo de configuração hostapd , às vezes vejo a chave ssidpara especificar o SSID e às vezes vejo a chave ssid2. Qual é a diferença entre estes? Estou tendo problemas para encontrar documentação sobre o ssid2.

Atualmente usando Raspbian/bookworm na configuração padrão, 'NetworkManager' é usado para conectar-se a redes WiFi. Se você usar pelo menos um dispositivo WiFi adicional em seu RaspberryPi, você terá mais de uma interface wlan*. No meu exemplo eu uso um RaspberryPi 3B que tem WiFi integrado, então conectei um adaptador USB-WiFi, então tenho duas interfaces:

• wlan0 (interface WiFi própria do RaspberryPi)
• wlan1 (a interface adicional do adaptador USB-WiFi)

Como as conexões WiFi parecem não estar vinculadas à interface no NetworkManager, a conexão alterna descontroladamente entre a interface wlan0 e a interface wlan1 de vez em quando (como também às vezes entre reinicializações).

NetworkManager tem o seguinte configurado em /etc/NetworkManager/system-connections/preconfigured.nmconnection

[connection]
id=preconfigured
uuid=8043d3ca-6cb6-4449-83c4-61539463af66
type=wifi
[wifi]
mode=infrastructure
ssid=myhomenetwork
hidden=false
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
[wifi-security]
key-mgmt=wpa-psk
psk=ec6f<snip>128e

O dispositivo WiFi integrado (= wlan0) do RaspberryPi obviamente tem menos intensidade de sinal para minha rede doméstica do que o adaptador USB-WiFi, então quero usar o adaptador USB-WiFi (= wlan1) para conectar-me à minha rede doméstica. (Quero usar o dispositivo WiFi interno para conectar-me a outro AP WiFi próximo). Por esse motivo, tento vincular a conexão à minha rede doméstica na interface wlan1.

De acordo com a documentação do NetworkManager isso deve ser feito definindo interface-nameem [connection]. A documentação indica essa propriedade: "O nome da interface de rede à qual esta conexão está vinculada. Se não for definido, a conexão poderá ser anexada a qualquer interface do tipo apropriado..."

Então adicionei interface-name=wlan1assim:

[connection]
id=preconfigured
uuid=8043d3ca-6cb6-4449-83c4-61539463af66
type=wifi
interface-name=wlan1

Mas mesmo depois de definir o nome da interface, após uma reinicialização, 'preconfigured.nmconnection' ainda usa wlan0.

Estou me perguntando por que esse é o caso e como forçar essa conexão com a interface wlan1.

Recentemente peguei um laptop Toshiba antigo e carreguei o Kali Linux nele. Tudo está funcionando bem, com uma exceção: o adaptador sem fio. Ao configurar originalmente o novo sistema operacional, ele falhou várias vezes ao tentar configurar a rede sem fio, mas consegui pular esta parte. Quando estiver em Kali, não há opção de adaptador sem fio em lugar nenhum. Eu costumava lspciverificar se o adaptador wireless era reconhecido e apareceu um: um Broadcom BCM43142. Consegui conectar o laptop com Ethernet para conectar-se à Internet e tentar algumas soluções de problemas que encontrei na web . No entanto, muitos desses métodos são para versões mais antigas (cerca de 8 anos). A versão do Kali que estou executando é 2024.1. Presumo que o problema que estou encontrando está relacionado a um driver ausente para este adaptador específico, no entanto, não tenho certeza da melhor maneira de obtê-los e configurar a rede sem fio para permitir que Kali use o adaptador e acesse o WiFi. Agradeço qualquer ajuda! Obrigado!

Estou enfrentando um problema com meu adaptador de rede MT7601U no Linux. Embora eu tenha entrado com êxito no modo monitor, estou tendo dificuldades para capturar handshakes e descobrir dispositivos na(s) rede(s). Estranhamente, apenas os ataques WPS parecem funcionar de forma confiável.

Aqui estão os principais detalhes:

• Adaptador: Ralink MT7601U
• Distribuição: parrotOS 6.0 (lorikeet) Kernel 6.8.0-xxxxx de 64 bits
• Resumo do problema:
  • O modo monitor está ativado.
  • Não é possível capturar handshakes ou detectar dispositivos na rede, exceto para ataques WPS, que são um tipo muito diferente de ataque wifi.
• Tentativas de resolver:
  • Entrou com sucesso no modo monitor usando o iwcomando ( sudo iw dev <interface> set monitor control).
  • Tentei várias ferramentas como Aircrack-ng, Wireshark e tcpdump para captura de pacotes, mas sem sucesso na captura de handshakes.
  • Mesmo depois de garantir que o modo monitor esteja ativo, nenhum dispositivo será descoberto na rede, exceto durante ataques WPS.
• Observações:
  • Verificou os logs do sistema ( dmesg, /var/log/syslog), mas não encontrou mensagens de erro relevantes.
  • Atualizei os drivers através do gerenciador de pacotes e também tentei baixar no site do fabricante, mas o problema persiste.

Estou entrando em contato com a comunidade para obter orientação sobre etapas de solução de problemas ou possíveis soluções para esse problema. Qualquer conselho ou conhecimento de usuários familiarizados com o adaptador MT7601U ou problemas semelhantes com outros adaptadores serão muito apreciados.

Obrigado pela sua ajuda!

Atenciosamente, Mikey.

Estou tentando configurar um AP com um servidor RADIUS externo usando dois hosts Linux para cada serviço hostapde freeradius, correspondentemente. Esses hosts e o host do cliente Wi-Fi são unidades Raspberry Pi 4 executando Ubuntu 22.04.4 LTS (jammy).

Todos os hosts possuem uma conexão Ethernet com a LAN comum (10.1.0.0/24):

• hostA - AP Wi-Fi (10.1.0.22 Ethernet, 192.168.220.1 Wi-Fi)
• hostB - servidor RADIUS (Ethernet 10.1.0.12)
• hostC - cliente Wi-Fi (10.1.0.50 Ethernet, 192.168.220.101 Wi-Fi)

Configurei o freeradiusservidor no hostB e pude testá-lo no cliente Wi-Fi pela LAN Ethernet:

hostC:~$ radtest -x testUser1 testPassword1 10.1.0.12 0 testSecret1
Sent Access-Request Id 155 from 0.0.0.0:35529 to 10.1.0.12:1812 length 79
    User-Name = "testUser1"
    User-Password = "testPassword1"
    NAS-IP-Address = 10.1.0.50
    NAS-Port = 0
    Message-Authenticator = 0x00
    Cleartext-Password = "testPassword1"
Received Access-Accept Id 155 from 10.1.0.12:1812 to 10.1.0.50:35529 length 20

Em seguida, abro o AP Wi-Fi (hostA) configurado com o seguinte hostapd.confconteúdo:

    logger_syslog=-1
    logger_syslog_level=0
    ctrl_interface=/var/run/hostapd/
    interface=wlp1s0
    driver=nl80211
    country_code=CA
    ieee80211n=1
    hw_mode=g
    channel=6
    beacon_int=100
    dtim_period=2
    disassoc_low_ack=0
    ssid=testAP
    ieee80211w=0
    auth_algs=1
    wpa=0
    ignore_broadcast_ssid=0
    
    eap_server=0
    
    own_ip_addr=10.1.0.22
    auth_server_addr=10.1.0.12 #hostB
    auth_server_port=1812
    auth_server_shared_secret=testSecret1

O hostapdserviço é construído a partir do código mais recente disponível na mainbranch com a única modificação abaixo do defconfigarquivo para desabilitar o servidor RADIUS integrado:

# Integrated EAP server
CONFIG_EAP=n

Posso ver que o hostapdserviço está iniciando corretamente com a configuração do servidor RADIUS relatada de acordo:

hostA:/usr/src/hostap/hostapd$ sudo ./hostapd /etc/hostapd/hostapd.conf -i wlp1s0
wlp1s0: interface state UNINITIALIZED->COUNTRY_UPDATE
wlp1s0: RADIUS Authentication server 10.1.0.12:1812
wlp1s0: interface state COUNTRY_UPDATE->ENABLED
wlp1s0: AP-ENABLED 

Consigo conectar com êxito o cliente Wi-Fi (hostC) ao AP Wi-Fi (hostA). No entanto, quando tento fazer o teste RADIUS agora em uma rede Wi-Fi (192.168.220.0/24) visando o AP Wi-Fi para processar solicitações RADIUS, recebo a falha:

hostC:~$ radtest -x testUser1 testPassword1 10.1.0.22 0 testSecret1
Sent Access-Request Id 235 from 0.0.0.0:59778 to 10.1.0.22:1812 length 79
    User-Name = "testUser1"
    User-Password = "testPassword1"
    NAS-IP-Address = 10.1.0.50
    NAS-Port = 0
    Message-Authenticator = 0x00
    Cleartext-Password = "testPassword1"
Sent Access-Request Id 235 from 0.0.0.0:59778 to 10.1.0.22:1812 length 79
    User-Name = "testUser1"
    User-Password = "testPassword1"
    NAS-IP-Address = 10.1.0.50
    NAS-Port = 0
    Message-Authenticator = 0x00
    Cleartext-Password = "testPassword1"
Sent Access-Request Id 235 from 0.0.0.0:59778 to 10.1.0.22:1812 length 79
    User-Name = "testUser1"
    User-Password = "testPassword1"
    NAS-IP-Address = 10.1.0.50
    NAS-Port = 0
    Message-Authenticator = 0x00
    Cleartext-Password = "testPassword1"
(0) No reply from server for ID 235 socket 3

Capturei o tráfego na interface Wi-Fi do hostAe vi que ele responde com o pacote ICMP dizendo que Destination unreachable (Port unreachable):

Frame 2: 155 bytes on wire (1240 bits), 155 bytes captured (1240 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Apr  2, 2024 18:18:11.473305000 PDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1712107091.473305000 seconds
    [Time delta from previous captured frame: 0.000101000 seconds]
    [Time delta from previous displayed frame: 0.000101000 seconds]
    [Time since reference or first frame: 0.000101000 seconds]
    Frame Number: 2
    Frame Length: 155 bytes (1240 bits)
    Capture Length: 155 bytes (1240 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:icmp:ip:udp:radius]
    [Coloring Rule Name: ICMP errors]
    [Coloring Rule String: icmp.type eq 3 || icmp.type eq 4 || icmp.type eq 5 || icmp.type eq 11 || icmpv6.type eq 1 || icmpv6.type eq 2 || icmpv6.type eq 3 || icmpv6.type eq 4]
Ethernet II, Src: IntelCor_05:02:62 (80:45:dd:05:02:62), Dst: IntelCor_de:58:55 (3c:9c:0f:de:58:55)
    Destination: IntelCor_de:58:55 (3c:9c:0f:de:58:55)
        Address: IntelCor_de:58:55 (3c:9c:0f:de:58:55)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: IntelCor_05:02:62 (80:45:dd:05:02:62)
        Address: IntelCor_05:02:62 (80:45:dd:05:02:62)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.220.1, Dst: 192.168.220.101
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 141
    Identification: 0xa48f (42127)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: ICMP (1)
    Header Checksum: 0x9b68 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.220.1
    Destination Address: 192.168.220.101
Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 3 (Port unreachable)
    Checksum: 0x3724 [correct]
    [Checksum Status: Good]
    Unused: 00000000
    Internet Protocol Version 4, Src: 192.168.220.101, Dst: 192.168.220.1
        0100 .... = Version: 4
        .... 0101 = Header Length: 20 bytes (5)
        Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
            0000 00.. = Differentiated Services Codepoint: Default (0)
            .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
        Total Length: 113
        Identification: 0xc1e8 (49640)
        Flags: 0x00
            0... .... = Reserved bit: Not set
            .0.. .... = Don't fragment: Not set
            ..0. .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment Offset: 0
        Time to Live: 64
        Protocol: UDP (17)
        Header Checksum: 0x7edb [validation disabled]
        [Header checksum status: Unverified]
        Source Address: 192.168.220.101
        Destination Address: 192.168.220.1
    User Datagram Protocol, Src Port: 40929, Dst Port: 1812
        Source Port: 40929
        Destination Port: 1812
        Length: 93
        Checksum: 0xbfa6 [unverified]
        [Checksum Status: Unverified]
        [Stream index: 0]
        UDP payload (85 bytes)
RADIUS Protocol
    Code: Access-Request (1)
    Packet identifier: 0x95 (149)
    Length: 85
    Authenticator: 2cc8f534dfcac17c947a03ced3daf62f
    Attribute Value Pairs
        AVP: t=User-Name(1) l=11 val=testUser1
            Type: 1
            Length: 11
            User-Name: testUser1
        AVP: t=User-Password(2) l=18 val=Encrypted
            Type: 2
            Length: 18
            User-Password (encrypted): 986ed23c9a832e3a98a328697e8fab38
        AVP: t=NAS-IP-Address(4) l=6 val=192.168.220.101
            Type: 4
            Length: 6
            NAS-IP-Address: 192.168.220.101
        AVP: t=NAS-Port(5) l=6 val=0
            Type: 5
            Length: 6
            NAS-Port: 0
        AVP: t=Message-Authenticator(80) l=18 val=b4669b2314a4738a956f683b59b645c4
            Type: 80
            Length: 18
            Message-Authenticator: b4669b2314a4738a956f683b59b645c4
        AVP: t=Framed-Protocol(7) l=6 val=PPP(1)
            Type: 7
            Length: 6
            Framed-Protocol: PPP (1)

O que sinto falta aqui?