Perguntas[networking](unix)

Tenho um Raspberry Pi 1 Modelo B que usa Bookworm de 32 bits e o conectei ao meu roteador de rede (um hub BT) via cabo Ethernet.

Quero poder ler e gravar em todos os arquivos do Raspberry Pi do meu laptop Windows 11 usando o caminho \\192.168.1.123\example.

Atualmente, meu PC consegue ler alguns arquivos que configurei usando o Samba naquele diretório de arquivos, mas não consigo ver nenhum dos arquivos originais não criados usando o Samba ou nenhuma das unidades USB conectadas.

Como posso fazer com que meu laptop seja capaz de gravar e ler todos os arquivos e unidades conectados ao Raspberry Pi?

Também quero que todas as unidades que eu conecte sejam automaticamente acessíveis pelo laptop para que eu não precise alterar nada no meu Raspberry Pi toda vez que conectar uma nova unidade.

Ao olhar o tráfego no Wireshark, notei que meu computador estava enviando um pacote UDP a cada três segundos no endereço de transmissão para a porta 8765, com o conteúdo "*" (42 em ASCII). Não parece ser uma resposta a nada. A porta de origem muda a cada pacote.

Tentei descobrir o que estava emitindo esse pacote, mas não obtive sucesso. Tentei:

• Interrompendo todos os serviços não vitais que eu poderia pensar.
• Adicione uma regra iptables para descartar os pacotes (isso interrompe os pacotes, mas não me ajuda a saber o que os emite).
• Adicionei uma regra do iptables para interromper o encaminhamento e ver se de alguma forma ele foi encaminhado pelo meu computador, mas não.
• Usei auditd com vários parâmetros, mas nada combinou e nem consegui encontrar um write(*,*,1)/send(*,*,1)/sendto(*,*,1,*,*)/sendmsg/sendmmsgcom a frequência certa. No entanto, não estou familiarizado com auditd.
  • auditctl -a exit,always -F arch=b64 -S socket -F a0=2 -F a1=2para procurar a criação de soquetes UDP IPv4.
  • auditctl -a exit,always -F arch=b64 -S connectapenas para procurar por alguma conexão.
  • auditctl -a exit,always -F arch=b64 -S write -S send -S sendto -F a2=1para combinar sende writesyscalls com comprimento de 1.
  • audictl -a exit,always -F arch=b64 -S sendmsg -S sendmmsg
  • Todos os itens acima com -F arch=b32instead.
• Use netstat/ss, mas o soquete provavelmente tem vida curta, então não mostra nada.

Quais são outras maneiras de determinar o que transmite esse pacote? E se ele vier do kernel ou de um módulo do kernel? Como eu poderia saber?

Eu tenho o Zoom Workplace 6.2.6 instalado manualmente a partir de um arquivo RPM baixado do site oficial do Zoom. Quando tento fazer login com meu nome de usuário e senha, ele não consegue se conectar e diz: " Parece que não conseguimos nos conectar. Verifique sua conexão de rede e tente novamente ". Ele também não consegue se conectar a uma reunião já iniciada por outra pessoa usando uma URL sem fazer login e uma mensagem de erro semelhante é exibida.

Ao mesmo tempo, outras pessoas na mesma LAN podem se conectar e usar o Zoom. Eu também tentei outra rede (conexão WiFi a um Hotspot no meu telefone) com o mesmo resultado.

Se eu executar zooma partir de um terminal, nenhuma mensagem adicional será impressa naquele terminal.

$ dnf info zoom
Updating and loading repositories:
Repositories loaded.
Installed packages
Name            : zoom
Epoch           : 0
Version         : 6.2.6.2503
Release         : 1
Architecture    : x86_64
Installed size  : 681.9 MiB
Source          : zoom-6.2.6.2503-1.src.rpm
From repository : @commandline
Summary         : Zoom Cloud Meetings
URL             : https://www.zoom.us
License         : see https://www.zoom.us/
Description     : Zoom Cloud Meetings
                : Zoom brings people together to connect and get more done in a frictionless, secure video environment. Our easy, 
                : reliable, and innovative video-first solutions provide video meetings and chat, with additional options for webi
                : nars and phone service.
                :  .
                : Zoom is the leading unified communications platform and helps individuals, schools, healthcare professionals and
                :  enterprises stay connected. Visit blog.zoom.us and follow @zoom_us.
                :  .
                : By installing this app, you agree to our Terms of Service (https://zoom.us/terms) and Privacy Statement (https:/
                : /zoom.us/privacy).
Vendor          : Zoom Video Communications, Inc.

É um bug/problema conhecido? Onde posso baixar uma versão mais antiga do Zoom? Por exemplo, 6.0.6

Tenho configurado uma caixa Linux como meu roteador. E minha rede é bem simples neste ponto:

1. Tenho o roteador conectado à minha caixa de fibra, que autentica com meu ISP usando pppd.
2. Tenho uma interface ethernet, enp2s0que é o gateway no roteador:

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.1.1  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::20d:b9ff:fe5a:2f91  prefixlen 64  scopeid 0x20<link>
        ether 00:0d:b9:5a:2f:91  txqueuelen 1000  (Ethernet)
        RX packets 57348511  bytes 31510953543 (29.3 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 116229180  bytes 129467792313 (120.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xf7a00000-f7a1ffff

3. Tenho uma interface sem fio:

wlp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.1.2  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::6f0:21ff:fe91:cf90  prefixlen 64  scopeid 0x20<link>
        ether 04:f0:21:91:cf:90  txqueuelen 1000  (Ethernet)
        RX packets 493730  bytes 595814115 (568.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 355275  bytes 344035494 (328.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Com o qual eu gostaria que os clientes se conectassem.

4. Tenho nftablesalgumas regras básicas de roteamento para direcionar o tráfego.

Meus clientes conseguem se conectar à interface ethernet sem problemas. E internet etc. funcionam como esperado. No entanto, ao conectar à interface sem fio e fazer ping:

-> % ping -I wlp65s0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 10.1.1.48 wlp65s0: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
60 packets transmitted, 0 received, 100% packet loss, time 60428ms

Parece que não recebo nenhuma resposta.

No roteador, vejo o seguinte ao habilitar nftables trace:

trace id 85cd7345 ip filter trace_chain packet: iif "ppp0" ip saddr 8.8.8.8 ip daddr 10.1.1.48 ip dscp af21 ip ecn not-ect ip ttl 61 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 12 icmp sequence 59 @th,64,96 0xd9d22c6700000000d1790900 
trace id 85cd7345 ip filter forward packet: iif "ppp0" oif "enp2s0" ip saddr 8.8.8.8 ip daddr 10.1.1.48 ip dscp af21 ip ecn not-ect ip ttl 60 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 12 icmp sequence 59 @th,64,96 0xd9d22c6700000000d1790900 
trace id 3626e73a ip filter trace_chain packet: iif "wlp4s0" ether saddr 48:ad:9a:9d:5e:a4 ether daddr 04:f0:21:91:cf:90 ip saddr 10.1.1.48 ip daddr 8.8.8.8 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 52040 ip length 84 icmp type echo-request icmp code net-unreachable icmp id 12 icmp sequence 60 @th,64,96 0xdad22c67000000006cd70900 
trace id 3626e73a ip filter forward packet: iif "wlp4s0" oif "ppp0" ether saddr 48:ad:9a:9d:5e:a4 ether daddr 04:f0:21:91:cf:90 ip saddr 10.1.1.48 ip daddr 8.8.8.8 ip dscp cs0 ip ecn not-ect ip ttl 63 ip id 52040 ip length 84 icmp type echo-request icmp code net-unreachable icmp id 12 icmp sequence 60 @th,64,96 0xdad22c67000000006cd70900 
trace id a6c3e760 ip filter trace_chain packet: iif "ppp0" ip saddr 8.8.8.8 ip daddr 10.1.1.48 ip dscp af21 ip ecn not-ect ip ttl 61 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 12 icmp sequence 60 @th,64,96 0xdad22c67000000006cd70900 
trace id a6c3e760 ip filter forward packet: iif "ppp0" oif "enp2s0" ip saddr 8.8.8.8 ip daddr 10.1.1.48 ip dscp af21 ip ecn not-ect ip ttl 60 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 12 icmp sequence 60 @th,64,96 0xdad22c67000000006cd70900 

O que não consigo entender.

Qualquer dica aqui será muito útil.

Se eu alterar o endereço da interface sem fio para 10.1.2.1, poderei me conectar a outros hosts na LAN/WAN.

O bootpc e o bootpd atuais do Debian (do bootp ) não parecem realmente funcionar juntos no ambiente do kernel Linux de hoje. Parece haver um problema 🐔/🥚; bootpdenvia as respostas como pacotes UDP unicast para o endereço IP ainda não configurado. O kernel do cliente então os descarta sem entregar ao bootpcsoquete do cliente, porque esse endereço IP não é (ainda) um endereço local válido no host.

Como isso funcionou?

• Existe algum parâmetro do kernel ou outra modificação que pode fazer com que o kernel envie esses pacotes ao bootpcprocesso?
• Existe uma configuração bootpdque fará com que ele use todos os endereços IP de destino 1 ou 0 em vez do endereço IP unicast do cliente ainda não configurado?

Temos um cliente em potencial com uma grande infraestrutura bootp não-DHCP. Suporte bootp old-school é um dos requisitos deles.

Detalhes do problema

• bootpdenvia seus pacotes de resposta como pacotes unicast para o endereço MAC do cliente bootpc, usando um valor de endereço IP de destino do endereço que também está na carga útil, informando ao cliente para se configurar.
• O kernel então descarta esses pacotes, em vez de entregá-los ao bootpcprocesso que os solicitou.
• bootpcabriu corretamente um soquete de escuta para 0.0.0.0:68 0.0.0.0:*(veja a saída netstat abaixo)
• Verifiquei essa análise de várias maneiras:
  • Eu corri tcpdumpe posso ver as respostas chegando ao NIC
  • Eu executei dropwatche vi os pacotes sendo descartados com o motivo IPINADDRERROR, que basicamente significa "endereço IP inválido"
  • Posso enganar bootpdpara usar 0.0.0.0 como o endereço IP de destino omitindo uma atribuição de IP real; quando faço isso, bootpcobtenho as respostas e as processa. No entanto, isso não ajuda porque o cliente não obtém um endereço IP
  • Eu tentei adicionar o endereço IP à interface enquanto bootpcela faz requisições. Depois que eu adiciono, a próxima resposta chega ao processo.
• Eu também tentei a bootpc --serverbcastopção. Isso falha por um motivo similar:
  • bootpdenvia as respostas para o endereço de transmissão da sub-rede (por exemplo, 10.0.43.255)
  • Como o endereço IP e a máscara de sub-rede ainda não estão configurados em uma interface, o kernel não tem motivos para considerar isso um endereço válido para si mesmo.
• Aqui está nossa bootptabconfiguração atual:

.vs-default:\
  :sm=255.255.254.0:\
  :gw=10.0.42.1:\
  :ds=10.0.42.1:\
  :hn:
client-ad02-vs:\
  ht=1:\
  ha=0xea4a1fad0002:\
  ip=10.0.42.31:\
  tc=.vs-default:

Saída do Netstat mostrando bootpc's listening socket:

$ sudo netstat -unlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
udp        0      0 0.0.0.0:68              0.0.0.0:*                           2295/bootpc         

Solução alternativa para o Hacky

Eu inventei uma solução alternativa que parece hackeada. Em particular, acho que ela aproveita um comportamento não intencional, talvez não possamos contar com ela para funcionar no futuro:

• o módulo iptables conntrack tem uma correspondência ctstatecom um valor de DNAT.
• Isso pode ser usado para aceitar pacotes que tenham um endereço IP de destino não reconhecido
• Não creio que a intenção seja corresponder a IPs de horário de verão arbitrários:
  • Ele só pode ser usado com pacotes que foram NAT'd pelo kernel do mesmo host
  • Acredito que seu propósito seja corresponder a pacotes que tiveram seus endereços reescritos (o que não estamos fazendo), mas é uma implementação "barata" que ignora a tabela de mapeamento NAT em vez de verificar se há uma entrada que corresponde a esse pacote específico.
  • Estou preocupado que isso seja removido ou reescrito para ser menos promíscuo no futuro
  • Para que isso funcione, preciso mapear a porta desses pacotes para a porta DST existente, apenas para obter dados de estado da conexão NAT no pacote. Caso contrário, --ctstate DNATnão se aplica ao pacote.

Histórico/Due Diligence

• Nosso ambiente de testes usa o Debian 12 no Linux 6.1.0.
• Nossos hosts de teste são de imagens de VM prontas para uso do UTM Debian 12
• bootpdtem muito poucas opções de cli, nenhuma das quais envolve respostas, portas ou endereços. A página do manual não menciona "broadcast" ou "unicast", e referências a "address" ou "destination" são poucas e não relevantes.
• Nosso produto atual é o Debian 12 em um kernel Linux 5.19.9 personalizado (e se comporta da mesma maneira)
• A conectividade IP está funcionando totalmente entre o cliente e o servidor do ambiente de teste
• bootpcse recusa a enviar solicitações, a menos que o seguinte seja verdadeiro:
  • Não há nenhum endereço IP roteável na interface (169.254/16 é permitido, embora eu tenha tentado sem ele)
  • Há uma rota padrão 0/0 apontando para a interface onde o servidor bootp é esperado
    • Caso contrário, diznetwork unreachable
    • Nota: especificar --dev <iface>na bootpclinha de comando não ajuda com isso
• Ainda estou trabalhando na avaliação de bootptabopções de configuração para ver se há alguma que afete isso. Não encontrei uma boa referência para elas, a bootptabpágina man do man é muito concisa sobre elas.

Solução alternativa

Consegui fazer isso funcionar com uma iptablessolução menos complicada: adicionei uma regra NAT que corresponde à porta UDP 68 (bootpc) e mapeia o endereço IP de destino para 255.255.255.255 (e mantém a mesma porta UDP).

Isso funciona, mas considero isso hacky. Claramente não é assim que o protocolo deve funcionar, então eu preferiria uma solução "real", se possível.

A questão de como criar um IPv6 estático, mas com prefixo anunciado, já foi feita aqui (a solução parece ser definir token), mas gostaria de entender exatamente o que está acontecendo na minha configuração.

Meu sistema usa nativamente o NetworkManager, mas eu gostaria de implementar as mudanças através do ifupdown. Eu criei um arquivo /etc/network/interfaces com a seguinte configuração

auto wlp2s0 permitir hotplug wlp2s0

iface wlp2s0 inet dhcp

iface wlp2s0 inet6
endereço automático ::be70:f1ic:a1a1:d502/64
accept_ra 2

privado 0

Quando inicio o networkingdaemon após criar este arquivo, dois endereços são adicionados à interface wlp2s0, um global dynamic mngtmpaddre um global dynamic mngtmpaddr noprefixroute(além dos originais, que incluem uma dinâmica global, uma extensão de privacidade e o link um), nenhum dos quais tem o prefixo que eu queria consertar. Além disso, neste estágio não consigo acessar a internet (na verdade, parece que as conexões existentes continuam funcionando enquanto novas não podem ser estabelecidas).

E se eu reiniciar o sistema (acredito que reiniciar o NetworkManager pode ser suficiente, mas não tenho certeza), meu adaptador sem fio nem consegue iniciar (a interface wlp2s0 fica inativa sem operadora).

Agora, para minhas perguntas:

1. Eu sei que a maneira correta de fazer o que quero é com um token, mas por que exatamente minha configuração não fixa um IP para ter meu sufixo?

2. Por que recebo dois novos endereços, um com noprefixroutee outro sem, em vez de apenas um?

3. Por que reiniciar o kernel mata a interface?

Agradeço qualquer informação!

Tenho uma pergunta de 'entendimento', mas ela tem um caso do mundo real que eu simplifiquei. Considere esta rede de exemplo (com IPs simplificados): Da esquerda para a direita:

• Três hosts S1-S3 (IPs, executando três programas R1-R3 respectivamente; Um switch com 3 VLANS e uma porta trunk conectada à eth0 de um quarto host S4. Todos são Ubuntu 20.04 LTS, mas isso provavelmente é irrelevante.
• O S4 está executando o P1 que se vincula a três soquetes UDP, um em cada uma das três interfaces VLAN nas respectivas redes S1,2,3
• P1 Envia mensagens UDP unicast e multicast para várias portas em cada um desses sockets a taxas de 10-100Hz. Há uma OUTPUTcadeia netfilter controlando esses fluxos.

Cada uma das áreas vermelhas representa algo que pode estar 'inativo'. Em todos esses casos, exceto um, os datagramas UDP são imediatamente descartados:

• Interface virtual V10está com link inativo; processo R2não está em execução; ou OUTPUTencadeia DROPo fluxo - Em cada caso, os pacotes são descartados silenciosamente por S2 ou um erro é relatado de volta para P1 e o pacote descartado. Todos os outros mcast continuam a fluir.
• No caso do S3, após a remoção do OUTPUTbloco, o txbuffer do soquete v12rapidamente se enche com pacotes unicast destinados 12.1e isso bloqueia qualquer gravação futura de unicast e multicast.

Neste estado, um straceon P1pode se parecer com isto (aparado):

15:38:27 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:27 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:27 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:27 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = -1 EAGAIN (Resource temporarily unavailable)
15:38:30 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:30 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:30 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:30 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = -1 EAGAIN (Resource temporarily unavailable)

E ssmostra o problema:

State    Recv-Q  Send-Q   Local Address:Port   Peer Address:Port  Process
UNCONN   0       148992   0.0.0.0:51047        0.0.0.0:*          users:(("task",pid=381888,fd=9))
     skmem:(r0,rb212992,t148992,tb131070,f0,w0,o0,bl0,d0)

Então temos 4 * ~30kb de gravações no buffer de socket (padrão 120kb) com o 4º reportando EAGAINquando o buffer está cheio. O buffer está enchendo repetidamente enquanto o SO está esperando por uma ARPresposta S3que nunca virá.

Duas perguntas depois de tudo isso:

1. UDP não é confiável por natureza. Nossa aplicação fica muito feliz que pacotes sejam descartados de outra forma, então por que seriam txenfileirados dessa forma enquanto o kernel tenta resolver ARP? (Considere o caso em que o S3 pode estar conectado apenas ocasionalmente, mas outros hosts v12ainda podem ser alcançáveis.)
2. O buffer parece ser esvaziado (e então rapidamente preenchido com novas gravações) a cada 3 segundos. Um dos resultados é que qualquer multicast que entra na mesma txfila sai em pequenas rajadas em vez de na taxa de envio constante. Claro que podemos abrir mais soquetes de envio, mas onde esse valor é definido e esse comportamento é ajustável sysctl?

Uma pergunta relacionada está aqui, mas a resposta não é muito intuitiva. Certamente há um método mais padrão para configurar NIC:
Como posso associar permanentemente comandos tc qdisc a uma interface específica?

Outra questão relacionada é:
As regras do TC podem persistir além de uma reinicialização? Onde?

No entanto, não estou usando networkingo serviço para editar, /etc/network/interfacesconforme detalhado posteriormente na pergunta.

Atualmente, minha placa de rede wifi está configurada para usar noqueuedisciplina de enfileiramento e quero alterá-la para fq_codel, mas, para que ela persista, reinicialize:

ip link show dev wlan0
    
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff

Para mudar qdisceu faço:

sudo tc qdisc add dev wlan0 root fq_codel
ip link show dev wlan0

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DORMANT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff

Isso funciona, qdiscfoi alterado conforme visto, mas somente até a reinicialização.

Também verifiquei o qdiscvalor padrão definido no sistema, que já está definido como fq_codel:

sudo sysctl net.core.default_qdisc

net.core.default_qdisc = fq_codel

A rede é controlada por systemd-networkd, networkingo serviço é desabilitado.
A NIC é gerenciada por NetworkManagersem nenhuma configuração systemd.

Estou ciente de que no modo monitor, você pode ser desconectado da internet. Você não conseguirá acessar a internet dentro do modo monitor porque o gerenciador de rede para. Então eu reinicio:

sudo systemctl start NetworkManager

então coloco o wlan0 (nome da minha placa wireless) no managedmodo

sudo ifconfig wlan0 down
sudo iwconfig wlan0 mode managed
sudo ifconfig wlan0 up

Eu corro iwconfige vejo que wlan0está em modo gerenciado:

wlan0     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=-2147483648 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

mas ainda não consigo ver as conexões wifi. se eu reiniciar a máquina, volto às configurações normais, mas não quero reiniciar toda vez que trabalho no modo monitor

Acabei de instalar o endeavoros no meu laptop e, a princípio, pensei que estava tudo bem porque usei uma conexão com fio e tinha acesso à internet, mas quando tentei o wifi mais tarde, não consegui conectar ou fazer ping em nenhum site. Conectei-me ao wifi com o iwctl e ele mostra que estou conectado, mas o nmcli mostra que não estou conectado. Acho que o problema é que não tenho um endereço IP de gateway ou uma rota padrão porque quando uso o routecomando, ele só retorna isso:

Kernel IP routing table
Destination   Gateway   Genmask Flags Metric Ref   Use Iface

Quando tentei adicionar uma rota com sudo ip route add default via 192.168.0.1(obtive esse endereço de outra postagem do fórum, mas vi muitos outros endereços em fóruns diferentes, mas não sei qual devo usar porque todo mundo, exceto eu, parece ter um), só recebi este erro:

Error: Nexthop has invalid gateway. 

Não sei o que fazer porque ainda não consegui encontrar ninguém com esse problema.

Desculpe se entendi errado alguma coisa ou se usei os termos errados, mas não tenho muita experiência com problemas de internet.

Editar: Acabei de descobrir que a internet funciona perfeitamente bem quando uso o KDE Plasma em vez do Hyprland, que eu usava antes. No Plasma, conectei-me ao wifi usando a GUI e funcionou, e eu tinha acesso à internet e o comando route também tinha uma saída normal. Quando tentei usar a GUI no Hyprland, não funcionou. Isso é um bug específico do Hyprland ou eu baguncei alguma coisa quando o instalei?